我有個問題。我的所有機器都位於連接到數據機上的 ETH 連接埠的路由器後面。該連接埠的下載/上傳功能太有限。因此，我嘗試將兩條電纜從路由器的兩個連接埠連接到調製解調器。我一直在研究如何解決這個問題，但我不知道該嘗試什麼。
我的路由器有4個介面：
enp1s0f0 172.16.0.3
enp4s0f1 10.0.0.6
enp1s0f1 192.168.0.3
enp4s0f0 192.168.0.6
正如你所看到的，eth3 和 eth4 在同一個網路上，這很奇怪。如果我想使用兩個 ETH 連接埠連接到數據機 (192.168.0.1)，就必須採用這種方式。
所以，這是我嘗試過的：
echo "1 myorg" >> /etc/iproute2/rt_tables #added a custom routing table myorg
sudo ip route add 192.168.0.1 scope link dev enp4s0f0 #don't know if it is really necessary
sudo ip rule add from 192.168.0.6 table myorg
sudo ip route add default via 192.168.0.1 dev enp4s0f0 table myorg #second default gateway through myorg table
我得到這些路線的結果：
$ ip -4 route show table main
default via 192.168.0.1 dev enp1s0f1 onlink
10.0.0.0/24 dev enp4s0f1 proto kernel scope link src 10.0.0.6
172.16.0.0/24 dev enp1s0f0 proto kernel scope link src 172.16.0.3
192.168.0.0/24 dev enp1s0f1 proto kernel scope link src 192.168.0.3
192.168.0.0/24 dev enp4s0f0 proto kernel scope link src 192.168.0.6
192.168.0.1 dev enp4s0f0 scope link
$ ip -4 route show table myorg
default via 192.168.0.1 dev enp4s0f0
$ sudo route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 0 0 0 enp1s0f1
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0f1
172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0f0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0f1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0f0
192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 enp4s0f0
我使用ufw作為NAT防火牆。我在 *nat 部分添加：
:POSTROUTING ACCEPT - [0:0]
-A POSTROUTING -s 172.16.0.0/24 -o enp1s0f1 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/24 -o enp4s0f0 -j MASQUERADE
或者，問題是 10.0.0.0 網路中的電腦從數據機（網關 192.168.0.1）接收 ping 回應，或來自 172.16.0.0 網路的電腦。根據具體情況，可能會出現相反的情況，我不知道為什麼。
我的數據機在兩個 ETH 連接埠上看到客戶端 192.168.0.3 和 192.168.0.6。
那麼，是否可以在具有此拓撲（同一網路上有兩個介面的路由器）的所有電腦和所有網路上進行 WAN 存取？
答案1
雖然沒有明確寫入，但我想目標是分割流量，以便：
- 172.16.0.0/24 流量流經 enp1s0f1
- 10.0.0.0/24 流量流經 enp4s0f0
正如OP所寫，這需要基於策略/來源的路由。iptables和網路過濾器很少有用（至少單獨使用）：
- 一般來說iptables和網路過濾器不路由也不關心路由。網路路由堆疊路由。一些iptables' 操作仍會導致路由決策變更（如這裡所述示意圖）
- 進行的任何操作後佈線顧名思義，發生了後路線決定已做出：更改路線為時已晚。在這裡，雖然nat/後路由需要規則，它們不會改變路線。
每當iptables可以避免解決路由問題，最好避免它。有時它是無法避免的（然後通常iptables用於向資料包添加標記，並且該標記用於ip rule條目中）。
路線
我會假設rp_filter=1在所有介面上設置，因為它是大多數發行版的預設設置，以啟用嚴格反向路徑轉送。
來源位址由規則選擇，目的地由路由表選擇。當只應選擇多個路由中的一個時（然後僅將這一個添加到表中），附加路由表應具有足夠的資訊來覆蓋（無歧義）路由。通常也必須複製主表中的其他路由，否則可能會發生不好的事情。
在我的回答中，我不會優先考慮一個網路或另一個網路：每個網路都會有自己的路由表。我將忘記表 1，並使用表 10 表示 LAN 10.0.0.0/24，使用表 172 表示 LAN 172.16.0.0/24。保留 NAT 規則，刪除規則和附加路由表，以及192.168.0.1 dev enp4s0f0 scope link從 main.conf 中刪除規則和附加路由表。
10.0.0.0/24 <--> 10.0.0.6 enp4s0f0 | 的路由enp4s0f1 192.168.0.6 <--> 192.168.0.1/預設：
ip rule add from 10.0.0.0/24 lookup 10 ip route add table 10 10.0.0.0/24 dev enp4s0f1 ip route add table 10 192.168.0.0/24 dev enp4s0f0 src 192.168.0.6 ip route add table 10 default via 192.168.0.1
上面，如果沒有 10.0.0.0/24 的重複路由條目，系統本身將無法存取此 LAN：它將解析該路由，因為必須經過預設網關，僅適用於嚴格反向路徑轉送(SRPF) 的目的使得調試變得困難。如果不添加的話，這就是一個壞事的例子。如有疑問，只需重複路線即可。
其他等效選項可以代替將上述規則更改為的附加路線：
ip rule add from 10.0.0.0/24 iif enp4s0f1 lookup 10
因此它不會匹配本地（非路由）流量，並且只會使用主表。
172.16.0.0/24 <--> 172.16.0.3 enp1s0f0 | 的路由enp1s0f1 192.168.0.3 <--> 192.168.0.1/預設：
ip rule add from 172.16.0.0/24 lookup 172 ip route add table 172 172.16.0.0/24 dev enp1s0f0 ip route add table 172 192.168.0.0/24 dev enp1s0f1 src 192.168.0.3 ip route add table 172 default via 192.168.0.1在 Linux 系統上變更傳出來源 IP 位址時，也可以變更本地發起的傳出流量的路由（連結）。這應該是可選的，但關於 ARP 流量的下一部分將其強制執行：
ip rule add from 192.168.0.6 lookup 10 ip rule add from 192.168.0.3 lookup 172任何涉及規則中覆蓋路由的非特殊情況也必須重複
這裡唯一缺少的路由是兩個特殊 LAN 本身之間的路由：
表 10 中達到 172.16.0.0/24
表 172 達到 10.0.0.0/24
因為每個附加表還沒有到另一端的路由，所以它將使用預設路由（但會再次被 SRPF 阻止），從而防止兩個特殊網路之間再進行通訊。因此，只需為每個表複製缺少的路由即可：
ip route add table 10 172.16.0.0/24 dev enp1s0f0
ip route add table 172 10.0.0.0/24 dev enp4s0f1
使用此模型，如果要添加另外兩個“正常”內部網絡，它們可以在彼此之間進行通信（並且將使用主表的預設路由到外部），而無需額外設置，但再次需要在每個附加路由表用於與兩個特殊LAN 進行通訊。
現在路線已經很好了，但還有...
這ARP通量問題
Linux 遵循弱宿主模型。 IP 路由就是這種情況，Linux 應答 ARP 請求的方式也是如此：來自任何介面的任何 IP，但當然使用介面自己的 MAC 位址。由於當多個介面位於同一 LAN 上時，這可能會同時在所有介面上發生，因此通常最快的獲勝。然後 ARP 資訊會緩存在遠端系統上，並會在那裡保留一段時間。最終快取過期，同樣的情況也會發生，但結果可能不同。那麼這怎麼會導致問題呢？這是一個例子：
- 路由器（數據機）向 192.168.0.6 發送 ARP 請求，以發回最初從 10.0.0.0/24 發送的流量的路由和 NAT（透過 Linux）回應。
- Linux 回覆於enp1s0f1（enp1s0f1贏得比賽）使用enp1s0f1的 MAC 位址回覆告訴它有 192.168.0.6。
- 在幾秒鐘到幾分鐘內，來自 192.168.0.6 的路由器的未來入口 IP 封包到達enp1s0f1,
- 同時出口來自 192.168.0.6 的資料包使用enp4s0f0。
這種非對稱路由被捕獲嚴格反向路徑轉送（rp_filter）並且流量將會失敗。這甚至可能會隨機工作幾秒鐘，然後再次失敗。根據整體流量，問題甚至可能稍後切換到其他連結（然後問題切換到其他 LAN）。
幸運的是，為了防止這種情況發生，Linux 提供了一個僅與策略路由一起使用的設置，以使 ARP 遵循路由定義的相同規則：arp_filter。
arp_filter - 布林值
1 - 允許您在同一子網路上擁有多個網路接口，並為每個接口提供 ARP介面回答基於核心是否會將來自 ARP 的 IP 的封包路由到該介面（所以您必須使用基於來源的路由為了這個工作）。換句話說，它允許控制哪些卡（通常是 1 個）將回應 arp 請求。
sysctl -w net.ipv4.conf.enp4s0f0.arp_filter=1
sysctl -w net.ipv4.conf.enp1s0f1.arp_filter=1
現在 ARP 行為是正確的，如果設定剛剛到位，應該強制刷新 ARP 快取同行（此處：調製解調器）透過執行重複位址檢測arping（從iputils/iputils-arping）它將向對等點廣播並讓他們更新快取：
arping -c 5 -I enp4s0f0 -D -s 192.168.0.6 192.168.0.6 &
arping -c 5 -I enp1s0f1 -D -s 192.168.0.3 192.168.0.3
請注意，上一部分第 3 條中的兩條規則現在是強制性的，因為 IP 位址 192.168.0.3 和 192.168.0.6 必須在策略路由規則中匹配，才能正確解析 ARP arp_filter=1。
如何偵錯
ip route get對於檢查路由和反向路徑過濾非常有用：
上面第 4 點的新測試案例：
# ip route get from 10.0.0.111 iif enp4s0f0 172.16.0.111
172.16.0.111 from 10.0.0.111 dev enp1s0f0 table 10
cache iif enp4s0f0
# ip route get from 172.16.0.111 iif enp1s0f0 to 10.0.0.111
10.0.0.111 from 172.16.0.111 dev enp4s0f1 table 172
cache iif enp1s0f0
刪除規則或路由時：
# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp4s0f0 table 10
cache iif enp4s0f1
# ip rule del from 10.0.0.0/24 lookup 10
# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp1s0f1
cache iif enp4s0f1
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
local 192.168.0.6 from 192.168.0.1 dev lo table local
cache <local> iif enp4s0f0
# ip rule delete from 192.168.0.6 lookup 10
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
RTNETLINK answers: Invalid cross-device link
這顯示了結果如何根據（缺乏）規則和附加路線而改變。最後的結果是錯誤訊息，告訴反向路徑轉送檢查失敗（=>丟棄）。
然後有ip neigh（最有用的同行系統）來檢查 ARP 條目tcpdump等。