0

问题

在本地网络的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只是卡在环回中。

安装源码链接

配置文件 ( /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 Clientws_uri检查了连接。即使这样也给出了相同的结果；禁用 ufw 时连接成功，启用 ufw 时未连接并在超时后收到警报。undefined

知识管理系统问题

在每次连接失败后，无论是使用 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'

成功时

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
4

1 回答 1

4

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

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

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

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

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

我认为这会覆盖 websocketpp（版本 0.70）设置的值。

PS：我tcp_syn_cookies永久启用以抵抗同步泛洪。

于 2018-02-08T16:37:14.080 回答