直到几个月前,我的 Linux 桌面还充当着家庭网络路由器的双重职责,一切运行正常。
然后我设置了一台小型 Linux 机器作为独立路由器,从那时起,我遇到了很多断开的连接。
类似这样的错误很常见(这个错误发生在 rsync 会话期间):
Write failed: Broken pipe
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: connection unexpectedly closed (1576 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]
我的 IM 会话经常断开并重新连接。SSH 会话中断,有时网页无法加载。
它始终是一个活动连接,已丢弃(与建立新连接时出现的问题相反)。当我的 Internet 连接繁忙时(就活动连接数而言,而不是就带宽而言),这种情况最常发生。例如,运行 bittorrent 会使问题变得更糟,但下载或上传占用 100% 带宽的单个大文件似乎不会引发该问题。我总是可以立即重新连接(尽管新连接也经常很快断开)。
我有一个 8mbit(哈!是的!)的电缆调制解调器连接,来自 Telecable(墨西哥最大的有线电视公司之一)。我以为是他们的服务出了问题,但当我不使用路由器时,并没有遇到这个问题。
因此,我似乎很明显地感觉到我的 Linux 路由器已经达到了某种“最大连接数”限制
我以前在非常繁忙的系统上遇到过类似的问题,增加 netconn_max(或旧内核中的等效值)总能解决问题。但这次似乎不是问题所在。这是在经历了一系列断开连接之后立即发生的:
/proc/sys/net/ipv4/netfilter/ip_conntrack_max: 48324
/proc/sys/net/ipv4/netfilter/ip_conntrack_count: 75
不管怎样,'iptables -L -t nat' 的输出如下:
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere anywhere multiport dports 6881:6999 to:10.0.3.5
DNAT udp -- anywhere anywhere multiport dports 6881:6999 to:10.0.3.5
DNAT tcp -- anywhere anywhere tcp dpt:4380 to:10.0.3.12
DNAT udp -- anywhere anywhere udp dpt:4380 to:10.0.3.12
DNAT tcp -- anywhere anywhere tcp dpt:49181 to:10.0.3.12
DNAT udp -- anywhere anywhere udp dpt:49181 to:10.0.3.12
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
我还需要检查什么?
编辑: 根据要求,平均负载和内存使用情况:
total used free shared buffers cached
Mem: 755 747 8 0 154 504
-/+ buffers/cache: 88 667
Swap: 1903 0 1903
18:32:19 up 4 days, 19:53, 2 users, load average: 0.00, 0.00, 0.00
我还忘了最初包含uname -a
输出:
Linux reep 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 UTC 2011 i686 GNU/Linux
答案1
有趣的是,您的“路由器”所做的一件事是伪装/NAT(如果我读得正确的话)。
如果您的电缆调制解调器通常执行该任务,则其处理出站连接的能力可能会受到以下事实的影响:当路由器打开时,您的“路由器”(之所以用引号表示,是因为它的作用不仅限于路由)另一端的所有内容都具有相同的 IP 地址。换句话说,如果它具有每个主机的连接存储桶,或者其内部连接处理根本无法处理来自单个主机的大量连接,那么电缆调制解调器路由器可能会超载。
测试此问题的一种方法是将路由器配置为仅将数据包推送到电缆调制解调器路由器,而不是进行伪装/NAT。这意味着配置默认路由并告诉内核转发数据包(如果我没记错的话)。如果我没记错的话,问题应该会再次消失。