Routing und NAT auf sich selbst
Hallo zusammen,
ich stehe mal wieder etwas auf dem Schlauch, vielleicht denke ich auch nur zu kompliziert um die Ecke, der Titel trifft es auch nicht genau.
An meinem Router habe ich aus dem Internet eingehende DNS & Dyndns-Ports (53/8245) weitergeleitet auf einen "DMZ"-Host (soll heißen sparates VLAN, per Firewall separiert vom Rest des LAN). Klappt alles ganz gut.
ExterneIP -> Router
Router -> DMZ
Router -> LAN
NAT: Port 53 der Schnittstelle Internet egal woher -> DMZHost:53
Jetzt geht es um die Überwachung bzw. Überprüfen der korrekten Funktion "von innen heraus".
Ping aus dem LAN auf die ExterneIP funktioniert.
nslookup aus dem LAN auf die ExterneIP funktioniert nicht. Wie auch, die NAT-Weiterleitung ist ja nicht für die LAN-Schnittstelle eingerichtet. Eine zusätzliche Weiterleitung für die LAN-Schnittstelle will ich nicht einrichten.
Gibt es überhaupt eine Möglichkeit, von "innen heraus" zu testen, ob die Weiterleitung funktioniert (außer am Protokoll des DMZ-Host)? Wenn ich das hier so schreibe würde ich ja sagen nein. Wenn ich die DNS-Funktion von extern her testen will, muss ich das auch von externen Host machen - oder? Es gibt da keinen Loopback-Trick - nicht wahr?
Grüße
lcer
ich stehe mal wieder etwas auf dem Schlauch, vielleicht denke ich auch nur zu kompliziert um die Ecke, der Titel trifft es auch nicht genau.
An meinem Router habe ich aus dem Internet eingehende DNS & Dyndns-Ports (53/8245) weitergeleitet auf einen "DMZ"-Host (soll heißen sparates VLAN, per Firewall separiert vom Rest des LAN). Klappt alles ganz gut.
ExterneIP -> Router
Router -> DMZ
Router -> LAN
NAT: Port 53 der Schnittstelle Internet egal woher -> DMZHost:53
Jetzt geht es um die Überwachung bzw. Überprüfen der korrekten Funktion "von innen heraus".
Ping aus dem LAN auf die ExterneIP funktioniert.
nslookup aus dem LAN auf die ExterneIP funktioniert nicht. Wie auch, die NAT-Weiterleitung ist ja nicht für die LAN-Schnittstelle eingerichtet. Eine zusätzliche Weiterleitung für die LAN-Schnittstelle will ich nicht einrichten.
Gibt es überhaupt eine Möglichkeit, von "innen heraus" zu testen, ob die Weiterleitung funktioniert (außer am Protokoll des DMZ-Host)? Wenn ich das hier so schreibe würde ich ja sagen nein. Wenn ich die DNS-Funktion von extern her testen will, muss ich das auch von externen Host machen - oder? Es gibt da keinen Loopback-Trick - nicht wahr?
Grüße
lcer
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 397629
Url: https://administrator.de/forum/routing-und-nat-auf-sich-selbst-397629.html
Ausgedruckt am: 25.04.2025 um 02:04 Uhr
4 Kommentare
Neuester Kommentar
Hi,
wenn Du rein die Funktion des Servers in der DMZ prüfen willst, dann kannst Du auch ohne NAT von intern diese prüfen, wenn der Router entsprechende ACLs hat. Aber wenn Du die Funktion des Servers bei Zugriff von Extern über die öffentliche IP prüfen willst, dann musst Du auch von Extern aus testen. Das geht nun mal nicht anders. Alles andere wäre Selbsttäuschung.
E.
wenn Du rein die Funktion des Servers in der DMZ prüfen willst, dann kannst Du auch ohne NAT von intern diese prüfen, wenn der Router entsprechende ACLs hat. Aber wenn Du die Funktion des Servers bei Zugriff von Extern über die öffentliche IP prüfen willst, dann musst Du auch von Extern aus testen. Das geht nun mal nicht anders. Alles andere wäre Selbsttäuschung.
E.
Hallo,
Und zum testen deines internen DNServers braucht es keine externen IP gefrickel, sondern nur ein DNS weiterleitung nach aussen wenn die externe Resource nicht in einer IP aufgelöst werden kann.
Erkläre uns was du genau willst bzw. meinst.
Gruß,
Peter
Zitat von @lcer00:
Jetzt geht es um die Überwachung bzw. Überprüfen der korrekten Funktion "von innen heraus".
Ping aus dem LAN auf die ExterneIP funktioniert.
nslookup aus dem LAN auf die ExterneIP funktioniert nicht.
Wir kennen deinen Router nicht, also wissen wir auch nicht ob Hairpin-NAT kann oder nicht. Einige können es, andere wiederum nicht. Es ist auch kein gefordertes Leistungsmerkmal, sondern Hersteller und Modelabhängig. Und was soll dir ein NSLookup ExterneIPdeinesRouters bringen? Mach das mal von einen Rechner der auch nach aussen darf oder ohne laufenden Proxy.Jetzt geht es um die Überwachung bzw. Überprüfen der korrekten Funktion "von innen heraus".
Ping aus dem LAN auf die ExterneIP funktioniert.
nslookup aus dem LAN auf die ExterneIP funktioniert nicht.
Wie auch, die NAT-Weiterleitung ist ja nicht für die LAN-Schnittstelle eingerichtet. Eine zusätzliche Weiterleitung für die LAN-Schnittstelle will ich nicht einrichten.
Und wie bekommen deine Clients im LAN dann Internet bzw. Verbindungen zu externen Geräte, Websites usw.?Gibt es überhaupt eine Möglichkeit, von "innen heraus" zu testen, ob die Weiterleitung funktioniert (außer am Protokoll des DMZ-Host)?
Da einige Router einen Zugriff von Innen auf die eigene Externe IP erkennen schalten die intern ein abkürzung ein. Wie der Hersteller das umgesetzt hat? Hairpin-Nat ist wie gesagt weder Standard noch vorgeschrieben noch als ein muss für Router. https://tools.ietf.org/html/rfc5128 oder https://en.wikipedia.org/wiki/HairpinningWenn ich die DNS-Funktion von extern her testen will, muss ich das auch von externen Host machen - oder?
Was willst du von extern in deine DMZ oder LAN denn DNS-mäßig von Extern testen. Betreibst du externe DNS oder was oder warum willst du ein Portforwarding für DNS einrichten. Dein DNS braucht nur raustelefonieren können und die Antwort lesen dürfen. Da reicht ein erlaubter ausgehender Traffic auf Port 53 dein deinen internen DNS Server.Und zum testen deines internen DNServers braucht es keine externen IP gefrickel, sondern nur ein DNS weiterleitung nach aussen wenn die externe Resource nicht in einer IP aufgelöst werden kann.
Erkläre uns was du genau willst bzw. meinst.
Gruß,
Peter
Hallo,
Haripin nat ist das richtige Stichwort. Ob das der Router kann, muss ich überprüfen.
Es geht um einen dynDNS-Server als Ersatz für dyndns-Anbieter und dessen Überwachung.
Danke erst mal.
Grüße
lcer
Haripin nat ist das richtige Stichwort. Ob das der Router kann, muss ich überprüfen.
Es geht um einen dynDNS-Server als Ersatz für dyndns-Anbieter und dessen Überwachung.
Danke erst mal.
Grüße
lcer
Hallo & Rückmeldung:
ist ein Bintec be.ip bzw. RS353bw. Dort heißt das "Loopback aktiv" unter NAT, und wenn man weiß was man sucht, finden sich auch einige Artikel sowie ein Eintrag im Benutzerhandbuch
Zum Sinn des ganzen noch folgende Erklärung:
Ich überwache das eigene selbstbau-DynDNS jetzt mittels PRTG einmal von einer entfernten PRTG-Probe eines anderen Standorts aus (Test1) und von der PRTG-Probe am Hauptstandort (Test2). (also doppelt.)
Solange beide Standorte per VPN verbunden sind, kann ich das komplette Funktionieren der DNS-Auflösung an Test1 erkennen. Bricht das VPN weg, sehe ich über Test2 wenigstens, dass es zu 99% nicht am DNS-Server liegt (geschätztes 1% für Fehlfunktionen des Loopback-NAT).
Danke nochmal.
Grüße
lcer
ist ein Bintec be.ip bzw. RS353bw. Dort heißt das "Loopback aktiv" unter NAT, und wenn man weiß was man sucht, finden sich auch einige Artikel sowie ein Eintrag im Benutzerhandbuch
Zum Sinn des ganzen noch folgende Erklärung:
Ich überwache das eigene selbstbau-DynDNS jetzt mittels PRTG einmal von einer entfernten PRTG-Probe eines anderen Standorts aus (Test1) und von der PRTG-Probe am Hauptstandort (Test2). (also doppelt.)
Solange beide Standorte per VPN verbunden sind, kann ich das komplette Funktionieren der DNS-Auflösung an Test1 erkennen. Bricht das VPN weg, sehe ich über Test2 wenigstens, dass es zu 99% nicht am DNS-Server liegt (geschätztes 1% für Fehlfunktionen des Loopback-NAT).
Danke nochmal.
Grüße
lcer
