Es gibt vielfältige Gründe für eine solche fehlerhafte Konfiguration, darunter häufig
- fehlerhaft konfigurierte Ethernet-Bridges
- fehlerhaft konfigurierte VPN-Dienste/Server
- fehlerhaft konfigurierte Netzwerk-Geräte
- fehlerhaft konfigurierter Linux-Kernel bei mehreren Netzwerk-Karten
Überprüfen des Problems
Um zu überprüfen, ob das Problem weiterhin besteht, können Sie ein
arping
auf das externe Netzwerk-Interface Ihres Servers, z.B. eth0 oder ifext, und private IP-Adressen machen:arping -c 1 -I [eth0/ifext] 10.0.0.1
Es ist wichtig, nicht nur eine private IP-Adresse zu "pingen", sondern möglichst alle privaten IP-Adress-Bereiche nach RFC 1918, siehe dazu auch den Wikipedia-Beitrag zu privaten IP-Adressen.
Dies lässt sich z.B. mittels
seq
durchführen, z.B.for i in $(seq 1 254); do arping -c 1 -I [eth0/ifext] 10.$i.0.1; done
Das vorgenannte Mini-Skript ist nicht vollständig sondern dient nur als Vorlage. Sie müssen theoretisch 10.x.x.x "scannen".
Sollten Sie bei den o.g. Tests Antworten ("Unicast reply") erhalten, prüfen Sie bitte, ob diese von Ihrem Server stammen, indem Sie die MAC-Adresse vergleichen. Stammen diese Antworten nicht von Ihrem Server, müssen Sie für die jeweils gescannte IP-Adresse nichts unternehmen (auch eine Information an uns ist nicht nötig).
Fehlerhaft konfigurierter Linux-Kernel bei mehreren Netzwerk-Karten
Bzgl. des Linux-Kernels verweisen wir auf die Anleitung für ARP Flux unter https://netbeez.net/blog/avoiding-arp-flux-in-multi-interface-linux-hosts/.
Daraus in aller Kürze:
$ sysctl -w net.ipv4.conf.all.arp_announce=1
$ sysctl -w net.ipv4.conf.all.arp_ignore=2
Wichtig: Diese Einstellungen müssen dauerhaft in der /etc/sysctl.conf gespeichert werden, sonst gehen sie beim Neustart verloren, siehe dazu auch unseren Wiki-Beitrag zur /etc/sysctl.conf.