Habe dies in „Netzwerktechnik“ im Stack Exchange gefragt und wurde hierher weitergeleitet.
Ich habe ein paar Server mit der folgenden Konfiguration
Server 1:
eno1: 127.15.0.1/16 scope global
eno2: 5.0.0.1/24
Server2:
lo: 127.0.0.1/16 (it had /8. I changed the subnet mask using 'ip addr del 127.0.0.1/8 dev lo; ip addr add 127.0.0.1/16 dev lo')
eno2: 5.0.0.2/24
eno1 von Server1 ist mit einem völlig anderen L2-Netzwerk verbunden und vollständig isoliert.
Die eno2-Schnittstellen beider Server sind mit demselben L2-Netzwerk verbunden. Jetzt muss ich von Server2 aus auf 127.15.0.1 zugreifen.
Server1 wurde vor langer Zeit bereitgestellt und ich habe keine Berechtigung, irgendwelche Konfigurationen zu ändern. Ich weiß nicht, warum jemand das Subnetz 127.xxx mit globalem Gültigkeitsbereich verwendet hat. Ich bin mir nicht sicher, ob es eine gültige Konfiguration ist, aber ich muss damit leben. Ich habe die vollständige Kontrolle über Server2 und kann alles ändern.
Beide Server basieren auf Linux.
Die Konnektivität zwischen 5.0.0.1 <-> 5.0.0.2 ist gut.
Mein erster Versuch bestand darin, eine Route in Server2 wie unten hinzuzufügen.
ip r add 127.15.0.1/32 via 5.0.0.1 hat 127.15.0.1 von Server2 aus gepingt. Ich sehe die Ping-Anfragen und -Antworten im TCPdump auf Server2, aber der Ping-Befehl zeigt 100 % Verlust an.
Ich habe rp_filters deaktiviert
sysctl.cnf:
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.lo.rp_filter=0
net.ipv4.conf.eno2.rp_filter=0
Neustart nach Aktualisierung von sysctl.conf
Und ich habe die iptables geleert. (iptables -F)
Gleiches Ergebnis. Ich dachte, Server2 mag die Verwendung der 127.xxx-Serie vielleicht nicht. Also habe ich die folgende Regel auf Server 2 hinzugefügt
iptables -t nat -A OUTPUT -d 5.0.0.1 -j DNAT --to-destination 127.15.0.1
Diese Regel soll die Ziel-IP durch 127.15.0.1 ersetzen, wenn das Paket für 5.0.0.1 bestimmt ist.
5.0.0.1 von Server2 gepingt. Iptables hat die Ziel-IP durch 127.15.0.1 ersetzt (bestätigt durch TCPdump von Server1). Server1 hat geantwortet, aber die Antworten werden erneut gelöscht.
An diesem Punkt gingen mir die Ideen aus. Ich habe Server1 zur Wartung heruntergefahren und 127.15.0.1/26 durch 192.168.1.1/16 ersetzt. Die Konnektivität funktionierte in diesem Fall einwandfrei (mit und ohne iptables). Nun stellt sich die Frage, ob das Problem an der Verwendung von 127.xxx liegt. Wenn ja, gibt es einen Ausweg? Wenn nein, was kann ich sonst noch versuchen?
Hinweis: Diese Konfiguration hat vorher funktioniert. Wir haben kürzlich Server2 verloren (auf dem das alte Linux lief) und ich baue es von Grund auf neu auf. Außerdem erlaubt Windows nicht die Verwendung von 127.xxx für andere Schnittstellen als Loopback. Ich bin mir nicht sicher, warum Linux dies für Nicht-Lo-Schnittstellen zulässt. Vielleicht gibt es dafür einen Grund!
Zusammenfassend habe ich folgende Fragen:
- Windows lehnt die Konfiguration komplett ab, wenn wir versuchen, 127.xxx zu konfigurieren, aber Linux erlaubt dies und das auch mit globaler Gültigkeit. Gibt es dafür einen Anwendungsfall?
- In diesem Fall sendet Server2 Anfragen an 127.xxx und Server1 sendet tatsächlich Antworten zurück. Wenn 127.xxx nurHost-intern, warum senden sie überhaupt Pakete über die Verbindung??
Antwort1
Die Linux-Sysctl-Flags bei
/sys/net/ipv4/conf/*/route_localnet
Erlauben Sie die Deaktivierung einer angemessenen Behandlung solcher Pakete.
route_localnet – BOOLEAN
Loopback-Adressen beim Routing nicht als Martian-Quelle oder -Ziel betrachten. Dies ermöglicht die Verwendung von 127/8 für lokale Routing-Zwecke. Standardmäßig FALSE
Da nur wenige vernünftige Menschen so etwas jemals tun würden, kann es heutzutage funktionieren oder auch nicht (ich habe es vor ein paar Jahren zum letzten Mal getestet).
Bitte ordnen Siefür diesen Zweck reserviert(möglicherweise link-lokal, aber nicht host-intern) oderim BesitzIP-Raum zu den betreffenden Schnittstellen.Die Fortsetzung dieses merkwürdigen Setups wird nur noch mehr Probleme verursachen, insbesondere wenn es einfache Alternativen gibt.