Zusammenfassung
Es muss sichergestellt sein, dass Ihr Server auf dem externen, öffentlichen Netzwerk-Interface nur für die Ihnen zugeteilten IP-Adressen antwortet, nicht jedoch für private IP-Adressen wie z.B. 10.0.0.0/8 oder 192.168.0.0/16, antwortet.
Gründe
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 (1) private IP-Adresse zu "pingen", sondern möglichst alle privaten IP-Adress-Bereiche nach RFC 1918, siehe dazu auch 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 komplett 10.x.x.x (und weitere Netze) "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.
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.