iptables lehnt tcp-reset bei Loopback ab

1225
Haris

Ich versuche zu prüfen, wie sich eine Software bei einem Netzwerkfehler verhalten würde. Diese Software verwendet TCP send()und recv()kommuniziert.

Zuvor habe ich die Software miteinander kommunizieren lassen, indem ich sie in einem LAN-Netzwerk auf zwei verschiedenen Computern installierte. Um einen Netzwerkfehler zu simulieren, verwendete ich die folgende Regel.

sudo iptables -A INPUT -p tcp -s 10.100.52.234 -j REJECT --reject-with tcp-reset

Nehmen wir an, 10.100.52.234ist die IP eines der Systeme. Dies führte sofort zum Versagen. Alles gut und gut.

Jetzt versuche ich, dies auf einer Maschine mit einer Loopback-Adresse zu simulieren 127.0.0.1. Alles funktioniert genauso wie beim vorherigen Setup, aber der obige Befehl funktioniert nicht. Es tritt keine Netzwerkverbindung auf und die Software hängt einfach. Es findet keine Kommunikation statt, aber es scheitert auch nicht.

Ich habe den Befehl benutzt

sudo iptables -A INPUT -p tcp -s 127.0.0.1 -j REJECT --reject-with tcp-reset

und

sudo iptables -A INPUT -p tcp -i lo -j REJECT --reject-with tcp-reset

beide arbeiten nicht. Es dauert sehr lange, bis die Software ausfällt.

Gibt es eine andere Möglichkeit, die Verbindung für die Loopback-Adresse sofort abzubrechen?

3
Wie wäre es mit "--reject-with icmp-host-unreachable" oder "--reject-with icmp-port-unreachable"? guest-vm vor 7 Jahren 0
@guest Hat jede dieser Optionen ausprobiert. Das gleiche Verhalten bleibt bestehen. Haris vor 7 Jahren 0
Nur eine wilde Vermutung, korrigieren Sie mich, wenn ich falsch liege: Da sowohl Client als auch Server die gleiche Loopback-IP haben, würde jede Ablehnungsnachricht als Antwort auf den Client ebenfalls durch die iptables-Regel blockiert. kannst du die beiden mit der Portnummer in der Regel unterscheiden? guest-vm vor 7 Jahren 0
Seltsam, Versuchen Sie, die Loopback-Schnittstelle zu simulieren? Ist es nicht das Ziel der Loopback-Schnittstelle, dass Sie weiterhin auf einen Dienst zugreifen können, der auf dem lokalen Computer ausgeführt wird, wenn das Netzwerk tatsächlich ausfällt? (Wahrscheinlich würden Sie über eine Konsole im Rechenzentrum auf diesen Dienst zugreifen, falls das Netzwerk jemals ausfiel, und Sie wären auch die Einzigen.) NotAdmin Dave vor 7 Jahren 0

1 Antwort auf die Frage

3
Kamil Maciorowski

Ich habe Ihr Ergebnis reproduziert (mit SSH-Verbindungsversuch, 127.0.0.1während ich sshdzuhörte). Es stimmt, dass die Software einfach hängt.

Ich denke, die Software erwartet eine Antwort oder eine Fehlermeldung, aber die Fehlermeldung fällt in dieselbe Regel und wird abgelehnt. Ich weiß nicht, ob es eine Kettenreaktion auf Fehlermeldungen gibt oder nicht - ich habe das bisher nicht untersucht. Ich kann es falsch verstehen, also wenn jemand eine bessere Erklärung hat, werde ich es gerne lesen.

Hier ist die Lösung, die in meinem Debian funktioniert:

Sie sollten eine Verbindung herstellen 127.0.0.2( Erklärung hier ) und Ihre Regel wie folgt festlegen:

sudo iptables -I INPUT 1 -p tcp -d 127.0.0.2 -j REJECT --reject-with tcp-reset

Beachten Sie das -I INPUT 1Fragment, das sicherstellt, dass die Regel an der ersten Position eingefügt wird, um Vorrang vor allen ACCEPTRegeln zu haben, die Sie möglicherweise bereits in Ihrer Loopback-Schnittstelle haben (wie in meinem Debian).

Ich habe den Test wiederholt (mit SSH-Verbindungsversuch, diesmal bis 127.0.0.2). Es versagte sofort mit

Connection refused

Ich denke, es funktioniert so, wie Sie es wünschen, denn jetzt ist die Fehlermeldung dazu bestimmt 127.0.0.1, von der Ablehnungsregel nicht erfasst und bestanden zu werden.

Verwandte Probleme