it-swarm.com.de

Loopback zur weitergeleiteten öffentlichen IP-Adresse vom lokalen Netzwerk - Haarnadel NAT

Dies ist eine 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). Der Router verfügt über eine Portweiterleitung zum Server, sodass einige seiner Dienste extern verfügbar sind. Wir haben DNS, das auf den externen Server verweist IP. Lokale Netzwerkclients stellen keine Verbindung her, aber externe Arbeit.

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

Diese Frage enthält Antworten, die aus mehreren anderen Fragen zusammengeführt wurden. Sie bezogen sich ursprünglich auf FreeBSD, D-Link, Microtik und andere Geräte. Sie alle versuchen jedoch, das gleiche Problem zu lösen.

46
adopilot

Was Sie suchen, heißt "Haarnadel NAT". Anforderungen von der internen Schnittstelle nach einer der externen Schnittstelle zugewiesenen IP-Adresse sollten NAT-fähig sein, als ob sie von der externen Schnittstelle eingegangen wären.

Ich bin mit FreeBSD überhaupt nicht vertraut, lese aber das "pf" -Handbuch für OpenBSD ( http://www.openbsd.org/faq/pf/rdr.html ) der vorgeschlagenen Lösungen von Split-Horizon-DNS mit einem DMZ Netzwerk oder TCP Proxy) lässt mich glauben, dass "pf" kein Haarnadel-NAT unterstützt.

Ich würde versuchen, den Weg des Split-Horizon-DNS zu beschreiten und keine IP-Adressen in URLs intern zu verwenden, sondern stattdessen Namen zu verwenden.

16
Evan Anderson

Da dies zur kanonischen Frage zu Haarnadel-NAT erhoben wurde, dachte ich, dass es wahrscheinlich eine Antwort geben sollte, die allgemeiner gültig ist als die derzeit akzeptierte, die (obwohl ausgezeichnet) in Beziehung steht speziell für FreeBSD.

Diese Frage gilt für Dienste, die von Servern in RFC1918-adressierten IPv4-Netzwerken bereitgestellt werden und externen Benutzern durch Einführung von destination NAT (DNAT) am Gateway) zur Verfügung gestellt werden. Interne Benutzer versuchen dann, auf diese Dienste zuzugreifen über die externe Adresse. Ihr Paket geht vom Client an das Gateway-Gerät, das die Zieladresse neu schreibt und sie sofort wieder in das interne Netzwerk einspeist. Es ist diese scharfe Kehrtwende, die das Paket am Gateway macht, die das verursacht Name Haarnadel NAT , analog zur Haarnadelkurve .

Das Problem tritt auf, wenn das Gateway-Gerät die Zieladresse neu schreibt, nicht jedoch die Quelladresse. Der Server empfängt dann ein Paket mit einer internen Zieladresse (seiner eigenen) und einer internen Quelladresse (der des Clients). es weiß, dass es direkt auf eine solche Adresse antworten kann, also tut es dies. Da diese Antwort direkt ist, erfolgt sie nicht über das Gateway, wodurch niemals die Möglichkeit besteht, die Auswirkung des eingehenden Ziels NAT auf das ursprüngliche Paket durch Umschreiben der Quelladresse der Rückgabe) auszugleichen Paket.

Der Client sendet somit ein Paket an eine extern IP-Adresse, erhält jedoch eine Antwort von einer intern IP-Adresse. Es hat keine Ahnung, dass die beiden Pakete Teil derselben Konversation sind, daher findet keine Konversation statt.

Die Lösung ist, dass für Pakete, die ein solches Ziel-NAT benötigen und das Gateway vom internen Netzwerk aus erreichen, auch source NAT (SNAT) auf dem Eingehendes Paket, normalerweise durch Umschreiben der Quelladresse in die des Gateways. Der Server denkt dann, der Client sei das Gateway selbst und antwortet direkt darauf. Dies gibt dem Gateway wiederum die Möglichkeit, die Auswirkungen von DNAT und SNAT auszugleichen auf das eingehende Paket durch Umschreiben sowohl der Quell- als auch der Zieladresse auf das zurückgegebene Paket.

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

enter image description here

Einige Consumer-Gateway-Geräte sind hell genug, um die Pakete zu erkennen, für die der zweite Schritt NAT] erforderlich ist, und diese funktionieren wahrscheinlich sofort in einer Haarnadelkurve NAT Szenario. Andere sind es nicht und werden es auch nicht, und es ist unwahrscheinlich, dass sie zum Funktionieren gebracht werden können. Eine Diskussion darüber, welche Geräte für Endverbraucher für Serverfehler nicht zum Thema gehören.

