DNS Server + Probleme mit Namensauflösung im lokalen Netz

[Thorti83]

Hallo...

Ich habe ein Problem mit einem Win-Server (Win2k3).

Situation:
-Internet kommt von T-Online, keine Standleitung, normale DSL flat mit 24h Trennung
-vor den lokalen Rechnern sitzt ein Router (SMC 7004 ABR)
-im DMZ eingetragen ist der Active Directory Hauptserver, auf dem auch der DNS Server und der Applikationsserver (IIS 6.0) läuft, ausserdem sind alle wichtigen Dienste per port-forwarding auf den Server gerichtet
-DNS wird per dyndns.org realisiert

So, nun kommt die Frage. Obwohl es eigentlich nie so gedacht war, würde es mich interessieren, ob man bei einem Zugriff aus dem Internet die einzelnen lokalen Rechner irgendwie ansprechen könnte.
per IP funktioniert das nicht, ganz klar, maximal lässt sich der Router anpingen - was dahinter mit lokalen IP Adressen alles los ist kann man von aussen ja nich sehn.

Aber wieso funktioniert es nicht per DNS?

wir nehmen mal eine Beispieladresse mit der sich arbeiten lässt "beispiel.dyndns.org". Nehmen wir an ich hätte diese Adresse und bei dyndns.org ist der Rechner bzw. die externe IP des Routers korrekt eingetragen.

Den Server im internen Netz nennen wir einmal "Server1"
Dazu tun wir noch einen Client mit dem Namen "Client1"
Die interne Domain trägt denselben Namen wie die dyndns Adresse.

Da beide über einen DNS Eintrag am lokalen Server verfügen lassen sich beide jeweils mit Namen+DNS Suffix (z.B. Server1.beispiel.dyndns.org) im internen Netz ansprechen.

Von aussen aber lässt sich nur auf beispiel.dyndns.org zugreifen - nicht aber auf Server1.beispiel.dyndns.org.

Wieso nicht?

Wenn eine Anfrage von aussen an Server1.beispiel.dyndns.org gestellt wird, dann sollte das doch so funktionieren das die Anfrage zuerst an dyndns.org geht. Die sagen wo beispiel.dyndns.org liegt, und wenn dann die Anfrage hier ankommt sollte mein Server doch in der Lage sein Server1.beispiel.dyndns.org zu lokalisieren.

Funktioniert aber nicht.

Zuerst erschien mir die Erklärung logisch das das natürlich nicht gehen kann weil DNS Server ja auch nix anderes tun als IPs einen Namen zu geben. Und das ändert ja nichts an der Tatsache das die IPs keine offiziellen sind => nicht an den anfragenden Client übergeben werden können und zu einer Fehlermeldung führen.

Nach dieser Theorie hört das "externe DNS" quasi am Eingang des Routers auf, während das "interne DNS" erst am Router beginnt, und diese beiden nicht vermittelbar sind.

Aber dann ist mir eingefallen das DNS ja doch ins interne Netz übertragen und wieder zurück ins externe gegeben werden kann. Überprüft habe ich das indem ich mal schnell einen 2ten Webserver aufgemacht habe und eine 2te dyndns Adresse angelegt habe die auf dieselbe IP verweist. Und das funktioniert doch auch. Nach obiger Theorie müsste ein Client - egal welche der beiden dyndns Adressen er eingibt - immer auf derselben Seite Landen. Die Anfrage geht an Port 80, wird ins interne Netz an Server1 weitergeleitet und fertig. Aber hier ist man ja sehr wohl in der Lage dem Webserver zu sagen auf welchen DNS Header er jeweils anspringen soll. Das heisst bei beispiel2.dyndns.org wird ganz korrekt eine andere Seite angezeigt als bei beispiel.dyndns.org

Tja, und nun komme ich nicht weiter. Ich bin zwar kein Netzwerkprotokoll-Gott, aber es sollte doch irgendwie möglich sein...

Schliesslich werden ja die HTTP Anfragen von aussen auch im internen Netz ohne Probleme weitergeleitet, wieso also sollte es nicht gehen das man die Rechner auch einzeln zugänglich macht?

Wenn jemand Plan davon hat wär ich sehr dankbar. Egal ob nun bei mir ein grobes Verständnis-Problem vorliegt oder aber ich einfach nur irgendwo einen falschen Weg gegangen bin, hauptsache ich weiss woran es liegt!

Optimal wäre es natürlich wenn jemand bescheidwüsste was genau man nun noch tun könnte um das ganze zum laufen zu bewegen. Über Zoneneinträge im DNS Server funktioniert leider garnichts, oder ich bin zu blöd die Forward und Reverse lookup zones richtig zu konfigurieren...

[noid]

hilft es dir weiter, wenn ich dir sage, dass dns nur eine auflösung in ip-adressen macht?
wie willste nun deine lokalen adressen von außen ansprechen, wenn du ne nat hast? die nat ersetzt ja alle quell-ips durch die der nat-maschine.

-> geht also nicht.

was du machen könntest wäre ein portfw mit vrsch. ports uf die einzelnen rechner. dh. du könntest mit verschd. portadressen zB per ssh auf die einzelnen clients zugreifen.
einfach hingegen wäre ein vpn.
dann brauchst du von extern ein client und wählst dich so in dein netzwerk ein

-> jetzt kannst du über den tunnel jeden internen rechner mit seiner internen ip ansprechen.

