Frage Loopback für weitergeleitete öffentliche IP-Adresse vom lokalen Netzwerk - Hairpin NAT


Das ist ein Kanonische Frage über Haarnadel NAT (Loopback NAT).

Die generische Form dieser Frage lautet:

Wir haben ein Netzwerk mit Clients, einem Server und einem NAT-Router. Es gibt eine Portweiterleitung auf dem Router zum Server, so dass einige seiner Dienste extern verfügbar sind. Wir haben DNS auf die externe IP zeigen. Lokale Netzwerkclients stellen keine Verbindung her, aber externe Arbeit.

  • Warum scheitert das?
  • Wie kann ich ein einheitliches Benennungsschema erstellen (DNS-Namen, die sowohl lokal als auch extern funktionieren)?

Diese Frage hat Antworten aus mehreren anderen Fragen zusammengeführt. Sie referenzierten ursprünglich auf FreeBSD, D-Link, Microtik und andere Geräte. Sie versuchen alle dasselbe Problem zu lösen.


42
2017-08-18 15:16


Ursprung


Wenn Sie den Zugriff aus dem Internet testen möchten, ist es sinnlos, die Routers und / oder DNS-Einstellungen des Routers trotzdem zu überprüfen, von innen würden Sie überprüfen, ob der interne Teil des Routers funktioniert. Ich schlage vor, Sie verwenden einen Proxy-Server irgendwo auf der Außenseite.


Antworten:


Was Sie suchen, heißt "Haarnadel-NAT". Anforderungen von der internen Schnittstelle für eine IP-Adresse, die der externen Schnittstelle zugewiesen ist, sollten so NAT sein, als kämen sie von der externen Schnittstelle.