Die richtigen Netzwerkgeräte können im Allgemeinen angewiesen werden, zu funktionieren, aber - da sie nicht in der Lage sind, ihre Administratoren zu erraten - müssen sie dazu aufgefordert werden. Linux verwendet iptables, um die DNAT folgendermaßen auszuführen:

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

dies ermöglicht eine einfache DNAT für den HTTP-Port zu einem internen Server auf 192.168.3.11. Aber um Haarnadel-NAT zu aktivieren, würde man auch eine Regel benötigen 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, damit sie ordnungsgemäß funktionieren. Abhängig von den Einstellungen in der filter -Kette sind möglicherweise zusätzliche Regeln erforderlich, damit der NATted-Verkehr fließen kann. Alle derartigen Diskussionen fallen nicht in den Geltungsbereich dieser Antwort.

Aber wie andere gesagt haben, ist die ordnungsgemäße Aktivierung der Haarnadel NAT nicht der beste Weg, um das Problem zu lösen. Das Beste ist DNS mit geteiltem Horizont , wobei Ihre Organisation je nach Standort des anfordernden Clients unterschiedliche Antworten für die ursprüngliche Suche bereitstellt, entweder indem unterschiedliche physische Server für interne oder externe Benutzer vorhanden sind oder indem der DNS-Server so konfiguriert wird, dass er je nach dem unterschiedlich reagiert Adresse des anfragenden Kunden.

49
MadHatter

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

Nehmen wir folgende IPs an

  • Client: 192.168.1.3
  • Server: 192.168.1.2
  • Router intern: 192.168.1
  • Router extern: 123.123.123.1

Folgendes passiert:

  1. Der Client (192.168.1.3) sendet TCP-SYN an Ihre externe IP, Port 80 (123.123.123.1:80).
  2. Der Router erkennt 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. Der Client wartet auf eine SYN-ACK von der externen IP
  4. Der Server sendet seine Antwort direkt an den Client zurück, da er sich im selben Subnetz befindet. Das Paket wird nicht an den Router gesendet, wodurch das NAT umgekehrt würde.
  5. Der Client erhält eine SYN-ACK von 192.168.1.2 anstelle von 123.123.123.1. Und wirft es weg.
  6. Der Client wartet weiterhin auf eine SYN-ACK von 123.123.123.1 und läuft ab.
9
PEra

Warum nicht Split-Horizon-DNS verwenden, anstatt IP-Adressen überall fest zu codieren? Sie hätten ext.yourdomain, das außen auf 217.x.x.x und innen auf 192.x.x.x zeigt.

4
Ryaner

Wenn es sich um einen Original-D-Link-Router handelt (d. H. Nicht Rev. D/Firmware Version 1.00VG von Virgin Media), sollten Sie in der Lage sein, die Einstellungen anzupassen, um dies zu umgehen. (Ich stimme jedoch aus vielen anderen Gründen dem Vorschlag des vorherigen Posters von DD-WRT 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. Klicken Sie unter TCP-Endpunktfilterung auf das Optionsfeld Endpoint Independent (siehe Abbildung) der Screenshot unten (oder siehe Router-Emulator auf der D-Link-Website)
  5. Änderungen speichern; du bist fertig

D-Link router web UI screenshot

Dieser Screenshot stammt aus dem Rev. C-Modell. Ihre kann etwas anders sein.

2
David

Kürzlich wurde eine ähnliche Frage beantwortet: Cisco static NAT funktioniert nicht auf der LAN-Seite und ich habe gerade festgestellt, dass dies eine kanonische Frage ist. Lassen Sie mich also die Frage zusammenfassen Lösung hier.

Zuallererst: Vergiss NAT (wenn du kannst)) - die Frage betrifft überhaupt nicht die Konfiguration von NAT. Es geht darum, auf einen Server zuzugreifen, der hinter NAT from) steht Sowohl das Internet als auch das LAN. 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 (obwohl wahrscheinlich nicht perfekt):

