如何使 iproute2 多个上行链路与伪装一起工作
我在路由 + NAT 方面遇到以下问题： 如果我有两个 ISP，并且在两个 ISP 链路上使用 MASQUERADE 的默认路由中的两个下一跳，我会看到路由缓存已重新生成，但有时发送到新链路（缓存重新生成后）的数据包会使用错误的源地址进行伪装。
这是配置。
我通过两个不同的提供商有两个外部链接：eth1 和 eth2 eth0是局域网
$ ip a（输出的一部分，因为我们还有 3 个接口被禁用）
2：eth1：mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.1.254/24 brd 192.168.1.255 范围全局 eth1
3：eth2：mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.2.254/24 brd 192.168.2.255 范围全局 eth2
6：eth0：mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.5.1/24 brd 192.168.5.255 范围全局 eth0
轮换表：
$ ip r 192.168.5.0/24 dev eth0 原型内核范围链接 src 192.168.5.1
192.168.2.0/24 dev eth2 原型内核范围链接 src 192.168.2.254
192.168.1.0/24 dev eth1 原型内核范围链接 src 192.168.1.254
默认 nexthop 通过 192.168.1.1 dev eth1 权重 1
nexthop 通过 192.168.2.1 dev eth2 权重 1$ ip 第一个 eth1
默认通过 192.168.1.1 dev eth1$ ip 第一个 eth2
默认通过 192.168.2.1 dev eth2
规则：
$ ip ru
0：从所有本地查找
32450：从192.168.2.254查找eth2
32717：从192.168.5.124查找eth1
32766：来自所有查找主
32767：来自所有查找默认
Q1：如果我从 LAN 中的两台 PC：5.137 和 5.147 执行 ping 操作，到同一 IP (195.60.1.1) 他们如何通过不同的链接（ping 195.60.1.1 在两台计算机上运行）？
$ ip rg 195.60.1.1 来自 192.168.5.137 iif eth0
195.60.169.6 来自 192.168.5.137 通过 192.168.1.1 dev eth1 src 192.168.5.1
缓存 mtu 1500 advmss 1460 hoplimit 128 iif eth0$ ip rg 195.60.1.1 来自 192.168.5.147 iif eth0
195.60.169.6 来自 192.168.5.147 通过 192.168.2.1 dev eth2 src 192.168.5.1
缓存 mtu 1500 advmss 1460 hoplimit 128 iif eth0
在我的例子中，路由对于所有用户来说应该是相同的。它应该始终通过相同的链路将数据包发送到相同的目的地（即使源 IP 不同）。不是吗？
Q2：有时我在外部接口上的 tcpdump 中看到路由缓存已重新生成。这可以由ip rft 缓存强制执行。这有时会导致我的 ping 链接发生变化。但两台机器中的一台突然失去连接。从 tcpdump 我发现发生这种情况是因为路由决定使用另一个链接，但 MASQUERADE 没有根据以下内容进行更新：
$ tcpdump -i eth1
IP192.168.2.254> 195.60.1.1：ICMP 回显请求，id 10677，seq 242，长度 64
IP 192.168.1.254> 195.60.1.1：ICMP 回显请求，id 37387，seq 244，长度 64 IP 195.60.1.1> 192.168.1.254：ICMP 回显回复，id 37387，seq 244，长度 64
第二个和第三个数据包是来自/到 5.137 的请求-回复
第一个数据包是来自 .5.147 的请求，其源地址由于 MASQUERADE，该接口在路由缓存清除后未更新 - 因此，没有回复，因为 MASQUERADE 数据包的源地址是错误的。
这是我的假面舞会设置
$ iptables -L -t nat
链 POSTROUTING（策略接受 752K 数据包，48M 字节）
pkts 字节目标 prot 选择输出源目的地
2840K 256M 伪装所有 -- 任何 eth1 192.168.5.0/24 任何地方
2491K 229M 伪装所有 -- 任何 eth2 192.168.5.0/24 任何地方
我知道我可以使用 conntrack 来标记数据包，但它有点复杂。我更喜欢使用目标 IP 作为路由的关键。这种情况下有什么问题吗？为什么路由缓存清除不会通知 NAT 引擎有关路由更改的信息？
I've the following problem with routing + NAT:
If I've two ISP and I'm using two nexthop in default route with MASQUERADE on both ISP links, I see routing cache regenerated, but sometimes packets sent to a new link (after cache regeneration) uses wrong source address for masquerading.
Here is the config.
I've two links to outside via two different providers: eth1 and eth2
eth0 is the LAN
$ ip a (part of output, since we have 3 more interfaces disabled)
2: eth1: mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1
3: eth2: mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.2.254/24 brd 192.168.2.255 scope global eth2
6: eth0: mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.5.1/24 brd 192.168.5.255 scope global eth0
Roting tables:
$ ip r
192.168.5.0/24 dev eth0 proto kernel scope link src 192.168.5.1
192.168.2.0/24 dev eth2 proto kernel scope link src 192.168.2.254
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.254
default
nexthop via 192.168.1.1 dev eth1 weight 1
nexthop via 192.168.2.1 dev eth2 weight 1$ ip r s t eth1
default via 192.168.1.1 dev eth1$ ip r s t eth2
default via 192.168.2.1 dev eth2
Rules:
$ ip ru
0: from all lookup local
32450: from 192.168.2.254 lookup eth2
32717: from 192.168.5.124 lookup eth1
32766: from all lookup main
32767: from all lookup default
Q1: if I do pings from two PC in LAN: 5.137 and 5.147, to the same IP (195.60.1.1) how can they go via different links (ping 195.60.1.1 is run on both computers)?
$ ip r g 195.60.1.1 from 192.168.5.137 iif eth0
195.60.169.6 from 192.168.5.137 via 192.168.1.1 dev eth1 src 192.168.5.1
cache mtu 1500 advmss 1460 hoplimit 128 iif eth0$ ip r g 195.60.1.1 from 192.168.5.147 iif eth0
195.60.169.6 from 192.168.5.147 via 192.168.2.1 dev eth2 src 192.168.5.1
cache mtu 1500 advmss 1460 hoplimit 128 iif eth0
The routing in my case should be the same for all users. it should send packets to the same destination via the same link always (even if the source IP is different). isn't it?
Q2: Sometimes I see in tcpdump on external interfaces that the routing cache was regenerated. This can be forced by ip r f t cache. This sometimes results in change of the link for my pings. But one of two machines suddenly looses connection. From tcpdump I found that this happens because the routing has decided to use another link, but the MASQUERADE was not updated according:
$ tcpdump -i eth1
IP 192.168.2.254 > 195.60.1.1: ICMP echo request, id 10677, seq 242, length 64
IP 192.168.1.254 > 195.60.1.1: ICMP echo request, id 37387, seq 244, length 64
IP 195.60.1.1 > 192.168.1.254: ICMP echo reply, id 37387, seq 244, length 64
The second and third packets are request-reply from/to 5.137
The first packet is the request from .5.147 with wrong source address on that interface due to MASQUERADE not updated after the routing cache purge - hence, no reply, since the source address of the MASQUERADEd packet is wrong.
Here is my MASQUERADE setting
$ iptables -L -t nat
Chain POSTROUTING (policy ACCEPT 752K packets, 48M bytes)
pkts bytes target prot opt in out source destination
2840K 256M MASQUERADE all -- any eth1 192.168.5.0/24 anywhere
2491K 229M MASQUERADE all -- any eth2 192.168.5.0/24 anywhere
I understand that I can use conntrack to mark packets, but it is a little bit more complicated. I would prefer to use destination IP as the key for routing. What is wrong in this scenario? why routing cache purges do not notify NAT-engine about changes in routing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，终于通过搜索引擎找到了答案。
这种特殊行为是 Linux 内核中的一个错误，至少自 2005 年以来就已为人所知。Julian Anastasov 编写了一个补丁来解决此错误（请参阅 http://www.ssi.bg/~ja/#routes)
无论如何，我们发现选择的带有负载均衡和NAT的场景并不好，因为它可能会破坏某些设备的授权站点并导致 Jabber 和 Skype 闪烁，因为路由重新缓存导致每个目的地的路由发生变化（因为我们使用 NAT，外部 IP 也会发生变化，并且 Skype 和其他服务会将您视为从另一台计算机登录）。
在大型办公室中共享多个链接的更好方法是按渠道划分用户。因此，我们为网络中的每台计算机分配了一个首选通道，如果该通道未启动，我们会为该计算机选择任何其他通道。此策略为我们网络中的每台计算机保留相同的外部 IP（NAT 后）。设置首选通道允许我们通过更快的通道发送关键员工，而员工则通过低成本、宽但慢的通道处理大文件。我们使用 4 个频道，因为我们地区的所有 ISP 每周至少会出现两次持续几个小时的故障。
Ok, the answer was finally found using search engines.
This particular behaviour is a bug in the Linux kernel known at least since 2005. Julian Anastasov has written a patch to workaround this error (see http://www.ssi.bg/~ja/#routes)
Anyway, it was found that the chosen scenario with load balancing and NAT is not good, since it may break authorization on some sites and makes Jabber and Skype flicker due to recache of routes resulting in changes of routes for each destination (since we use NAT, the external IP changes too and Skype and other services sees you as logged in from another computer).
Much better way to share multiple links over a big office is to split users by channels. So, we assigned a preferred channel for each computer in our network and if that channel is not up we choose any other channel for the computer. This strategy keeps the same external IP (after NATing) for every computer in our network. Setting up preferred channel allows us to send critical employee via faster channels, while employee dealing with big files over low cos wide but slow channels. We use 4 channels, since all ISP in our region goes down at least 2 times a week for several hours.