丟包問題,可能與兩個網路介面 (DHCP) 上的不同網關有關
我正在努力使用一個伺服器,其中我有兩個網路介面連接到兩個不同的網路,每個網路都有不同的網關。我無權訪問交換機配置和 ACL,但“另一方”的說法是“一切都設置得很好”。
配置非常少,
netplan
在 Ubuntu 20.04 伺服器上使用:$ cat /etc/netplan/99_config.yaml network: version: 2 renderer: networkd ethernets: eno1: dhcp4: true eno2: dhcp4: true
這是網路(這是實際配置,沒有任何混淆)
$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether f4:ee:08:10:07:40 brd ff:ff:ff:ff:ff:ff inet 10.131.161.10/24 brd 10.131.161.255 scope global dynamic eno1 valid_lft 20579sec preferred_lft 20579sec inet6 fe80::f6ee:8ff:fe10:740/64 scope link valid_lft forever preferred_lft forever 3: ens1f0np0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether e4:3d:1a:e8:6c:90 brd ff:ff:ff:ff:ff:ff 4: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether f4:ee:08:10:07:41 brd ff:ff:ff:ff:ff:ff inet 10.189.161.110/24 brd 10.189.161.255 scope global dynamic eno2 valid_lft 20579sec preferred_lft 20579sec inet6 fe80::f6ee:8ff:fe10:741/64 scope link valid_lft forever preferred_lft forever 5: ens1f1np1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether e4:3d:1a:e8:6c:91 brd ff:ff:ff:ff:ff:ff
如您所見,兩個不同的網路
10.131.161.10/24
和10.189.161.110/24
兩個介面上。到目前為止一切順利,一切正常,但是……
有時(最後一次是在一個之後,
apt-get upgrade
而目前它只是在一夜之間發生,沒有任何互動),伺服器的網路最終會處於丟包率約為 90% 的狀態。--- ecap-s010 ping statistics --- 485 packets transmitted, 40 received, 91.7526% packet loss, time 490417ms rtt min/avg/max/mdev = 0.222/0.298/0.348/0.025 ms
從那時起,我幾乎無法通過 SSH 進行連接:我必須進行 100 次嘗試,如果幸運的話,我會捕捉到正確路由數據包的一小段時間視窗,這足以建立連接。如果我能做到這一點,我就有一個穩定的 SSH 連接(大部分時間)。
流量轉儲顯示,以某種方式回顯回復來自另一個介面(這是一個不同的網路)!如果我在這種錯誤狀態下 ping
10.131.161.10
,則答案(大多數情況下)會在分配給10.189.161.110
.**擺脫這種狀態的唯一方法是將網路電纜從
ens1f0np0
介面 (10.189.161.110
) 中拔出,然後重新插入。**在那之後,一切都像以前一樣工作了幾天。我想不出任何可以與此相關聯的事件,沒有任何消息dmesg
。唯一真正與互動相關的時間是在我執行時apt-get upgrade
,這可能觸發了一些重新配置,但我不知道它是什麼。其他時候它隨機發生。我沒有任何花哨的 IP 表配置。基本上就是這樣:
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m tcp --dport 3000 -m comment --comment "Grafana" -j ACCEPT -A INPUT -s 10.131.161.0/24 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -s 10.131.161.0/24 -p tcp -m state --state NEW -m tcp --dport 8086 -m comment --comment "Grafana Agents"-j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT
你有什麼想法如何調試這個,或者發生了什麼?
在多宿主主機上,您需要配置路由,以便它知道可以通過哪個介面訪問哪些網路。
在您目前的配置中,每個介面都從它所連接的網段的 DHCP 伺服器接收到一條預設路由。因此,您的伺服器將相信它可以通過兩個介面中的任何一個訪問每個 IP 地址,並且可以在它們之間自由選擇。(除了兩個直接連接的網路 10.131.161.10/24 和 10.189.161.110/24 之一中的地址,它將更喜歡直接連結。)您可以通過使用命令顯示和檢查路由表來驗證這一點
ip route
。但是,正如您所遇到的封包遺失所見證的那樣,這兩個介面中只有一個實際上可以訪問公共網際網路。所以你需要修正你的路由配置來告訴你的伺服器兩個預設路由中哪一個是正確的。一種方法是向文件中添加
route-metric
條目,如https://netplan.io/examples/#connecting-multiple-interfaces-with-dhcp/etc/netplan/99_config.yaml
中的 Netplan 配置範例所示。根據您的網路拓撲,您可能還需要額外的靜態路由。您應該與您的網路團隊討論這個問題。