(1) auf dem Server: Fügen Sie die öffentliche IP-Adresse als sekundäre IP-Adresse auf der Netzwerkschnittstelle des Servers mit der Maske 255.255.255.255 hinzu (der Webdienst oder was auch immer Sie auf dem Server möchten, sollte diese IP-Adresse ebenfalls abhören). Alle modernen Betriebssysteme ermöglichen dies (oder es kann eine Loopback-Schnittstelle mit der ihr 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. Verwenden Sie beispielsweise für Windows-Hosts den folgenden Befehl: route -p add 203.0.113.130 mask 255.255.255.255 192.168 .1.11 (Sie können auch die DHCP-Option "statische Route" verwenden, um die Route zu verteilen). Wenn sich zwischen den Clients und dem mit dem Internet verbundenen Router (a) L3-Switches/Router befinden, konfigurieren Sie diese Host-Route auf diesen (diesen) Zwischen-Switches/Routern, nicht auf die Kunden.

Für diejenigen, die sich mit dem TCP Drei-Wege-Handshake: In der vorgeschlagenen Konfiguration funktioniert es einwandfrei

Bitte geben Sie Feedback (zumindest Abstimmung).

2
Sergio

Aus technischer Sicht besteht die beste Lösung für dieses Problem darin, IPv6 in Ihrem Netzwerk zu aktivieren. Wenn IPv6 aktiviert ist, müssen Sie einen AAAA-Eintrag für Ihre Domain erstellen. Behalten Sie den vorhandenen A-Datensatz bei, der auf das externe IPv4 des Routers verweist. Erstellen Sie einen AAAA-Eintrag, der auf die IPv6-Adresse des Servers verweist.

IPv6 verfügt über genügend Adressen, um NAT zu vermeiden, sodass Sie keine Haarnadel benötigen NAT für IPv6. Sobald Sie IPv6 aktiviert und AAAA-Datensätze erstellt haben, unterstützt jeder Client RFC 8305 wird IPv6 vor IPv4 versuchen. Dies bedeutet, dass Sie keine Haarnadel benötigen NAT auch für IPv4, da die Clients es nicht verwenden werden.

Sie benötigen weiterhin Ihr vorhandenes IPv4 NAT für ausgehende Verbindungen und Portweiterleitung für eingehende Verbindungen, bis der größte Teil der Welt auch IPv6 aktiviert hat.

Es ist auch schneller.

Mit IPv6 erzielen Sie eine bessere Leistung als mit Haarnadel-NAT.

Mit der Haarnadel NAT) sendet Ihr Client ein Paket über einen Switch an den Router. Der Router führt dann zwei Übersetzungsrunden durch und sendet das Paket schließlich über den Switch an den Server. Pakete vom Server Der Kunde wird den gesamten Pfad in umgekehrter Reihenfolge durchlaufen.

Mit IPv6 vermeiden Sie NAT, stattdessen werden Pakete direkt über den Switch zwischen Client und Server gesendet. Dies bedeutet, dass Sie bei einer Rundreise die Anzahl der Durchgänge durch den Switch von 4 auf 2 reduzieren und 2 Fahrten durch den Router und die 4 Übersetzungen, die der Router durchgeführt hätte, vermeiden. Dies führt zu einer besseren Leistung.

Dies gilt auch dann, wenn Sie einen Switch verwenden, der in dieselbe Box wie der Router integriert ist.

Was ist, wenn der ISP kein IPv6 hat?

Wenn Sie einen ISP verwenden, der IPv6 nicht unterstützt, werde ich fragen, ob Sie Server in diesem Netzwerk hosten sollten. Dies sind meine Vorschläge, was zu tun ist, wenn der ISP IPv6 derzeit nicht unterstützt.

Teilen Sie dem ISP zunächst mit, dass Sie IPv6 benötigen. Und erinnern Sie sie vielleicht daran, dass es das IPv6-Protokoll seit 20 Jahren gibt, sodass sie es längst überfällig unterstützen. Wenn dies für den ISP nicht ausreicht, um Sie ernst zu nehmen, suchen Sie nach anderen ISPs.

Wenn Sie einen ISP mit IPv6-Unterstützung finden, können Sie ihn für eine Übergangszeit mit beiden ISPs ausführen. Auf dem mit dem neuen ISP verbundenen Router können Sie IPv4 auf der LAN-Seite deaktivieren und dann die LAN-Seiten beider Router mit demselben Switch verbinden. IPv4 und IPv6 sind zwei unabhängige Protokolle. Daher ist es überhaupt kein Problem, wenn diese Verbindungen über verschiedene Router erfolgen. Als Nebeneffekt erhalten Sie eine gewisse Redundanz, wenn eine der Verbindungen ausfällt.

