Ein Dienst lauscht auf 127.0.0.1:1080. Eine DNAT-Regel leitet eingehenden Verkehr an diese Adresse, doch die Verbindung scheitert. Der Dienst kann gesund sein und die NAT-Regel passen: IPv4-Loopback-Adressen erfahren eine besondere Routing-Behandlung.

Das route_localnet von Linux steuert, ob 127/8-Adressen beim Routing als Mars-Adressen behandelt werden. Sein Standardwert bewahrt die übliche Loopback-Grenze. Eine schnittstellenspezifische Ausnahme kann für ein bewusstes lokales Umleitungskonzept relevant sein.

Das erklärt, warum eine funktionierende Regel von einer anderen Maschine von einem sysctl abhängen kann, den Sie nicht mitkopiert haben. Es rechtfertigt nicht, die Option überall zu aktivieren.

Die Sicherheitsannahme ändert sich mit der Route

Eine Loopback-Bindung wird oft gewählt, weil ein Helfer keine eigenständige Client-Authentifizierung besitzt. Wenn Verkehr von einer anderen Schnittstelle dorthin geroutet werden kann, beschreibt die Bindeadresse allein nicht mehr den erreichbaren Kreis. Beschränken Sie Quellen, Ziel und Port im tatsächlichen Regelsatz, einschließlich Verkehr, der Loopback-Quell- oder -Zieladressen beansprucht, wo dies relevant ist.

Prüfen Sie den Netzwerk-Namespace, der den Dienst enthält. Das Loopback eines Containers ist nicht das des Hosts, und eine geänderte Host-Schnittstelleneinstellung erzeugt nicht automatisch einen Listener im Container.

rp_filter beantwortet eine andere Frage zur Quellpfadprüfung. Es global abzuschalten ist kein allgemeiner Ersatz für das Verständnis des Loopback-Routings. Ebenso betrifft ip_nonlocal_bind das Binden von Sockets an nichtlokale Adressen, nicht die Korrektheit dieses DNAT-Pfads.

Schließlich muss das umgeleitete Protokoll zum Listener passen. Roher HTTP- oder TLS-Verkehr an einen SOCKS-Port braucht weiterhin einen Übersetzer; eine Routing-Ausnahme kann die fehlende Aushandlung nicht liefern.

Ähnliche Artikel