為什麼 arp_ignore=1 會破壞 POINTOPOINT 介面上的 ARP？（kvm客人）

如果我在 kvm 來賓上添加以下設置：

net.ipv4.conf.all.arp_ignore=1

訪客網路停止（高度間歇性）。

kvm 主機使用橋接網路：

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto {{ vbox_interface }}
iface {{ vbox_interface }} inet static
 address {{ vbox_main_ipv4 }}
 netmask {{ vbox_ipv4_netmask }}
 gateway {{ vbox_ipv4_gw }}
 pointopoint {{ vbox_ipv4_gw }}

iface {{ vbox_interface }} inet6 static
 address {{ vbox_main_ipv6 }}
 netmask 128
 gateway {{ vbox_ipv6_gw }}

auto  br0
iface br0 inet static
address   {{ vbox_main_ipv4 }}
netmask   255.255.255.255
bridge_ports none
bridge_stp off
bridge_fd 0
bridge_maxwait 0
{% for ip in vbox_addtl_ipv4 %}
up route add -host {{ ip }} dev br0
{% endfor %}

iface br0 inet6 static
 address {{ vbox_main_ipv6 }}
 netmask 64

這是為什麼？

正如邁克爾在評論中指出的那樣，一些背景：

• 我確實了解arp_ignore（http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP）的基本要點 - 我主要想保留該設置，因為我在不受信任的網路中
• 我明白網路的設置可能不是標準的，這是因為我遵循了這個：https ://wiki.hetzner.de/index.php/KVM_mit_Nutzung_aller_IPs_-_the_easy_way/en - 這允許我使用所有 IP我給定的子網
• 我確實了解arp_ignore=0來賓 VM 上的設置將解決該問題。但是我想知道為什麼（因為我不需要在主機本身上這樣做）並且我不能接受它作為答案，因為我不相信設置它會導致網路離線（例如我想解決問題而不設置依賴項）
• 我假設（感謝 Peter Zhabin）使用網路遮罩 255.255.255.255 足夠安全，不受信任的網路中的任何人都可以利用 arp？

所以我想我的問題是：

當 kvm-guest 使用 pointopoint/255.255.255.255 時，為什麼會arp_ignore=1破壞 kvm-guest <> kvm-host 網路？

編輯 23/10/2018：訪客界面配置

# The loopback network interface
auto lo
iface lo inet loopback

auto ens7
iface ens7 inet static
 address IP from the pool {{ vbox_addtl_ipv4 }}
 netmask 255.255.255.255
 gateway {{ vbox_main_ipv4 }}
 pointopoint {{ vbox_main_ipv4 }}

iface ens7 inet6 static
 address xxx::xxx
 netmask 64
 gateway {{ vbox_main_ipv6 }}

我已經在沒有任何網橋、KVM 或 Hetzner 的 Ubuntu 18.04 上驗證了這種行為，我認為這實際上是關於處理arp_ignore點對點乙太網介面的核心錯誤。驗證步驟：

1. 通過完全禁用它來確保netplan不會干擾。
2. 設置兩個系統，乙太網介面相互連接，IP 地址分配如下：

伺服器 A：

ip addr add 192.168.100.1/32 peer 192.168.100.2 dev ens33

ip link set ens33 up

伺服器 B：

ip addr add 192.168.100.2/32 peer 192.168.100.1 dev ens33

ip link set ens33 up 3. 觀察從伺服器 A 到伺服器 B 的正常 ping 以及ip addr show包含此行的輸出：

inet 192.168.100.1 peer 192.168.100.2/32 scope global ens33 4. 在伺服器 A 上啟用arp_ignore=1withsysctl net.ipv4.conf.all.arp_ignore=1並看到 ping 在 ARP 條目超時後立即停止。一段時間後，ping將恢復一段時間，然後再次結束。這個過程將以這種方式無限期地繼續下去。 5. 在伺服器 B 上執行 atcpdump並觀察who-has來自伺服器 B 的對伺服器 A IP 地址的入站 ping 和出站無休止請求，但沒有響應。有時，伺服器 A 會who-has向伺服器 B 發出 IP 請求，會得到回复，伺服器 B 會暫時記憶體從該 ARP 請求中獲得的源 MAC 地址，這是 ping 恢復的時候。

現在，這就是發生的事情。點對點和標準廣播介面在如何iproute2（和類似工具）in_ifaddr填充include/linux/inetdevice.h.

對於普通介面，它的ifa_address欄位填充有本地介面地址；對於點對點介面ifa_address，使用遠端對等地址ifa_local填充並使用本地介面地址填充。

這是正常和預期的行為，因為在過去，任何點對點介面都被認為是附加的遠端設備本身；與之對應的本地端點地址甚至可能不存在。所以這裡沒有任何問題。

真正壞的是，間接使用定義的arp_ignore()處理程序定義的函式迭代地嘗試將ARP請求的目標IP地址（即本地介面地址）與介面上所有配置的IP地址記錄的欄位匹配。net/ipv4/arp.c``confirm_addr_indev()``net/ipv4/devinet.c``ifa_address

這在標準介面上執行良好，因為它們確實在ifa_address欄位中記錄了本地 IP 地址，但是對於點對點介面，它會失敗，因為它們在此欄位中記錄了對等 IP 地址。

現在，真正的問題是這個問題真的需要修復嗎，因為已經指出arp_ignore在 p2p 連結上使用沒有意義。我認為確實如此，因為可能存在所討論的主機具有多個介面（並且這些介面不是 p2p 介面）的情況，並且有人可能會啟用帶有conf.all前綴的東西，只是為了看到他的 p2p 連結無緣無故地關閉.

引用自：https://serverfault.com/questions/935366