Wenn Sie keinen ISP mit IPv6-Unterstützung finden, sollten Sie Ihren Server auf eine Hosting-Einrichtung verschieben. Mit einem Server in einer Hosting-Einrichtung sind Sie weniger vom geografischen Standort abhängig. Aus diesem Grund gibt es mehr Wettbewerb zwischen den Anbietern, um sicherzustellen, dass es einen gibt, der Ihren Anforderungen entspricht.

Wenn Sie den Server auf eine Hosting-Einrichtung verschieben, erhalten Ihre Clients kein IPv6. Wenn Sie den Server jedoch verschieben, benötigen Sie keine Haarnadel mehr NAT, um ihn zu erreichen).

Was Sie nicht tun sollten

Aktivieren Sie IPv6 nicht und erstellen Sie keine AAAA-Einträge, wenn Sie keine Möglichkeit haben, den IPv6-Verkehr weiterzuleiten. Wenn Ihr ISP IPv6 nicht unterstützt, Sie jedoch IPv6 in Ihrem LAN aktivieren (möglicherweise unter Verwendung von RFC 4193-Adressen) und AAAA-Einträge erstellen, funktioniert dies für Clients in Ihrem LAN, die den Server in Ihrem LAN erreichen. Die Kommunikation zwischen Ihrem LAN und der Außenwelt würde jedoch zuerst IPv6 ausprobieren (was nicht funktionieren würde), und Sie würden sich darauf verlassen, auf IPv4 zurückzugreifen, das bestenfalls etwas langsamer ist oder im schlimmsten Fall nicht auftritt.

1
kasperd

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

Ich werde von meinem ISP kontaktiert und gebeten, meine Probleme zu lösen. Was sie mir angeboten hatten, war eine andere öffentliche IP-Adresse nur für den Server. Jetzt habe ich lokalen Datenverkehr auf der Seite WAN von FreeBSD) und wir haben spezielle Pipes für einen schnelleren Durchsatz des lokalen Datenverkehrs zur öffentlichen IP des Servers erstellt

1
adopilot

Ich werde hier eine Antwort hinzufügen, da die Kommentare hier mein spezielles Problem nicht angesprochen haben. Ich vermute, das liegt daran, dass ich einen bösen 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 der in anderen Kommentaren behandelten Situationen die Hinzufügung der Software-Brücke br0. Es ist da, weil die Gateway-Box auch ein drahtloser Zugangspunkt für das LAN ist.

Unsere Gateway-Box führt immer noch NAT Aufgaben für die Computer im LAN aus. Da sie nur einen Ethernet-Port hat, muss sie Haarnadel-NAT ausführen. Ich vermute, sie sollte nur mit den angegebenen iptables-Regeln funktionieren in anderen Kommentaren hier, aber auf dem Linux-Kernel 4.9 zumindest nicht. Unter 4.9 kann unsere Gateway-Box auf das Internet zugreifen, während die Computer im LAN versuchen, über NAT can) darauf zuzugreifen 't.

tcpdump zeigt Antworten auf eingehende Pakete, die eth0 treffen, aber sie schaffen es nicht aus br0 heraus. 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 gemäß dem Standardverhalten des Kernels verarbeitet, indem sie an die Bridge übergeben und dann an die Routingmodule des Kernels übergeben werden. Der Befehl zwingt Pakete, die nicht aus dem LAN stammen, die Bridge zu umgehen und direkt zum Routing zu wechseln. Dies bedeutet, dass die Bridge keine Chance hat, sie zu verwerfen. 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 hinzufügen.

Sie könnten versucht sein, das Problem folgendermaßen zu beheben:

brctl hairpin br0 eth0 on
brctl hairpin br0 wlan0 on

Ich war auf jeden Fall so versucht - es war mein erster Versuch. Sobald ich es getan habe, haben Maschinen im LAN Zugang zum Internet erhalten, so dass es für eine Weile funktioniert. Dann geschah Folgendes (und ich wollte das Experiment nicht wiederholen):

  1. Die 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 usw., bis auf die Gateway-Box über das LAN nicht mehr zugegriffen werden konnte. Es roch nach einem Paketsturm, aber STP war überall eingeschaltet.
  2. Nicht lange nachdem alle drahtlosen Zugangspunkte gestorben waren.
  3. Beim Versuch zu diagnostizieren, was mit dem WLAN passiert ist, wurden alle IP-Telefone neu gestartet.
  4. Nicht lange danach verloren kabelgebundene Maschinen jeglichen Kontakt zum LAN.

