centos7上coturn服务启动后无法访问的故障处理
提问背景
我正在开发webrtc的视频通话功能,建立P2P的连接需要搭建stun/turn服务器,于是我在阿里云centos7服务器上利用coturn在3478端口启动了该服务,但是在测试时发现服务不可用。


尝试解决
一开始,我以为是端口未开放的问题,于是我在安全组设置了入方向和出方向的端口对全部流量进行全部开放,并且关闭了防火墙的限制,但是依然没有用。
详细信息
启动命令
▼js复制代码/usr/local/turnserver/bin/turnserver -v -r 47.94.53.126 -a -o -c /usr/local/turnserver/share/examples/turnserver/etc/turnserver.conf
具体配置
▼js复制代码listening-port=3478 listening-ip=172.18.61.183 tls-listening-port=5349 # TLS 加密端口 cert=/ssl/cert.pem pkey=/ssl/cert.key external-ip=47.94.53.126 user=user:654321 realm=47.94.53.126 lt-cred-mech relay-ip=0.0.0.0 # 至于为什么配置relay-ip=0.0.0.0 ?? # 因为我尝试填写了内网ip或外网IP,但都无效 min-port=49152 max-port=65535 verbose log-file=/var/log/turnserver.log
部分日志
▼js复制代码696: session 001000000000000010: realm <47.94.53.126> user <user>: incoming packet BINDING processed, success 696: session 001000000000000011: realm <47.94.53.126> user <user>: incoming packet BINDING processed, success 706: session 001000000000000010: realm <47.94.53.126> user <user>: incoming packet BINDING processed, success 706: session 001000000000000011: realm <47.94.53.126> user <user>: incoming packet BINDING processed, success 716: session 001000000000000010: realm <47.94.53.126> user <user>: incoming packet BINDING processed, success 716: session 001000000000000011: realm <47.94.53.126> user <user>: incoming packet BINDING processed, success 726: session 001000000000000010: realm <47.94.53.126> user <user>: incoming packet BINDING processed, success 726: session 001000000000000011: realm <47.94.53.126> user <user>: incoming packet BINDING processed, success 736: session 001000000000000010: realm <47.94.53.126> user <user>: incoming packet BINDING processed, success 736: session 001000000000000011: realm <47.94.53.126> user <user>: incoming packet BINDING processed, success 743: session 001000000000000010: refreshed, realm=<47.94.53.126>, username=<user>, lifetime=0 743: session 001000000000000010: realm <47.94.53.126> user <user>: incoming packet REFRESH processed, success 743: session 001000000000000011: refreshed, realm=<47.94.53.126>, username=<user>, lifetime=0 743: session 001000000000000011: realm <47.94.53.126> user <user>: incoming packet REFRESH processed, success 744: session 001000000000000010: usage: realm=<47.94.53.126>, username=<user>, rp=22, rb=1160, sp=22, sb=1888 744: session 001000000000000010: closed (2nd stage), user <user> realm <47.94.53.126> origin <>, local 172.18.61.183:3478, remote 36.112.200.70:30675, reason: allocation timeout 744: session 001000000000000010: delete: realm=<47.94.53.126>, username=<user> 744: session 001000000000000010: peer 172.17.0.1 deleted 744: session 001000000000000010: peer 36.112.200.70 deleted 744: session 001000000000000010: peer 10.24.68.63 deleted 744: session 001000000000000010: peer 47.94.53.126 deleted 744: session 001000000000000011: usage: realm=<47.94.53.126>, username=<user>, rp=22, rb=1160, sp=22, sb=1888 744: session 001000000000000011: closed (2nd stage), user <user> realm <47.94.53.126> origin <>, local 172.18.61.183:3478, remote 36.112.200.70:30676, reason: allocation timeout 744: session 001000000000000011: delete: realm=<47.94.53.126>, username=<user> 744: session 001000000000000011: peer 172.17.0.1 deleted 744: session 001000000000000011: peer 36.112.200.70 deleted 744: session 001000000000000011: peer 10.24.68.63 deleted 744: session 001000000000000011: peer 47.94.53.126 deleted
使用lsof命令查看端口信息
▼js复制代码[root@iZ2zeh5hzhg0kgjwdxkm9cZ ~]# lsof -i :3478 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME turnserve 27441 root 17u IPv4 25694475 0t0 TCP iZ2zeh5hzhg0kgjwdxkm9cZ:stun (LISTEN) turnserve 27441 root 20u IPv4 25693882 0t0 TCP iZ2zeh5hzhg0kgjwdxkm9cZ:stun (LISTEN) turnserve 27441 root 22u IPv4 25693885 0t0 UDP iZ2zeh5hzhg0kgjwdxkm9cZ:stun turnserve 27441 root 23u IPv4 25693886 0t0 UDP iZ2zeh5hzhg0kgjwdxkm9cZ:stun
评论
相关内容
0个评论
全部评论
点击登录,快来和大家讨论吧~
表情
图片
暂无评论
内容推荐
图像复原和扩散模型怎么入门啊,纯新手小白啥都不会,求大佬们指点一下方向
0
【入职求助贴】萌新刚入职某大厂做后端开发,目前还在试用期。最近遇到一个棘手的问题,想向大家求助一下。入职不久,leader 给我派了一个任务。跟我说是0.5天就可以解决,我刚毕业入职,做了一个星期没有做出来。实现一个收集定时成功任务的案例。听起来好像不复杂,但我自己摸索着做了一整个星期,到现在还没达到预期效果。这一周我基本是“边学边做”的状态,遇到卡点也会每天主动找 leader 沟通进度和疑问。
2
最近在使用ChatGPT/Codex过程中发现了一个官方bug:高频日志写盘,会损坏电脑磁盘的寿命。桌面版和CLI都有这个问题,目前最新版的ChatGPT/Codex还没有彻底解决这个问题(虽然官方自称已经修复了,但实测还是有高频日志写盘问题)。建议使用下面这段提示词发给AI让它检查和修复:帮我检查 ~./codex/logs_2.sqlite 是否因 TRACE 日志持续高频写盘;如果中招,先备
2
🐟友们,工作后,周末你们一般都干啥🤔
0
独立开发一个企业级Web系统:斗篷系统(ABcloakPro)的开发实践
2
