☰

VPN 路由规则

tag-icon • tag-icon iptables vpn routing
VPN 路由规则

我是网络方面的新手，需要一些帮助。我的设置如下

 ------------         ------------         ------------
|     A      |       |     B      |       |     C      | 
| 10.148.x.x |-------| 10.184.x.x |-------| 192.168.x.x|
|    APP     |       |    VPN     |       |   VPN      |
 ------------         ------------         ------------

我有一个这样的拓扑。其中 B 和 C 以隧道 VPN 站点到站点的方式连接。我想通过 B 将流量（例如 ICMP/API REQ/等）从 A 发送到 C，反之亦然。A 和 C 都将接收来自 B 的传入流量，而不是来自真实来源的流量（因此，例如，当 C PING B 时，B 会将该 PING 定向到 A 并告诉 A ping 的来源来自 B）。在浏览了许多问题之后，我发现这些规则适用于 IPTABLES 并应用于 B。

这是从 A 到 C 的路由：

-A PREROUTING -s 10.148.x.x -d 10.184.x.x -p tcp/icmp -j DNAT --to-destination 192.168.x.x
-A FORWARD -s 10.148.x.x -d 192.168.x.x -p tcp/icmp -j ACCEPT
-A POSTROUTING -o eth0 -j MASQUERADE

这是从 C 到 A 的路由：

-A PREROUTING -s 192.168.x.x -d 10.184.x.x -p tcp/icmp -j DNAT --to-destination 10.148.x.x
-A FORWARD -s 192.168.x.x -d 10.148.x.x -p tcp/icmp -j ACCEPT
-A POSTROUTING -o eth0 -j MASQUERADE

它在普通服务器上运行良好，但在这种情况下：

我使用 TCPDUMP 转储 B 处的流量。当 C PING B 时，流量如下

10:18:04.706713 IP 192.168.x.x > 10.184.x.x: ICMP echo request, id 49458, seq 12987, length 40
10:18:04.706806 IP 10.184.x.x > 10.148.x.x: ICMP echo request, id 49458, seq 12987, length 40
10:18:04.719587 IP 10.148.x.x > 10.184.x.x: ICMP echo reply, id 49458, seq 12987, length 40
this traffic direct to A but its seems like B cannot reply to 192.168.x.x

当 A PING B 时，流量看起来像流量返回 DUP！

64 bytes from 10.184.x.x: icmp_seq=1 ttl=187 time=48.1 ms
64 bytes from 10.184.x.x: icmp_seq=1 ttl=187 time=48.1 ms (DUP!)
64 bytes from 10.184.x.x: icmp_seq=1 ttl=187 time=48.2 ms (DUP!)
64 bytes from 10.184.x.x: icmp_seq=1 ttl=187 time=48.2 ms (DUP!)

来自 man ping：

重复和损坏的数据包

ping 将报告重复和损坏的数据包。重复数据包不应该发生，似乎是由不适当的链路级重新传输引起的。重复可能发生在许多情况下，并且很少（如果有的话）是一个好兆头，尽管低水平的重复可能并不总是引起警报。

损坏的数据包显然是引起警报的严重原因，并且通常表示 ping 数据包路径中（在网络或主机中）的某处有硬件损坏。

我错过了什么？

已编辑：如果我没有清楚地传达问题，我很抱歉。现在我编辑了 IP，因此上面显示的 IP 都是私有 IP，而不是公共 IP。AB 中没有隧道，只有 BC 之间的隧道 VPN。对于这种情况，我的用户只希望 A 和 C 都命中并知道 IP B。因此，A 和 C 都命中 B。

答案1

您让事情变得太复杂了。在您的设置中，您将整个 IP 范围 11.0.0.0/8 映射到 192.0.0.0/8，并在另一个方向上映射到 10.0.0.0/8。这意味着在站点 B，11.0.0.0/8 IP 都无法访问且无法直接使用。

首先，11.0.0.0/8 和 192.0.0.0/8 是存在于互联网内部的公共 IP 范围，不供私人使用。您的电脑如何知道指的是公共 IP 还是私人 IP？

您应该坚持使用专用私有 IP 范围，即 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。这些私有 IP 应该足够了，我怀疑您在每个站点上是否有 2400 万台设备。

如果我是你，我会设置站点到站点 VPN 隧道 AC 是直接的拓扑，这样你就可以将 AC 和 AB 作为单独的隧道。但在某些情况下，这是不可能的/不想要的，我会假设这是其中之一。如果我是你，我会设置具有“可见”IP 的 VPN 隧道：

隧道 AB 路由 192.0.0.0/8，以 B 内的隧道端点作为网关。BC 直接路由 10.0.0.0/8，以 B 内的隧道端点作为网关。这样，您就不必处理 DNAT 规则，所有三个 IP 范围都可以完全使用，并且从所有三个站点都可见。但请记住更改这些子网（例如更改为 10.1.0.0/16、10.2.0.0/16 和 10.3.0.0/16）

[编辑] 而且，如果您真的想让您的设置正常工作，并忽略我的所有警告：您需要删除伪装规则，并将其替换为两个 SNAT 规则。MASQUERADE 目标将所有源 IP 替换为网关的 IP，使得目标无法知道请求来自哪个 IP。这显然不是您想要的...

[编辑2]关于更新后的问题：

a）将 vpn“隐藏”在 B 后面（典型的家庭办公室场景）——这意味着应用程序无法打开与 C 的连接，C 必须打开与 A 的连接。

  • 删除 DNAT 规则
  • 修改 MASQUERADE 规则（您只想在一个方向上伪装流量）：-t nat -A POSTROUTING -s 192.168.0.0/16 -o eth0 -j MASQUERADE

b）将路由连接“发布”到整个应用程序网络：在这种情况下，您将完全删除 DNAT 和 MASQUERADE 规则，并通过路由执行此操作：在站点 A) 上：route add -net 192.168.0.0/16 gw <place IP of B here>10.148.0.0

c) 虚拟 IP 映射方案：此方案背后的想法是创建一个虚拟 IP，用于访问位于私有子网中无法通过其他方式访问的服务器。在此方案中，您需要一个完整的 NAT（DNAT 和 SNAT）和一个未在任何地方使用的 IP。此外，还需要正确的路由……这是最复杂的方案，因为您是网络方面的新手（如您所说），我明确不鼓励使用此解决方案。

相关内容