Der einzige Ausweg bestand darin, jeden Computer im Gebäude neu zu starten. Die einzige Ausnahme waren die Hardware-Switches, die nicht neu gestartet werden konnten. Sie mussten aus- und wieder eingeschaltet werden.

0
Russell Stuart

Da ich auch diese Frage gestellt habe (siehe Wie greife ich von innen auf einen hinter einer Firewall NAT-fähigen Netzwerkdienst mit dessen externer IP zu? ) und hier umgeleitet wurde, lieferten die Antworten hier kein Lösung (im Gegensatz zu generischen Erklärungen ) lassen Sie mich mein Linux (iptables spezifische) Lösung hier, um allen ein paar Stunden Experimentieren zu ersparen. Diese Datei hat das Format iptables-restore Und kann direkt in iptables eingelesen werden (natürlich nach dem Bearbeiten der IP-Adressen). Dies gilt für einen Webserver (Port 80) und nur für IPv4 - die Regeln für IPv6 und 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 Sie lan.local, web.local Und web.public.com Durch Ihr lokales Netzwerk (z. B. 10.0.x.0/24), die lokale IP Ihres Webservers (z. B. 10.0.1.2) und Ihre Öffentliche IP des Routers (z. B. 4.5.6.7). Mit -4 Werden nur IPv6- und IPv4-Regeln in derselben Datei zugelassen (solche Zeilen werden von ip6tables Ignoriert). Denken Sie auch daran, IPv6-Adressen in [Klammern] zu setzen, wenn sie Portdeklarationen enthalten, z. [fe0a:bd52::2]:80.

Das waren alles Dinge, die mich dazu veranlassten, mir die Haare auszureißen, als ich versuchte, die Erklärungen in dieser Frage tatsächlich umzusetzen . Ich hoffe ich habe nichts ausgelassen.

0
Jens

Da ist es eine kanonische Frage. Ich werde antworten, wenn Sie einen Sonicwall-Router haben.

Der zu wissende Ausdruck ist NAT-Loopback-Richtlinie

In diesem Dokument wird beschrieben, wie ein Host in einem SonicWall-LAN über die öffentliche IP-Adresse des Servers an den vollqualifizierten Domänennamen auf einen Server im SonicWall-LAN zugreifen kann. Stellen Sie sich ein NSA 4500 (SonicOS Enhanced) -Netzwerk vor, in dem das primäre LAN-Subnetz 10.100.0.0/24 und das primäre WAN IP ist 3.3.2.1) Angenommen, Sie haben eine Website für Ihre Kunden, und der Hostname lautet. Sie haben bereits die erforderlichen Richtlinien und Regeln geschrieben, damit Außenstehende auf die Website zugreifen können, diese wird jedoch tatsächlich auf einem privaten Server 10.100.0.2 ausgeführt. Stellen Sie sich das jetzt vor Sie sind eine Person, die privat einen Laptop mit der IP-Adresse 10.100.0.200 verwendet. Sie möchten den Server über seinen öffentlichen Namen erreichen, da Sie dasselbe tun, wenn Ihr Laptop mit Ihnen unterwegs ist. Wenn Sie darauf sitzen die private Seite und Anfrage http://www.example.com >, Loopback macht es möglich, dass dies funktioniert, obwohl der Server tatsächlich direkt neben Ihnen auf einer lokalen IP-Adresse ist .

Um diese Funktionalität zu ermöglichen, müssten Sie eine NAT Loopback-Richtlinie, auch bekannt als NAT Reflection oder Haarnadel), erstellen.

Loopback-Richtlinie mit WAN IP-Adresse der Schnittstelle

Login to the SonicWall Management GUI.
Navigate to Manage | Rules | NAT Policies submenu.
Click on the Add button.
Create the following NAT Policy.
Original Source: LAN Subnets (or Firewalled Subnets if you want hosts in other zones to be included)
Translated Source: WAN Interface IP
Original Destination: WAN Interface IP
Translated Destination: (LAN server object)
Original Service: Any
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

Die Sonicwall erkennt den externen Dienst, mit dem Sie Kontakt aufnehmen möchten, und schreibt die Zieladresse neu, um sie an die interne Adresse des Servers anzupassen. Dadurch ist sie für den Computer transparent.

0
yagmoth555