DNS-Server hinter NAT

Ich habe einen Bind 9-DNS-Server hinter einer NAT-Firewall. Angenommen, die IP-Adresse für das Internet lautet 1.2.3.4

Es gibt keine Einschränkungen für den ausgehenden Datenverkehr und Port 53 (TCP / UDP) wird von 1.2.3.4 an den internen DNS-Server (10.0.0.1) weitergeleitet. Weder auf dem VPS noch auf dem internen Bind 9-Server gibt es Regeln für IP-Tabellen.

Von einem entfernten Linux-VPS, der sich an einer anderen Stelle im Internet befindet, funktioniert nslookup einwandfrei

# nslookup foo.example.com 1.2.3.4
Server:    1.2.3.4
Address:   1.2.3.4#53

Name:      foo.example.com
Addresss:  9.9.9.9

Wenn hostich jedoch den Befehl auf dem Remote-VPS verwende, erhalte ich die folgende Ausgabe:

# host foo.example.com 1.2.3.4
;; reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53
;; reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53
;; connection timed out; no servers could be reached.

Vom VPS aus kann ich eine Verbindung (über Telnet) zu 1.2.3.4:53 herstellen

Auf dem internen DNS-Server (10.0.0.1) scheint der Host-Befehl in Ordnung zu sein:

# host foo.example.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

foo.example.com has address 9.9.9.9

Irgendwelche Vorschläge, warum sich der Host-Befehl auf meinem VPS über die Antwort beschwert, die von einem anderen Port zurückkommt, und was kann ich tun, um dies zu beheben?

Weitere Informationen:

Von einem Windows-Host außerhalb des Netzwerks

>nslookup foo.example.com 1.2.3.4
DNS request timeout
    timeout was 2 seconds
Server: UnKnown
Address: 1.2.3.4

DNS request timed out.
    timeout was 2 seconds
DNS request timed out.
    timeout was 2 seconds
DNS request timed out.
    timeout was 2 seconds
DNS request timed out.
    timeout was 2 seconds
*** Request to UnKnown timed-out

Dies ist eine Standardinstallation von bind aus Ubuntu 12.04 LTS mit etwa 11 konfigurierten Zonen.

$ named -v
BIND 9.8.1-P1

TCP-Dump (gefiltert) vom internen DNS-Server

20:36:29.175701 IP pc.external.com.57226 > dns.example.com.domain: 1+ PTR? 4.3.2.1.in-addr.arpa. (45)
20:36:29.175948 IP dns.example.com.domain > pc.external.com.57226: 1 Refused- 0/0/0 (45)
20:36:31.179786 IP pc.external.com.57227 > dns.example.com.domain: 2+[|domain]
20:36:31.179960 IP dns.example.com.domain > pc.external.com.57227: 2 Refused-[|domain]
20:36:33.180653 IP pc.external.com.57228 > dns.example.com.domain: 3+[|domain]
20:36:33.180906 IP dns.example.com.domain > pc.external.com.57228: 3 Refused-[|domain]
20:36:35.185182 IP pc.external.com.57229 > dns.example.com.domain: 4+ A? foo.example.com. (45)
20:36:35.185362 IP dns.example.com.domain > pc.external.com.57229: 4*- 1/1/1 (95)
20:36:37.182844 IP pc.external.com.57230 > dns.example.com.domain: 5+ AAAA? foo.example.com. (45)
20:36:37.182991 IP dns.example.com.domain > pc.external.com.57230: 5*- 0/1/0 (119)

TCP-Dump vom Client während der Abfrage

21:24:52.054374 IP pc.external.com.43845 > dns.example.com.53: 6142+ A? foo.example.com. (45)
21:24:52.104694 IP dns.example.com.29242 > pc.external.com.43845: UDP, length 95

Um zusammenzufassen, was zuvor in Kommentaren geschrieben wurde, mit einigen weiteren Erklärungen:

Es sieht ein bisschen so aus, als ob Ihre NAT-Regeln für UDP verletzt wurden. Ein Hinweis ist die Fehlermeldung reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53und Ihre Ablaufverfolgung vom Client, wo die Antwort aussieht dns.example.com.29242 > pc.external.com.43845: UDP, length 95. Der Quellport für das Antwortpaket sollte 53 sein. Er ist in Ihrem Speicherauszug korrekt, der vom DNS-Server stammt (wo er zu domainAnzeigezwecken aufgelöst wird).

