UFW不允许Kurento Media Server 6.7通过ws_uri连接
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了UFW不允许Kurento Media Server 6.7通过ws_uri连接相关的知识,希望对你有一定的参考价值。
问题
在Ubuntu 16.04中为本地网络配置kurento-media-server(版本6.7.0)的UFW时,我有非常奇怪的经历。我的节点应用程序和KMS都安装在同一台服务器上,运行在不同的端口上。禁用UFW后,应用程序运行正常,节点应用程序与KMS运行良好。现在,我激活ufw并将其配置为
- 允许进出kurento-media-server监听端口(8888)
- 允许通过所有UDP端口进出连接,
- 允许通过节点应用程序的侦听端口,
- 允许路由,
- 其他常见的ufw规则,如ufw允许80,443,53等
该应用程序将无法连接到KMS。似乎WebSocket握手卡在某种缓冲区中。
配置完成后,KMS将无法连接到该应用。而且,据我所知,ufw不会干扰localhost连接。但是与ws://localhost:8888/kurento
的连接只是陷入了环回。
Installation source link
Conf file (/etc/kurento/kurento.conf.json
)
{
"mediaServer" : {
"resources": {
// //Resources usage limit for raising an exception when an
// object creation is attempted
// "exceptionLimit": "0.8",
// // Resources usage limit for restarting the server when no
// objects are alive
// "killLimit": "0.7",
// Garbage collector period in seconds
"garbageCollectorPeriod": 240
},
"net" : {
"websocket": {
"port": 8888,
//"secure": {
// "port": 8433,
// "certificate": "defaultCertificate.pem",
// "password": ""
//},
//"registrar": {
// "address": "ws://localhost:9090",
// "localAddress": "localhost"
//},
"path": "kurento",
"threads": 10
}
}
}
}
尝试使用UFW:
- 启用ufw后,允许所有三个传入,传出路由,没有任何限制,然后kms也不会连接。
- 为了找出根本原因,我使用
ws_uri
检查了Simple WebSocket Client连接。即使这样也会产生相同的结果;在ufw被禁用时成功连接,并且在启用ufw时不连接并在超时后获取警报undefined
。
KMS问题
在每次连接失败后,无论是使用Node App(基本上是节点包kurento-client)还是Simple WebSocket Client,我都不能简单地禁用UFW并完成所有工作。我必须重启系统,禁用防火墙(ufw)并启动kurento-media-server-6.0。甚至sudo service kurento-media-server-6.0 restart
也无济于事。
tcpdump输出:
tcpdump -vv -i lo port 8888 and '(tcp-syn|tcp-ack)!=0'
when successful
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size
262144 bytes
13:04:30.904489 IP (tos 0x0, ttl 64, id 51739, offset 0, flags [DF],
proto TCP (6), length 316)
localhost.48866 > localhost.8888: Flags [P.], cksum 0xff30 (incorrect
-> 0xf928), seq 1016466694:1016466958, ack 1363142683, win 3637,
options [nop,nop,TS val 2501898228 ecr 2501846491], length 264
13:04:30.904729 IP (tos 0x0, ttl 64, id 51740, offset 0, flags [DF],
proto TCP (6), length 298)
localhost.48866 > localhost.8888: Flags [P.], cksum 0xff1e (incorrect
-> 0xc0e7), seq 264:510, ack 1, win 3637, options [nop,nop,TS val
2501898228 ecr 2501846491], length 246
13:04:30.906243 IP (tos 0x0, ttl 64, id 43249, offset 0, flags [DF],
proto TCP (6), length 52)
localhost.8888 > localhost.48866: Flags [.], cksum 0xfe28 (incorrect -
> 0x009f), seq 1, ack 510, win 1891, options [nop,nop,TS val
2501898228 ecr 2501898228], length 0
13:04:30.906293 IP (tos 0x0, ttl 64, id 43250, offset 0, flags [DF],
proto TCP (6), length 155)
localhost.8888 > localhost.48866: Flags [P.], cksum 0xfe8f (incorrect
-> 0xd653), seq 1:104, ack 510, win 1891, options [nop,nop,TS val
2501898230 ecr 2501898228], length 103
when failed
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size
262144 bytes
13:13:14.951036 IP (tos 0x0, ttl 64, id 22976, offset 0, flags [DF],
proto TCP (6), length 60)
localhost.53530 > localhost.8888: Flags [S], cksum 0xfe30 (incorrect -
> 0x270b), seq 3285074519, win 43690, options [mss 65495,sackOK,TS val
2502422275 ecr 0,nop,wscale 7], length 0
13:13:22.531679 IP (tos 0x0, ttl 64, id 28371, offset 0, flags [DF],
proto TCP (6), length 60)
localhost.55238 > localhost.8888: Flags [S], cksum 0xfe30 (incorrect -
> 0x1a57), seq 3772583348, win 43690, options [mss 65495,sackOK,TS val
2502429855 ecr 0,nop,wscale 7], length 0
13:13:23.559036 IP (tos 0x0, ttl 64, id 28372, offset 0, flags [DF],
proto TCP (6), length 60)
localhost.55238 > localhost.8888: Flags [S], cksum 0xfe30 (incorrect -
> 0x1654), seq 3772583348, win 43690, options [mss 65495,sackOK,TS val
2502430882 ecr 0,nop,wscale 7], length 0
13:13:25.575055 IP (tos 0x0, ttl 64, id 28373, offset 0, flags [DF],
proto TCP (6), length 60)
localhost.55238 > localhost.8888: Flags [S], cksum 0xfe30 (incorrect -
> 0x0e74), seq 3772583348, win 43690, options [mss 65495,sackOK,TS val
2502432898 ecr 0,nop,wscale 7], length 0
13:13:29.799248 IP (tos 0x0, ttl 64, id 28374, offset 0, flags [DF],
proto TCP (6), length 60)
localhost.55238 > localhost.8888: Flags [S], cksum 0xfe30 (incorrect -
> 0xfdf2), seq 3772583348, win 43690, options [mss 65495,sackOK,TS val
2502437123 ecr 0,nop,wscale 7], length 0
13:13:37.990986 IP (tos 0x0, ttl 64, id 28375, offset 0, flags [DF],
proto TCP (6), length 60)
localhost.55238 > localhost.8888: Flags [S], cksum 0xfe30 (incorrect -
> 0xddf3), seq 3772583348, win 43690, options [mss 65495,sackOK,TS val
2502445314 ecr 0,nop,wscale 7], length 0
最后,我自己解决了这个问题。经过非常严格的互联网搜索后,我在Websocketpp发现了类似的问题,问题#623突出了原因。
实际问题是由于不同内核对listen backlog参数的不同解释。 Ubuntu 16.04解释了值0
拒绝所有连接,而不是使用其默认的backlog队列。后来,我发现kurento-media-server使用相同的服务(Websocktepp)来处理websocket连接。这个问题已在提交0bb33e4
中解决,但它仍未在Websocktetpp的master
分支(版本0.70)上解决,问题在Websocketpp的develop
分支(版本0.80-dev)中得到解决。由于kurento-media-server仍在使用master
的稳定版本,因此没有直接的解决方案。
第一个想法是克隆kms repo,修复问题并重建服务。但测试失败了。
最后,使用以下内容更改积压长度解决了我的问题。
$ echo "net.ipv4.tcp_max_syn_backlog=1024" >> /etc/sysctl.conf
$ sysctl -p
我认为这会覆盖websocketpp(版本0.70)设置的值。
P.S。:我永久启用tcp_syn_cookies
以抵抗同步泛滥。
以上是关于UFW不允许Kurento Media Server 6.7通过ws_uri连接的主要内容,如果未能解决你的问题,请参考以下文章
Kurento - Firefox 无法与位于 wss://<ipaddress>:8433/kurento 的服务器建立连接。