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

Question

问题

在 Ubuntu 16.04 中为 local 配置 kurento-media-server（版本 6.7.0）的 UFW 时，我遇到了非常奇怪的经历网络。我的节点应用程序和 KMS 都安装在同一台服务器上，运行在不同的端口上。在禁用 UFW 的情况下，该应用程序运行良好，并且节点应用程序与 KMS 配合得很好。现在，我激活 ufw 并将其配置为

允许进出kurento-media-server监听端口(8888)
允许通过所有 UDP 端口进出连接，
允许通过 node 应用程序的侦听端口、
允许路由,
其他常见的 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 进行实验：

启用 ufw 时，传入、传出、路由这三个都可以不受任何限制地允许，那么 kms 也不会连接。
为了找出根本原因，我使用 Simple WebSocket Client 检查了 ws_uri 连接。即使这样也会产生相同的结果；禁用 ufw 时成功连接，启用 ufw 时未连接并在超时后收到警报 undefined。

KMS 问题

每次连接失败后，无论是使用节点应用程序（基本上是节点包 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 where issue #623 highlighted the cause.

中找到了类似的问题。

实际问题是由于不同内核对 listen backlog 参数的不同解释。 Ubuntu 16.04 将值 0 解释为拒绝所有连接，而不是使用其默认积压 queue.Later，我发现 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来抵抗syn flooding.

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

UFW not allowing Kurento Media Server 6.7 to get connected through ws_uri

node.js

websocket

kurento

ufw

问题

安装源link

配置文件 (`/etc/kurento/kurento.conf.json`)

使用 UFW 进行实验：

KMS 问题

tcpdump 输出：

成功时

失败时

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

UFW not allowing Kurento Media Server 6.7 to get connected through ws_uri

node.js

websocket

kurento

ufw

问题

安装源link

配置文件 (/etc/kurento/kurento.conf.json)

使用 UFW 进行实验：

KMS 问题

tcpdump 输出：

成功时

失败时

配置文件 (`/etc/kurento/kurento.conf.json`)