UFW 不允许 Kurento Media Server 6.7 通过 ws_uri 连接 [英] UFW not allowing Kurento Media Server 6.7 to get connected through ws_uri

问题描述

在 Ubuntu 16.04 中为 本地网络 中的 kurento-media-server(版本 6.7.0)配置 UFW 时，我遇到了非常奇怪的经历.我的节点应用程序和 KMS 都安装在同一台服务器上，运行在不同的端口上.禁用 UFW 后，应用程序运行良好，节点应用程序与 KMS 运行良好.现在，我激活 ufw 并将其配置为

I had very strange experiences while configuring UFW for kurento-media-server(version 6.7.0) in Ubuntu 16.04 for a local network. My node app and KMS are both installed on the same server, running on different ports. With UFW disabled, the app works fine, and the node app is working quite well with KMS. Now, I activate ufw and configure it to

• 允许进出kurento-media-server 监听端口(8888)
• 允许通过所有 UDP 端口进出连接，
• 允许通过节点应用的监听端口，
• 允许路由，
• 其他常见的 ufw 规则，如 ufw 允许 80、443、53 等

• allow in and out kurento-media-server listening port(8888)
• allow in and out connections through all UDP ports,
• allow in through node app's listening port,
• allow routing,
• other common ufw rules like ufw allow out 80, 443, 53, etc

该应用无法连接到 KMS.似乎 WebSocket 握手卡在某种缓冲区中.

the app won't connect to KMS. It seems that the WebSocket handshake is stuck in some kind of buffer.

配置完成后，KMS 将不会连接到应用程序.此外，据我所知，ufw 不会干扰本地主机连接.但是到 ws://localhost:8888/kurento 的连接只是卡在环回中.

As soon as this is configured, the KMS won't connect to the app. Moreover, as far as I know, ufw doesn't interfere in localhost connections. But the connection to ws://localhost:8888/kurento just gets stuck in loopback.

{
    "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. 为了找出根本原因，我使用 简单的 WebSocket 客户端.即使这样也会得到相同的结果；禁用 ufw 时成功连接，启用 ufw 时未连接，超时后收到警报 undefined.

1. When ufw is enabled, all three, incoming, outgoing, routing is allowed without any restriction, then also kms won't connect.
2. To dig up the root cause, I checked the ws_uri connection using Simple WebSocket Client. Even this gives the same outcome; successfully connecting when ufw is disabled, and not connecting when ufw is enabled and getting an alert undefined after the timeout.

KMS 问题

每次连接失败后，无论是使用 Node 应用程序(基本上是节点包 kurento-client) 或 Simple WebSocket Client，我不能简单地禁用 UFW 并完成所有事情.我必须重新启动系统，禁用防火墙(ufw)并启动 kurento-media-server-6.0.即使 sudo service kurento-media-server-6.0 restart 也无济于事.

KMS issue

After every failed connection, either with Node App (basically node package kurento-client) or Simple WebSocket Client, I can't simply disable UFW and get all things done. I have to reboot the system, disable the firewall(ufw) and start kurento-media-server-6.0. Even sudo service kurento-media-server-6.0 restart doesn't help.

tcpdump -vv -i lo 端口 8888 和 '(tcp-syn|tcp-ack)!=0'

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

失败时

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 中发现了类似的问题，其中 issue #623 强调了原因.

Finally, I resolved this issue myself. After very rigorous searching on the internet, I found the similar problem in Websocketpp where issue #623 highlighted the cause.

实际问题是由于不同内核对侦听积压参数的不同解释.Ubuntu 16.04 将值 0 解释为拒绝所有连接，而是使用其默认的积压队列.后来，我发现 kurento-media-server 使用相同的服务(Websocktepp)来处理 websocket 连接.该问题已在提交 0bb33e4 中解决，但它是在 Websocktetpp 的 master 分支(0.70 版)上仍未合并，问题在 Websocketpp 的 develop 分支(0.80-dev)中得到解决.由于 kurento-media-server 仍在使用 master 的稳定版本，因此没有直接的解决方案.

The actual problem was due to varying interpretation of listen backlog parameter by different kernels. Ubuntu 16.04 interpreted the value 0 to reject all the connections, rather using its default backlog queue.Later, I found out that kurento-media-server is using the same service (Websocktepp) for handling the websocket connections. The issue is already resolved in commit 0bb33e4 but it is still unmerged on master branch(version 0.70) of Websocktetpp and the issue is resolved in develop branch(version 0.80-dev) of Websocketpp. Since, kurento-media-server is still using the stable version of master, there was no direct solution to it.

第一个想法是克隆 kms 存储库，解决问题并重建服务.但是测试失败了.

The very first idea was to clone the kms repo, fix the issue and rebuild the service. But the tests failed.

最后，使用以下方法更改 backlog 长度解决了我的问题.

Finally, changing the backlog length using the following solved my issue.

$ echo "net.ipv4.tcp_max_syn_backlog=1024" >> /etc/sysctl.conf
$ sysctl -p

我认为这会覆盖 websocketpp(0.70 版)设置的值.

I think this overrides the value set by websocketpp (version 0.70).

P.S.:我永久启用了 tcp_syn_cookies 以抵抗同步泛滥.

P.S.: I enabled tcp_syn_cookies permanently so as to resist syn flooding.

这篇关于UFW 不允许 Kurento Media Server 6.7 通过 ws_uri 连接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！