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:

  1. 启用ufw后,允许所有三个传入,传出路由,没有任何限制,然后kms也不会连接。
  2. 为了找出根本原因,我使用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 录制音频的答案 SDP?

IPTable命令工作的原因是什么,但UFW没有?

ubuntu的ufw如何开放特定端口?

Kurento - Firefox 无法与位于 wss://<ipaddress>:8433/kurento 的服务器建立连接。

ufw防火墙禁止ping,怎设置?

如何在Ubuntu 16.04上使用UFW设置防火墙