UFW 不允许 Kurento Media Server 6.7 通过 ws_uri 连接

Question

问题

我在 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 不会干扰本地主机连接。但是与ws://localhost:8888/kurento 的连接只是卡在了环回中。

安装源link

配置文件 (/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. 为了找出根本原因，我使用Simple WebSocket Client 检查了ws_uri 连接。即使这样也给出了相同的结果；禁用 ufw 时连接成功，启用 ufw 时无法连接并在超时后收到警报 undefined。

KMS 问题

在每次连接失败后，无论是使用 Node 应用程序（基本上是节点包 kurento-client）还是简单的 WebSocket 客户端，我都不能简单地禁用 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'

成功时

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

Answer 1

最后，我自己解决了这个问题。经过网上非常严格的搜索，我在Websocketpp发现了类似的问题，其中问题#623突出了原因。

实际问题是由于不同内核对侦听积压参数的不同解释。 Ubuntu 16.04 将值 0 解释为拒绝所有连接，而不是使用其默认的积压队列。后来，我发现 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，以防止同步泛滥。