Während einige (insbesondere historische) Resolver möglicherweise DNS-Antworten von verschiedenen Ports / IPs akzeptieren, würden die meisten dies nicht tun - hauptsächlich aus Sicherheitsgründen, um DNS-Spoofing- und Cache-Vergiftungsangriffe zu verhindern .

In jedem Fall sollte Ihr Router für verbindungslosen UDP-NAT-Verkehr Statusdaten aus dem zuvor empfangenen UDP-DNS-Abfragepaket beibehalten und das IP: Port-Tupel für das Antwortpaket erneut auf 1.2.3.4:53 zuordnen - was anscheinend nicht der Fall ist . Dies kann ein Konfigurationsfehler oder ein Fehler in der Art und Weise sein, wie der Router die UDP-Statustabelle für Portweiterleitungsfälle verarbeitet. Am besten öffnen Sie einen Fall beim Kundensupport des Herstellers (nachdem Sie den Code auf den neuesten / besten Stand gebracht haben) im Voraus - ein solches Problem wurde wahrscheinlich bereits von anderen Benutzern bemerkt und ist daher wahrscheinlich bereits behoben.

OK ... ... ich werde das nur einmal sagen ... ... Sie können kein privates DNS über ein NAT erreichen, es sei denn, das NAT ist das DNS. Wenn Sie vorwärts portieren müssen, um zu einem Gerät zu gelangen, muss das Gerät so konfiguriert sein, dass es auf diesen Port reagiert. Zum Beispiel sende ich eine DNS-Abfrage an einem beliebigen Port an einen DNS in meinem internen Netzwerk. Ich benötige keine Portnummer, da sie sich nicht hinter einem NAT befinden. Die Nachricht ist direkt und ich erhalte eine DNS-Suche von meinem lokalen DNS-Server , läuft auf den Standard-DNS-Ports. Sie haben eine Abfrage an einem bestimmten Port an ein externes Netzwerk gesendet. Ist dieser Port der defekte DNS-Antwortport? WENN nicht, ich denke du weißt welches ist. Es wurde Ihnen in der Fehlermeldung gegeben. Versuchen Sie, Ihren DNS-Server so einzustellen, dass er nach Möglichkeit auf bestimmte Portnummern reagiert. Stellen Sie es so ein, dass es wie in Ihrem Beispiel auf 53 reagiert. Wenn es immer noch nicht geht, Ihr NAT leitet die Nachricht an eine ausgehende Portnummer um. Nur weil Sie Daten über die Portnummer an einen bestimmten Computer senden, bedeutet dies nicht, dass die Daten über dieselbe Portnummer zurückkommen. Der DNS-Antwortport kann unterschiedlich sein, was Problem A ist, und ein Router sendet die Antwort nach NAT an einem offenen Port entlang der Rücksprungadresse zurück, einem Port, der nicht unbedingt mit dem eingehenden Port identisch ist. Zuerst geht Ihre Nachricht an den Router, dann an den gewünschten Port, dann an den Computer, an den der Port weitergeleitet wird, und kehrt dann entlang des Antwortports zum Router zurück, der die Adresse und den Port übersetzt und an Ihre Adresse zurücksendet. Versuchen Sie, den Router auf der DNS-Seite zu portieren. Stellen Sie Port 53 ein, wenn Port 53 hinter dem NAT eingeschaltet wird. Wenn das nicht funktioniert, Überprüfen Sie Ihren DNS-Server und stellen Sie ihn so ein, dass er auch auf Port 53 reagiert. DasSollte ermöglichen, dass die Nachrichten funktionieren. Wenn dies ein DNS für ein VPN-Netzwerk ist, sollte das VPN aktiv sein und dieser Server sollte den Port weiterleiten, während der DNS eine statische Adresse im VPN-Subnetz hat. Jetzt können Sie den VPN-Hostserver und den Client-Server verbinden, und jeder hinter einem Client-Server kann das DNS als primäres, das Internet-Gateway als sekundäres und das ISP-DNS als tertiäres DNS sehen.