我遇到了類似的問題這個問題是關於區域網路IP錯誤的。然而，NIC 上的標準 addr 別名技巧並沒有幫助。我無法直接訪問伺服器控制台，如果幸運的話，我可能會在一周或更長時間內獲得實體存取權限，但我希望我能找到更快的方法。
我可以在（據稱）同一 L2 網段上10.0.0.1的伺服器（Linux，帶有 IP ）位址上對（Linux）伺服器進行 arping ，它會回复該伺服器的正確且預期的 MAC$MY_IP$TARGET_MAC
root@host:~# arping -c 3 -I $IFACE 10.0.0.1
ARPING 10.0.0.1 from $MY_IP $IFACE
Unicast reply from 10.0.0.1 [$TARGET_MAC] 0.746ms
Unicast reply from 10.0.0.1 [$TARGET_MAC] 0.796ms
Unicast reply from 10.0.0.1 [$TARGET_MAC] 0.807ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)
我隱藏了我的 IP 和 MAC，因為這些機器可以公開存取。
如果我為該介面新增位址別名，我仍然可以 arping 目標，但無法 ping 它。沒有其他介面具有 10.0.0.0/24 範圍，即使使用ping -I $IFACE.
root@host:~# ip addr add 10.0.0.2/24 dev $IFACE
root@host:~# arping -c 3 -I $IFACE 10.0.0.1
ARPING 10.0.0.1 from 10.0.0.2 $IFACE
Unicast reply from 10.0.0.1 [$TARGET_MAC] 0.788ms
Unicast reply from 10.0.0.1 [$TARGET_MAC] 0.766ms
Unicast reply from 10.0.0.1 [$TARGET_MAC] 0.794ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)
root@host:~# ping -c 3 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
--- 10.0.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms
目標伺服器監聽 SSH 連接，但 ssh 打不通
root@host:~# ssh -vvv 10.0.0.1
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.0.0.1 [10.0.0.1] port 22.
debug1: connect to address 10.0.0.1 port 22: Connection timed out
ssh: connect to host 10.0.0.1 port 22: Connection timed out
我嘗試透過向目標發送 ARP REPLY 封包來強制目標更新其 ARP 表，但這似乎沒有幫助。
root@host:~# arping -A -c 3 -s 10.0.0.2 -I $IFACE 10.0.0.1
ARPING 10.0.0.1 from 10.0.0.2 $IFACE
Sent 3 probes (3 broadcast(s))
Received 0 response(s)
root@host:~# ping -c 3 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
--- 10.0.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms
有可能存在一些 L3 元件，因為伺服器向我發送了電子郵件更新（apt-listchanges輸出），但電子郵件標頭包含分配給某個交換器的 IP，但標頭中的主機名稱是正確的（目標主機名稱） 。其他管理員告訴我，它應該位於同一個 L2 網段，而 arping 似乎表明了這一點。還有其他方法可以排除 L3 組件嗎？
目標是建立與目標伺服器的 SSH 連接，以便我可以解決問題。
答案1
顯然您在同一個 L2 乙太網路區段上，使用相同範圍內的 IP 1 和 2。我可以想到它不起作用的兩個原因：
- 具有 IP 的伺服器
10.0.0.1具有某種活動的第 3 層過濾功能（最有可能是 IPTable）並丟棄您正在發送的 ICMP 封包，儘管一切都已正確設定以使其在網路角度上運作。嘗試其他探測（ssh、telnet、http或任何已知在伺服器上偵聽的網路服務）。 - 無論出於何種原因，您的
ping探測都不會透過 $IFACE 離開（例如，如果在另一個介面上也配置了相同的 IP 範圍）。嘗試使用ping -i $IFACE