Ich habe überhaupt keine FreeBSD-Vertrautheit, aber ich lese das "pf" -Manual für OpenBSD (http://www.openbsd.org/faq/pf/rdr.html) Die vorgeschlagenen Lösungen von Split-Horizon-DNS, die ein DMZ-Netzwerk verwenden, oder TCP-Proxying lassen mich glauben, dass "pf" keine Haarnadel-NAT unterstützt.

Ich würde die Route des Split-Horizon-DNS betrachten und intern keine IP-Adressen in URLs verwenden, sondern stattdessen Namen verwenden.


14
2017-08-18 15:30



Ich bin über diesen Thread gelaufen, während ich versuchte, das gleiche Problem zu lösen, und obwohl es zutrifft, dass FreeBSD nicht haarnadelfähig ist, gibt es Möglichkeiten, den internen -> externen -> internen Datenverkehr umzuleiten. - eggo
Zum Beispiel: no nat on $int_if proto tcp from $int_if to $int_net  , nat on $int_if proto tcp from $int_net to $hairpin_int port $hairpin_ports -> $int_if , rdr on $int_if proto tcp from $int_net to $ext_if port $hairpin_ports -> $hairpin_int - eggo


Da dies erhöht wurde, um das zu sein kanonische Frage zu Haarnadel-NATIch dachte, es sollte wahrscheinlich eine Antwort geben, die allgemeingültiger ist als die derzeit akzeptierte, die sich speziell auf FreeBSD bezieht.

Diese Frage gilt für Dienste, die von Servern in RFC1918-adressierten IPv4-Netzwerken bereitgestellt werden, die externen Benutzern durch Einführung von Ziel-NAT (DNAT) am Gateway zur Verfügung gestellt werden. Interne Benutzer versuchen dann, über die externe Adresse auf diese Dienste zuzugreifen. Ihr Paket wird vom Client an das Gateway-Gerät gesendet, das die Zieladresse neu schreibt und sofort in das interne Netzwerk zurückspeist. Es ist diese scharfe Kehrtwendung, die das Paket am Gateway macht, das den Namen hervorbringt Haarnadel NAT, in Analogie zu den Haarnadelkurve.

Das Problem tritt auf, wenn das Gateway-Gerät die Zieladresse neu schreibt, aber nicht die Quelladresse. Der Server empfängt dann ein Paket mit einer internen Zieladresse (seine eigene) und einer internen Quelladresse (die des Kunden); es weiß, dass es direkt auf eine solche Adresse antworten kann, also tut es das auch. Da diese Antwort direkt erfolgt, geht sie nicht über das Gateway, das daher niemals die Möglichkeit hat, den Effekt des eingehenden Ziel-NAT auf das ursprüngliche Paket auszugleichen, indem die Quelladresse des Rückpakets überschrieben wird.

Der Client sendet somit ein Paket an ein extern IP-Adresse, erhält aber eine Antwort von einem intern IP Adresse. Es hat keine Ahnung, dass die beiden Pakete Teil derselben Konversation sind, sodass keine Konversation stattfindet.

Die Lösung ist das für Pakete, die ein solches Ziel-NAT erfordern und die das Gateway vom internen Netzwerk erreichen, um auch Quell-NAT (SNAT) auf dem eingehenden Paket durchzuführen, normalerweise durch Umschreiben der Quelladresse als diejenige des Gateways. Der Server denkt dann, dass der Client das Gateway selbst ist und antwortet direkt darauf. Dies gibt dem Gateway wiederum die Möglichkeit, die Auswirkungen von sowohl DNAT als auch SNAT auf das eingehende Paket auszugleichen, indem sowohl Quell- als auch Zieladressen auf dem Rückpaket umgeschrieben werden.

Der Client denkt, dass er mit einem externen Server kommuniziert. Der Server denkt, dass er mit dem Gateway-Gerät kommuniziert. Alle Parteien sind glücklich. Ein Diagramm kann an dieser Stelle hilfreich sein:

enter image description here

Einige Verbraucher-Gateway-Geräte sind hell genug, um jene Pakete zu erkennen, für die der zweite NAT-Schritt benötigt wird, und diese werden wahrscheinlich in einem Haarnadel-NAT-Szenario sofort einsatzbereit sein. Andere sind nicht und werden es auch nicht, und es ist unwahrscheinlich, dass sie zur Arbeit gebracht werden können. Eine Diskussion darüber, welche Consumer-Grade-Geräte für Serverfehler nicht verfügbar sind.

Angemessene Netzwerkgeräte können im Allgemeinen gesagt werden, um zu arbeiten, aber - weil sie nicht im Geschäft sind, ihre Admins zu hinterfragen - müssen sie dazu aufgefordert werden. Linux verwendet iptables um den DNAT so zu machen:

iptables -t nat -A PREROUTING  -p tcp --dport 80 -j DNAT --to-destination 192.168.3.11

was ermöglicht einfache DNAT für den HTTP-Port, zu einem internen Server auf 192.168.3.11. Aber um Haarnadel NAT zu aktivieren, braucht man auch eine Regel wie:

iptables -t nat -A POSTROUTING -d 192.168.3.11 -p tcp --dport 80 -j MASQUERADE

Beachten Sie, dass solche Regeln in den relevanten Ketten an der richtigen Stelle sein müssen, um richtig zu funktionieren, und abhängig von den Einstellungen in der filter Darüber hinaus können zusätzliche Regeln erforderlich sein, damit der NAT-Verkehr fließen kann. Alle diese Diskussionen fallen nicht in den Rahmen dieser Antwort.

Aber wie andere bereits gesagt haben, ist die korrekte Aktivierung der Haarnadel-NAT nicht der beste Weg, um das Problem zu lösen. Das Beste ist Split-Horizon-DNS, bei denen Ihre Organisation je nach dem Standort des anfragenden Clients unterschiedliche Antworten für die ursprüngliche Suche bereitstellt, entweder durch verschiedene physische Server für interne vs. externe Benutzer oder dadurch, dass der DNS-Server entsprechend der Adresse des anfordernden Clients anders reagiert.


46
2017-11-27 12:20



Ich frage mich etwas über die Adressen auf Paketen, die zwischen Gateway und Server ausgetauscht werden. Wäre es nicht konsistenter, wenn der Server die öffentliche IP-Adresse des Routers als Client-IP sieht? Technisch gesehen können beide funktionieren, aber um konsistent zu bleiben, wie andere Server die Clients sehen, müsste sie die öffentliche IP verwenden. - kasperd
Ich nehme an, Sie beziehen sich auf den letzten Fall, "richtige Haarnadel NAT". Das Entscheidende ist, die Quelladresse des eingehenden Pakets so zu schreiben, dass sie zum Router zurückkehrt, der dann sowohl den DNAT als auch den SNAT umkehren kann und somit das Problem vermeidet. Welche der vielen Adressen der Router verwendet, um dies zu tun, ist mehr eine Sache des Geschmacks, und wenn Sie dies mit tun iptables, ist sicherlich etwas, das Sie konfigurieren können, wenn Sie dies wünschen. - MadHatter
Viele Admins, mich eingeschlossen, betrachten Split-Horizon DNS als eine Heilung, die schlimmer ist als eine Krankheit. Wenn ein zusätzlicher SNAT überhaupt als Krankheit bezeichnet werden kann. Ein Split-View-DNS verwirrt Menschen, während es das Leben von Routern einfacher macht. Dieses Thema wird besser durch eine separate ServerFault-Frage / Antwort behandelt. - kubanczyk
Meine Antwort ist sehr viel über Haarnadel-NAT. Ich kann die Vor- und Nachteile der Eröffnung einer kanonischen "Split-Horizon DNS" -Frage sehen: Profis beinhalten eine Frage, die den Anwendungen und Problemen von SHDNS gewidmet ist, aber die Nachteile sind, dass diese Frage bereits viele andere Fragen hatte, die damit zusammenhängen es verschmolz damit, das könnte auch mit deiner Frage geschehen. Wenn ich es wäre, würde ich das Thema Meta aufgreifen und nach Konsens streben. Wenn eine solche Frage geschrieben wird, freue ich mich darauf, Ihre Antwort darauf zu lesen! - MadHatter
@MadHatter Wo soll ich den Befehl iptables schreiben? auf Client oder Gateway oder Server? - Rock Balbao


Das Problem hierbei ist, dass Ihr Router nicht die interne Adresse Ihres internen Clients verwendet. Daher schlägt der TCP-Handshake fehl.

Nehmen wir folgende IPs an

  • Kunde: 192.168.1.3
  • Server: 192.168.1.2
  • Interner Router: 192.168.1
  • Router extern: 123.123.123.1

Hier ist was passiert:

  1. Client (192.168.1.3) sendet TCP-SYN an Ihre externe IP, Port 80 (123.123.123.1:80)
  2. Der Router sieht die Portweiterleitungsregel und leitet das Paket an den Server weiter (192.168.1.2:80), ohne die Quell-IP zu ändern (192.168.1.3)
  3. Client wartet auf ein SYN-ACK von der externen IP
  4. Der Server sendet seine Antwort direkt an den Client, da er sich im selben Subnetz befindet. Es sendet das Paket nicht an den Router, wodurch das NAT umgekehrt wird.
  5. Client erhält ein SYN-ACK von 192.168.1.2 anstelle von 123.123.123.1. Und verwirft es.
  6. Der Client wartet immer noch auf ein SYN-ACK von 123.123.123.1 und läuft ab.

8
2017-10-10 11:32





Warum nicht Split-Horizon-DNS anstelle von Hardcoding-IP-Adressen überall verwenden? Sie würden ext.yourdomain auf 217.x.x.x auf der Außenseite und dann 192.x.x.x auf der Innenseite zeigen.


4
2017-08-20 08:42



Wenn Sie einen Moment Zeit haben, könnten Sie näher erläutern, was Split-Horizon DNS ist, wie es funktioniert und welche wesentlichen Nachteile es hat. Dies ist jetzt eine kanonische Frage und es wäre schön, eine vollständigere Antwort zu haben. - Chris S


Kürzlich beantwortet eine ähnliche Frage: Cisco statisches NAT funktioniert nicht auf der LAN-Seite und habe gerade gemerkt, dass dies eine kanonische Frage ist. Gestatten Sie mir, hier die Lösung zusammenzufassen.

Vor allem: vergessen Sie NAT (wenn Sie können) - die Frage ist überhaupt nicht über die Konfiguration von NAT. Es geht um den Zugriff auf einen Server, der sich hinter NAT sowohl im Internet als auch im LAN befindet. Die Verwendung von zwei DNS-Zonen ist eine praktikable Alternative, aber nicht immer die Lösung. Aber die Lösung existiert und ist unglaublich einfach (wenn auch nicht perfekt, wahrscheinlich):

(1) auf dem Server: die öffentliche IP-Adresse als sekundäre IP-Adresse auf der Netzwerkschnittstelle des Servers mit der Maske 255.255.255.255 hinzufügen (Web-Service oder was auch immer auf dem Server gewünscht wird, sollte auch diese IP-Adresse abhören); Alle modernen Betriebssysteme ermöglichen dies (oder es kann eine Loopback-Schnittstelle mit der zugewiesenen öffentlichen IP-Adresse verwendet werden, anstatt der primären Schnittstelle eine sekundäre IP hinzuzufügen).

(2) auf den LAN-Hosts: Fügen Sie eine Host-Route für die öffentliche IP-Adresse hinzu, z. B. für Windows-Hosts den folgenden Befehl: route -p add 203.0.113.130 Maske 255.255.255.255 192.168.1.11 (Sie können auch die Option DHCP "Statische Route" verwenden, um die Route zu verteilen). Wenn sich zwischen den Clients und dem Router, der dem Internet zugewandt ist, (a) L3-Switch (s) / Router befinden, konfigurieren Sie diese Host-Route auf diesen (diesen) zwischengeschalteten Switches / Routern nicht auf den Kunden.

Für diejenigen, die sich mit dem TCP-Dreiwege-Handshake befassen: Es wird in der vorgeschlagenen Konfiguration OK.

Bitte geben Sie Feedback (mindestens, Abstimmung).


2
2017-11-03 11:14



Anforderung Nr. 2 macht dies in BYOD-Netzwerken nicht gut ... - Michael


Ich beantworte meine Fragen nur, um den Horizont für diejenigen mit ähnlichen Problemen zu erweitern.

Ich wurde mit meinem ISP kontaktiert und bat sie, meine Probleme zu lösen. Was sie mir angeboten haben, ist eine andere öffentliche IP-Adresse nur für Server, Jetzt habe ich lokalen Datenverkehr auf der WAN-Seite von FreeBSD und wir haben spezifische Leitungen für schnellerer Durchsatz nach lokalem Verkehr zur öffentlichen IP des Servers


1
2017-08-20 08:37



Diese Lösung implementiert a Perimeter-Netzwerk oder DMZund ist eine gute Alternative sowohl zu Hairpin NAT als auch zu Split-Horizon DNS. - Chris S


Wenn es sich um einen originalen D-Link-Router handelt (d. H. Nicht Rev. D / Firmware Version 1.00VG von Virgin Media), sollten Sie die Einstellungen anpassen können, um dies zu umgehen. (Ich stimme jedoch dem Vorschlag des früheren Posters von DD-WRT aus vielen anderen Gründen zu!)

  1. Melden Sie sich bei der Weboberfläche des Routers an
  2. Klicken Sie oben auf die Registerkarte Erweitert
  3. Klicken Sie links auf die Registerkarte Firewall-Einstellungen
  4. Drücke den Endpunkt unabhängig Optionsfeld unter TCP-Endpunktfilterung, wie im Screenshot unten gezeigt (oder sehen Sie die Router-Emulator auf der Website von D-Link)
  5. Änderungen speichern; Sie sind fertig

D-Link router web UI screenshot

Dieser Screenshot stammt vom Modell Rev. C; Ihre können etwas anders sein.


1
2018-03-11 02:37





Da ich diese Frage auch gestellt habe (vgl Wie greife ich von außen auf einen Netzwerkdienst zu, der hinter einer Firewall NAT-basiert ist?) und wurde hier umgeleitet, aber die Antworten hier lieferten keine Lösung (im Gegensatz zu generischen Erklärungen) Lass mich mein Linux (iptables spezifische) Lösung hier, um alle ein paar Stunden des Experimentierens zu speichern. Diese Datei befindet sich in iptables-restore Format und kann direkt in iptables gelesen werden (natürlich nach der Bearbeitung der IP-Adressen). Dies gilt für einen Webserver (Port 80) und nur für IPv4 - die Regeln für IPv6 und für SSL (Port 443) sind analog.


# Port forwarding for VM / Container access with „hairpin NAT“.
*nat
:PREROUTING ACCEPT [3:205]
:INPUT ACCEPT [59:670]
:OUTPUT ACCEPT [16:172]
:POSTROUTING ACCEPT [20:257]

# This was simple port forwarding - access works from outside but not from inside
#-A PREROUTING  -4 -p tcp -i eth0 --dport 80 -j DNAT --to web.local:80

# This is real hairpin NAT which allows „web.local“ to access itself via the VM hosts external IP.
# First we need to masquerade any traffic going out the external interface:
-A POSTROUTING -o eth0 -j MASQUERADE

# Then we need to reroute incoming traffic on the public IP to the local IP:
-A PREROUTING  -4 -p tcp -d web.public.com --dport  80 -j DNAT --to web.local:80

# And finally we need to tell the router that the source IP of any traffic
# coming from the LAN must be source-rewritten when going to the web server:
-A POSTROUTING -4 -p tcp -s lan.local/24 -d web.local --dport  80 -j SNAT --to-source web.public.com:80

COMMIT

Ersetzen lan.local , web.local und web.public.com mit Ihrem lokalen Netzwerk (z. B. 10.0.x.0 / 24), der lokalen IP Ihres Webservers (z. B. 10.0.1.2) und der öffentlichen IP-Adresse Ihres Routers (z. B. 4.5.6.7). Das -4 dient nur dazu, IPv6 - und IPv4 - Regeln in derselben Datei zuzulassen (solche Zeilen, die von ip6tables). Denken Sie auch daran, IPv6-Adressen in [Klammern] zu setzen, wenn sie Port-Deklarationen enthalten, z. [fe0a:bd52::2]:80.

Das waren all die Dinge, die mich dazu brachten, mir die Haare auszuziehen, wenn ich wirklich versuchte implementieren die Erklärungen in dieser Frage. Ich hoffe, ich habe nichts ausgelassen.


0
2018-03-24 06:02



MASQUERADE auf der Wan-Schnittstelle ist im Allgemeinen nützlich, ist aber nicht mit der "Haarnadel-NAT" -Frage verbunden. Die kanonische Antwort schlägt MASQUERADE auf der LAN-Schnittstelle vor und Sie schlagen stattdessen eine SNAT (SNAT ist ungefähr das gleiche wie MASQUERADE). Sie erzwingen etwas seltsame Quell-IP: Port-Override. - kubanczyk


Ich werde hier eine Antwort hinzufügen, da die Kommentare hier nicht auf mein spezielles Problem eingehen. Ich vermute, das liegt daran, dass ich einen fiesen Linux-Kernel-Bug gefunden habe. Das Setup ist:

internet <--> modem 1.1.1.1/30 <--> switch <---> LAN 10.1.1.0/24
                                      ^
        +----------------------+      |
        |              /--eth0 o <----/
        |              |       |           
        | 10.1.1.1/24 br0      |           v (antenna)
        |  1.1.1.2/30  |       |           |
        |              \-wlan0 o ----------/
        +----------------------+ 

Trotz des komplex aussehenden Bildes ist die einzige relevante Änderung in Situationen, die in anderen Kommentaren behandelt werden, die Hinzufügung der Softwarebrücke br0. Es ist da, weil die Gateway-Box auch ein WLAN-Access-Point für das LAN ist.

Unsere Gateway-Box führt immer noch NAT-Aufgaben für die Maschinen im LAN aus. Weil es nur 1 Ethernet-Port hat, ist es gezwungen, Haarnadel-NAT zu machen. Ich vermute, dass es nur mit den iptables-Regeln funktionieren sollte, die in anderen Kommentaren hier angegeben sind, aber auf dem Linux-Kernel 4.9 tut es das zumindest nicht. Unter 4.9 während unsere Gateway-Box auf das Internet zugreifen kann, können die Maschinen im LAN, die versuchen, über NAT darauf zuzugreifen, dies nicht tun.

tcpdump zeigt Antworten auf eingehende Pakete, die eth0 erreichen, aber sie machen es nicht aus br0. Durch Ausführen dieses Befehls wird Folgendes behoben:

ebtables -t brouter -A BROUTING -d 01:00:00:00:00:00/01:00:00:00:00:00 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-dst 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-src 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 -j DROP

Bevor dieser Befehl ausgeführt wird, werden eingehende Pakete entsprechend dem Standardverhalten des Kernels verarbeitet, das heißt, sie werden der Bridge übergeben und dann die Routing-Module des Kernels übergeben. Der Befehl zwingt Pakete, die nicht vom LAN kommen, die Brücke zu umgehen und direkt zum Routing zu gehen, was bedeutet, dass die Brücke keine Chance hat, sie fallen zu lassen. Broadcast- und Multicast-Adressen müssen überbrückt werden, sonst funktionieren Dinge wie DHCP und mDNS nicht. Wenn Sie IPv6 verwenden, müssen Sie auch Regeln dafür hinzufügen.

Sie könnten versucht sein, das Problem mit diesem Problem zu beheben:

brctl hairpin br0 eth0 on
brctl hairpin br0 wlan0 on

Ich war sicherlich so versucht - es war mein erster Versuch. Sobald ich es geschafft habe, haben Maschinen im LAN Zugriff auf das Internet bekommen, so dass es für eine Weile funktioniert. Dann passierte folgendes (und ich wollte das Experiment nicht wiederholen):

  1. Ping-Zeiten über das LAN zum Gateway verdoppelten sich in Intervallen von etwa 10 Sekunden, von 0,1 ms auf 0,2 ms, 0,4 ms, 0,8 ms, 2 ms und so weiter, bis die Gateway-Box vom LAN aus nicht erreichbar war. Es roch wie ein Paket Sturm, aber STP wurde überall eingeschaltet.
  2. Nicht lange nachdem alle drahtlosen Zugangspunkte gestorben sind.
  3. Beim Versuch, zu diagnostizieren, was mit dem WLAN-Gerät passiert ist, wurden alle IP-Telefone neu gestartet.
  4. Nicht lange danach verloren verdrahtete Maschinen jeglichen Kontakt mit dem LAN.

Der einzige Ausweg war, alle Maschinen im Gebäude neu zu starten. Die einzige Ausnahme waren die Hardware-Switches, die nicht neu gestartet werden konnten. Sie mussten mit Strom versorgt werden.


0
2018-06-22 05:45