☰

只能直接连接，不能通过路由器连接

tag-icon • tag-icon networking dd-wrt
只能直接连接，不能通过路由器连接

我当地的住房互联网提供商刚刚改变了政策，他们似乎阻止路由器工作1。

我的设置（已经运行了一年）：

[ISP router (in the residence, out of my reach)] -- My DD-WRT router -- PC

-- : RJ45 cable connection

到目前为止，它已经停止工作了。经过一些测试，我发现了以下情况：

  • 路由器与 PC 之间的连接似乎正常（我可以通过 SSH 访问其 Web 界面）
  • 路由器-ISP 连接似乎正常（通过 SSH 连接到我的路由器，我可以 ping 8.8.8.8/8.8.4.4）
  • PC-路由器-ISP 连接不起作用（甚至无法 ping 8.8.8.8/8.8.4.4）

我想了解 ISP 是否可以通过这种方式阻止连接，以及是否有办法避免这种情况2。

1 这一改变显然是为了防止人们同时使用多台设备。这是一条从未宣布过的武断规定。他们之所以能做到这一点，是因为他们垄断了我的学生宿舍。

2 我不认为这是未经授权的，因为我从未签署任何服务条款，也不必接受任何最终用户许可协议。我搬进来的那天，我插上了路由器，从那时起它就一直在工作。我付房租，我的住所付钱给 ISP，因此垄断了。

有关我的设置的详细信息

我使用的是 DD-WRT 的标准网关配置。这似乎是一对多 NAT，因为本网站说：

要禁用 NAT 并仍保留其路由/防火墙，您可以将操作模式更改为“路由器”而不是“网关”（位于高级路由中）

和这个 DD-WRT 维基页面解释如何配置一对一 NAT，因此我的默认配置应该是一对多 NAT。

这是正确的吗？如果已经是这样，我的 ISP 是否能够以某种方式检测出我是否在使用直接连接？我认为手动将路由器数据包的 TTL 设置为 1 会产生这种效果，但我不确定。

编辑：也许我理解错了，但 TTL 可能是罪魁祸首。以下是结果ping 8.8.8.8：

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=1 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=1 time=3.52 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=1 time=21.1 ms

请注意，TTL 字段始终为 1。

但是我之前从来没有注意过这一点。这正常吗？否则我可以让 DD-WRT 增加它吗？

答案1

事实证明，问题确实是由 TTL 引起的！以下是常见问题解答，希望对其他人更有用。

为什么我的连接只能通过直连电缆进行，而不能通过路由器进行？我的路由器工作不正常吗？

如果你的情况和我一样，路由器以前（现在）工作正常。问题是我的 ISP 刚刚实施了TTL 限制。

什么是 TTL 节流？

TTL 节流包括设置 TTL（生存时间) 为 1，以防止使用路由器：来自 WAN（Internet）的所有数据包在到达 PC 之前都会被丢弃（因为它们的 TTL 变为 0）。

如何检测 TTL 节流？

使用直接电缆连接时（应该可以正常工作），尝试 ping 任何服务器，最好通过 IP 来避免 DNS 问题。Google 的公共 DNS 服务器很容易记住，所以我经常这样做：

ping 8.8.8.8

结果将包含一个字段ttl（或TTL在 Windows 上）：

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=1 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=1 time=3.52 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=1 time=21.1 ms

在这个例子中，TTL 正好是 1。在实践中，如果没有 TTL 限制，发生这种情况的可能性几乎为零。ttl=1表明你的 TTL 正在受到限制。

如何规避 TTL 限制？

您需要配置路由器，以便它能够修改传入数据包的 TTL，将其增加到更高的值（例如，64），以便数据包在到达连接到路由器的设备之前不会被丢弃。

不幸的是，具体细节将取决于每个路由器/固件。我的路由器上安装了 DD-WRT，所以我使用iptables规则来配置它。

经过多次尝试，我最终成功定义了一条适合自己的规则，但每个固件版本可能不同！您可能需要尝试几种组合才能找到一种可行的组合。

关于配置 DD-WRT iptables 以取消 TTL 限制的一般技巧

  • 如果可以，使用 SSH 命令行连接路由器。它速度更快，并且会给出错误命令的反馈；
  • 您可能必须了解 iptables 语法才能修复命令，使其适合您；
  • 我仍然不太了解它，而且我厌倦了尝试，所以我只是坚持第一个有效的方法，尽管它可能不是最好的。

以下是我添加到 DD-WRT 启动脚本的命令：

iptables -v -t mangle -A OUTPUT -j TTL --ttl-set 60
iptables -v -t mangle -A PREROUTING -j TTL --ttl-set 63

他们在某种程度上几乎肯定是错误的，但重要的部分是：

  • 总是用来-v获得详细输出；将会指示不正确的命令；
  • 避免使用-n（用于数值，即IP输出）；尽管在 DD-WRT 的 Iptables 页面中提到过，这个选项似乎不存在于我的 DD-WRT 版本中，导致静默错误。我只有在$?命令后回显时才注意到它，结果是 255 而不是 0。删除此选项后，我才看到错误消息；
  • 为了在 PC 上没有可用的 Internet 连接的情况下进行快速测试，您可以ping在控制台上让命令在 PC 上运行，同时iptables在另一个控制台上尝试这些命令。默认情况下，我的路由器会回复ttl=64，但当我得到一个有效的规则时，我可以立即看到 ping 返回新值（这就是为什么我在示例中没有使用 64）使用OUTPUT链条时（否则，对于实际的互联网连接来说是没有必要的）；
  • 有些人提到链条PREROUTING，其他人提到INPUT。我不确定两者的区别，但PREROUTING对我来说似乎效果更好。

不幸的是，这仍然不理想：每隔一小时左右，我的连接似乎就会被重置，所以我必须手动更新 iptables 规则。

笔记：我对此几乎一无所知iptables，因此欢迎任何有关更好规则的建议（我将对其进行测试并进行相应的更新）。

Windows/Mac 互联网共享

如果你使用 Windows/Mac 电脑作为路由器（例如使用你的 PC/笔记本电脑与其他设备共享你的互联网连接），那么 Connectify 等软件（自 7.1 版起）根据他们的网站) 还可以绕过 TTL 限制。

Connectify 调用此设置避开酒店/NAT 限制。默认情况下，它是活动的，这可以解释为什么没有那么多人抱怨互联网上的 TTL 限制：Windows 用户最终大多使用 Connectify，而没有问它为什么有效。然而，这可以解释为什么 Windows 的标准互联网连接共享可能无法开箱即用。

最后要说的是...

我是否应该对避免 TTL 限制感到难过？

可能不会，特别是如果你的 ISP（比如我的）(1) 已经进行了带宽限制，(2) 引入了 TTL 限制但从未宣布过，并且 (3) 显然只对欺骗用户感兴趣，而不是改善服务。人为地通过“欺骗”（伪造 TTL）删除标准功能是作弊），但要收取双倍的费用才能放回去，非常卑鄙的举动。

相关内容