nachtrag: der http-verkehr wird je nach konfiguration auch anders abgewickelt. entweder durch ein application-layer-gateway (proxy, deine internen rechner connecten nur zum gateway und dürfen nicht direkt nach außen) oder du lässt einfach am paket-filter port80-anfragen nach außen durch.
bei den anfragen von außen geht es sicherlich nicht, dass beide internen http-server auf port80 lauschen. das glaub ich beim besten willen nicht. über verschd. ports kannst du wie gesagt in den forwarding-regeln festlegen auf welchen rechner die pakete eines best zielports weitergeleitet werden.

[Thorti83]

ja nee, is klar, so weit hab ich das ja auch schon gerafft das es per IP (und damit *eigentlich* auch per DNS) nicht funktionieren kann.

Die Frage is nur - wenn man das Problem nicht lösen kann, lässt sich denn auch kein workaround finden? HTTP Requests laufen ja wie Du schon angemerkt hast durch den Application Layer - wobei der Request im Header die DNS Adresse erhält an die er gerichtet ist, nicht nur die IP zu der er letztendlich vom Router weitergeleitet wird. So sind verschiedene Webserver auf einem Rechner in der Lage unterscheiden zu können an welchen der Server die Anfrage ging.

Aber wenn ich per HTTP ganz ganz einfach mehrere Server auf derselben physikalischen Maschine managen kann (oder auch weiterleiten kann auf andere lokale oder nichtlokale Webserver), wieso gehts ned per DNS?

Der Webserver macht ja in dem Fall nichts anderes als der im Header des HTTP Requests angegeben DNS Adresse eine lokale IP zuzuweisen. Der Client bemerkt davon garnichts.

Nun müsste sich das doch auch in der Namensauflösung realisieren lassen. Dem Client kann es ja kackegal sein welche IP der Server hat, wenn er nur mit dem primären lokalen DNS Server (als "Gegenstück" zum Webserver in diesem Beispiel) kommuniziert und dieser anhand seiner Config entscheidet welchen weiteren Rechner er ansprechen soll.

edit: Um das nochmal zu verdeutlichen: Ich könnte ja auf einem 2ten lokalen Server die Webseite hinterlegen, den 1sten Server aber weiterhin als Master nutzen. Im Webserver würde ich nur angeben das beispiel.dyndns.org nicht auf dem Rechner liegt sondern von einem anderen Rechner im LAN bereitgestellt wird.

Genau dasselbe bräuchte ich mit der internen Namensauflösung. Die Anfrage soll reinkommen, und der DNS Server soll sagen "ja klaro, *weiterleit an passenden rechner* siessudahassu"

[noid]

moment, dein webserver bekommt erstmal _einen_ request. im http-get steht ja drin was er haben will (url wird mitgeschickt).
deine 2 webserver auf der kiste sind doch virtuell, dh ein webserver hängt davor und verteilt je nach http-get die anfragen. deine beiden http-server horchen also nur auf die eine url, die du einstellt hast.
das ist aber eine sache, die mit ip-adressen und nat, sowie dns _nichts_ zu tun haben. wenn schon http-segmente geschickt werden, dann ist die ganze sache mit dns schon gelaufen.

zwischen einer url und dns gibt es einenen unterschied. dns ist ein protokoll zu namensauflösung.

deine konfiguration geht auch nur, weil alle anfragen von extern port80 auf _eine_ kiste geschickt werden. diese zerpflückt dann die segmente und schaut anhand des http-inhalts an an welchen server das geht.
dennoch werden alle pakete nur an deinen smc-router geschickt.
einen 2ten rechner wirst du über 2 dns-namen also auch nicht von extern ansprechen können, wenn alle webserver auf port80 laufen sollen und du nicht einen davor hast, der die anfragen an die andren verteilt.

das mit dem application-layer war auch nur ein beispiel wenn du noch nen proxy hättest. der smc ist aber afaik ein paket-filter - er routet nur nach port- ud ip-nummern. deine konfiguration ist also glücklich gewählt.

wie gesagt, portforwarding ist der schlüssel. auch wenn das bei nem ftp mit nat nicht immer einfach ist.
aber vnc und vpn sollten gehen.

DAS GEHT NICHT, WEIL ANDRE ANFRAGEN KEINERLEI INFORMATION ZUR DOMAINE ENTHALTEN!!! IP-ADRESSEN WERDEN ZUM TRANSPORT GENUTZT. HTTP IST EINE AUSNAHME. DNS-ABFRAGEN LAUFEN MEIST VOR EINER VERBINDUNG ÜBER EIN EXTRA-PROTOKOLL AB, MUSS ABER BEI KENNTNIS DER IP NICHT SEIN.

jetzt klar? keine andre anwendung bekommt das hin, da hier ein kurzer dns-request an einen dns-server geschickt wird (und das ist nicht dein rechner). dann werden segmente mit der ip-geschickt. der router kann nun nur anhand des ports an einzelne rechner gezielt forwarden. und das ganze hat halt mit nat zu tun.
wenn du ne eigene ip-range hättest, dann würde sowas gehen.

[Thorti83]

*klick*

ok ich glaub jetzt hab ichs verstanden... thx!
Hab mich da gedanklich total in die falsche richtung verrannt.

Mein Gedanke war halt der das wenn ich mehrere physikalische HTTP Server auf denen unterschiedliche Domains liegen mit einer "richtigen" IP Adresse betreiben kann sofern es einen "Master-Webserver" gibt der die Verbindungen managed - der Umkehrschluss sein müsste das man andere Protokolle bzw. Dienste auch dazu vergewaltigen kann.

Sry, wennsch mich bissi doof angestellt hab, aber wenn man sich erstmal nen bescheuerten Gedanken ins Hirn gesetzt hat...