![AT&T U-verse IRC、SSH 等会话中断](https://linux22.com/image/558407/AT%26T%20U-verse%20IRC%E3%80%81SSH%20%E7%AD%89%E4%BC%9A%E8%AF%9D%E4%B8%AD%E6%96%AD.png)
AT&T U-verse 光纤 24Mbit 下行/3Mbit 上行
2Wire 路由器型号 3800HGV-B
软件版本 6.1.9.24-enh.tm
我们的速度和广告宣传的一样。AT&T 的网络连接速度很快。问题不在于速度。
问题是我们与公共互联网上的远程主机的 IRC 和 SSH 会话最多持续几秒钟或几分钟。2Wire 上的 TCP 会话超时配置为 86400。与我们 LAN 上的服务器的 SSH 会话表现正常。我们的 LAN 没有出现成为问题。问题出现是 2Wire 路由器。我无法在 2Wire 路由器上获取 shell,因此无法在那里运行 tcpdump 等。LAN 上的 Tcpdump 显示每个会话中断都是由远程服务器发起的 TCP 重置引起的。根据我的理解,通过谷歌搜索,发送 TCP 重置是因为远程主机认为 TCP 会话出了问题,这再次让我怀疑 2Wire 路由器上发生了什么。从多种类型的其他互联网连接、移动网络共享、时代华纳有线电视、我们另一个办公室的 T1 等到这些相同的远程服务器的 IRC 和 SSH 会话都按预期运行,没有任何问题。
在我们切换到 AT&T 并开始使用 2Wire 之前,所有这一切都运行正常。我们使用 AT&T 的整个时间(至今已有 2 周)都遇到了这个问题。
在高峰时段,我们办公室大约有 50 台设备使用此互联网连接,包括笔记本电脑、台式机、移动设备。在我们的 LAN 上,我尝试了几种已知可以正常工作的(与其他提供商合作)托管交换机等。我尝试让每个人都只连接到 2Wire 无线 SSID 等。所有这些隔离问题的尝试都无法改变问题,问题似乎指向了 2Wire 路由器。
一般来说,当办公室里人很少时,我们的 IRC 和 SSH 会话会持续更长时间,超过几分钟。有时会话仍会在 5 秒内结束,但如果办公室里只有我一个人,有时我可以保持会话打开 10 分钟或更长时间。
如果问题出在 2Wire 路由器上,我不确定是什么问题,也不知道该如何解决。我甚至不知道如何排除故障并找出问题所在。
在我们的 LAN 上捕获的 SSH 会话断开的 tcpdump 输出,从远程服务器发送了 TCP 重置:
10:51:33.357748 IP (tos 0x10, ttl 63, id 11177, offset 0, flags [DF], proto TCP (6), length 52)
2wire.ip.53096 > remote.server.ip.22: Flags [.], cksum 0xd8bb (correct), seq 3878, ack 3193, win 65535, options [nop,nop,TS val 904726345 ecr 194200103], length 0
10:51:33.357757 IP (tos 0x10, ttl 63, id 54768, offset 0, flags [DF], proto TCP (6), length 52)
2wire.ip.53096 > remote.server.ip.22: Flags [.], cksum 0xd86b (correct), seq 3878, ack 3273, win 65535, options [nop,nop,TS val 904726345 ecr 194200103], length 0
10:51:33.456382 IP (tos 0x10, ttl 63, id 37832, offset 0, flags [DF], proto TCP (6), length 100)
2wire.ip.53096 > remote.server.ip.22: Flags [P.], seq 3878:3926, ack 3273, win 65535, options [nop,nop,TS val 904726346 ecr 194200103], length 48
10:51:33.493452 IP (tos 0x0, ttl 48, id 35965, offset 0, flags [DF], proto TCP (6), length 100)
remote.server.ip.22 > 2wire.ip.53096: Flags [P.], seq 3273:3321, ack 3926, win 157, options [nop,nop,TS val 194200137 ecr 904726346], length 48
10:51:33.493757 IP (tos 0x0, ttl 48, id 35966, offset 0, flags [DF], proto TCP (6), length 132)
remote.server.ip.22 > 2wire.ip.53096: Flags [P.], seq 3321:3401, ack 3926, win 157, options [nop,nop,TS val 194200137 ecr 904726346], length 80
10:51:33.494297 IP (tos 0x10, ttl 63, id 12429, offset 0, flags [DF], proto TCP (6), length 52)
2wire.ip.53096 > remote.server.ip.22: Flags [.], cksum 0xd7e7 (correct), seq 3926, ack 3321, win 65535, options [nop,nop,TS val 904726347 ecr 194200137], length 0
10:51:33.494485 IP (tos 0x10, ttl 63, id 28130, offset 0, flags [DF], proto TCP (6), length 52)
2wire.ip.53096 > remote.server.ip.22: Flags [.], cksum 0xd797 (correct), seq 3926, ack 3401, win 65535, options [nop,nop,TS val 904726347 ecr 194200137], length 0
10:53:04.123228 IP (tos 0x0, ttl 255, id 48599, offset 0, flags [DF], proto TCP (6), length 40)
remote.server.ip.22 > 2wire.ip.53096: Flags [R.], cksum 0x9bbf (correct), seq 3401, ack 3926, win 0, length 0
有其他人遇到过这个问题,解决过这个问题吗?或者有人对故障排除、识别和解决问题有什么建议吗?
更新:
首先非常感谢您阅读这个长问题并给予答复。+1
我也对 NAT 转换表有所怀疑,但显然怀疑程度不够。我曾猜测 2Wire 或任何设备都可以处理 2^16 个会话。但我猜错了:
我之前没有看到 2Wire 上的会话表,但是根据您的建议我去寻找它,并且很容易找到:
session table 15/1024 available, 0/512 used in inbound sessions:
上面的会话表详细信息来自下午某个时间,当时我们办公室大约有四分之一的人没有坐在办公桌前使用电脑,而我们的并发会话数已接近 1024 个的限制。
另外,谷歌搜索“uverse 会话表”也给了我一些有用的搜索结果。
答案1
作为一个家用设备,我最初的直觉反应是它无法支持所有并发的 TCP 连接和 NAT 转换(以及为超出限制的数据包伪造重置数据包)。
我很难找到该设备的规格来证实我的怀疑,但在寻找它们的过程中,似乎有很多轶事证据支持该理论。
有什么办法可以检查正在运行多少个连接?
答案2
说实话,您已经通过故障排除解决了所有问题。我会打电话给 ATT,让他们对连接进行诊断,重点关注第 1 层和第 2 层问题。您有权访问网关吗?它是否为您提供了任何类型的诊断来解决问题?
我知道这是一项不同的技术,但当我支持 DSL 时,有时如果客户端距离 DSLAM 太远,并且存在导致衰减的布线问题,您会看到类似的情况。我会从网关开始(直接插入,没有无线!)然后解决问题。如果这是一条商务级线路,ATT 应该能够从他们的一线团队一直到 NOC 为您排除故障,看看是否存在问题。