Domänenzugriff via VPN

[MariusP]

Hi,
Du solltest nicht generell alle WINS freigeben, sondern eher nur die die vom VPN-Netz kommen.
Gruß

[Bernie137]

Hallo Peter,

das freut mich zu hören, dass es erst mal prinzipiell funktioniert. Ich möchte Dir noch ein paar Tipps geben, damit Du nicht in einer Sackgasse landest.

Dank Dir kann ich jetzt die Freigaben aus Standort A in Standort B über die IP-Adressen mounten. Auch die Drucker findet er über die IP Adressen.

Prima, der Zugriff geht schon mal prinzipiell, was fehlt ist eine funktionierende DNS Auflösung.

Leider geht WINS noch nicht! Das macht Problem bei den Druckern. Ich habe eine Default Regel gefunden in der Firewall die wohl alle WINS-Anfragen blockt.

Das ist nicht das eigentliche Problem. ich versuche das mal kurz an der Stelle zu erklären:
Angenommen ein Server im Standort A heißt "Filesrv", dann ist das gleichzeitig sein WINS-Name. Jedoch der DNS Name ist Filesrv.deinedomain.local. WINS brauchte man zu Zeiten von Windows NT4. In einer solche Domain gab es damals kein Active Directory und DNS war dafür nicht notwendig. Ab einer Windows 2000 Domain gilt: DNS zwingend erforderlich, sonst dauert eine Anmeldung an einem Client auch mal wesentlich länger als gewöhnlich. Der Client muss also zwingend mit "seinem" DNS Server seiner zugehörigen Domain kommunizieren. D.h. in seinen TCP/IP Einstellungen MUSS dass der erste DNS Eintrag sein. Der zweite DNS Eintrag wird nur befragt, wenn der erste DNS Server überhaupt nicht erreichbar ist - nur das verstehen viele nicht und denken hier verkehrt und tragen mal einen externen DNS wegen Internet und eine zweiten DNS fürs lokale Netz ein - FATAL! Sämtliche *.deinedomain.local Anfragen landen beim Internet DNS Server und der kennt filesrv.deinedomain.local nicht.

WINS benutze man dazu, damit man im Windows Explorer unter Netzwerkumgebung "hübsch" die Netzwerkcomputer inkl. Freigaben sehen und anklicken kann, eben mit WINS Name "Filesrv". Diese Meldungen werden als Broadcasts im Netzwerk rumgedröhnt und enden beim Router. Man kann nun explizit konfigurieren, dass diese Meldungen auch in den VPN Tunnel zum Standort B gelangen, jedoch "belastet" das die Verbindung mehr als es nutzt. Die Blocking Route hat Ihren Sinn und stammt noch bissel aus ISDN-Zeiten, weil da bei jedem Broadcast eine kostenpflichtige Wählverbindung aufgebaut wurde, damit quasi ne Dauerverbindung.

Heutzutage erledigt man dass vernünftigerweise nicht mit WINS UNC-Pfaden \\filesrv\freigabe, sonder mit DNS UNC Pfaden: \\filesrv.deinedomain.local\freigabe und weist einen Laufwerksbuchstaben zu oder baut eine Verknüpfung auf den Desktop. Man klickt nicht mehr in der Netzwerkumgebung herum, sondern präsentiert es dem User mundgerecht. Dazu braucht man aber DNS und nicht WINS.

Kurzum, Dein Client im Standort B bekommt als ersten DNS Server den lokalen Lancom Router vom Standort B eingetragen. Der Lancom Router muss sich nun kümmern bei einer DNS Anfrage auf \\filesrv.deinedomain.local\feigabe, dass er den DNS Server für *.deinedomain.local im Standort A über den VPN Tunnel befragt unbd die korrekte Antwort ausspuckt.

Folgende Einstellungen sind im Router Standort B notwendig, erklärt anhand LANconfig:
1. TCP/IPv4 -> DNS (aktiviert) -> Weiterleitungen -> Hinzufügen: *.deinedomain.local mit VPN-Gegenstelle Standort A (oder direkt die IP-Adresse des DNS von Standort A, sollte auch klappen)
2. Kommunikation -> Protokolle -> IP-Parameter -> hinzufügen: VPN-Gegenstelle Standort A, erster DNS=<Dein DNS Server für *.deinedomain.local im Standort A>, zweiter DNS=<Dein zweiter DNS Server für *.deinedomain.local im Standort A>, alle anderen Werte können bei 0.0.0.0 stehen bleiben. Den VPN Tunnel mal auftrennen und neu "wählen" lassen, dass es "begreift".
Vorraussetzung: Die DNS Server im Standort A können auch über den VPN Tunnel mit Standort B kommunizieren und akzeptieren in Ihrer Windows Firewall DNS ANfragen aus einem anderen Subnetz (nämlich Standort B).

vg Heiko

PS: Kurz ist relativ für die Erläuterung

[pcg0506]

Servus Heiko,

und wieder vielen Dank für Deine Antwort und die dafür aufgewendete Zeit! Ich finde es wirklich klasse, dass Du mir das so ausführlich erklärst. Genau das fehlt mir.
Ich habe jetzt die Änderungen vorgenommen. Leider ohne Erfolg. Der Anmeldeserver ist immer noch nicht erreichbar, wenn ich einen Domänen-Benutzer anmelden will der auf der Client-Maschine noch nicht angemeldet war. Muss ich ggf. noch weitere Ports freischalten? Bzw. der Anmeldedienst auf dem AD-Server hatte noch keinen Haken in der Firewall , dass er „zugelassen“ wird. Den habe ich jetzt gesetzt. Konnte es aber leider nicht testen, weil ich den verdammten Client-Rechner nicht remote „aufwecken“ kann. Vor Ort bin ich erst wieder in 2-3 Wochen. Ich habe mal Screenshots von den beiden letzten Änderungen gemacht. Passen die? Lancom Router sind immer die 192.168.xx.18 in den beiden Netzen. Irgendwann kommt auch noch ein dritter Standort dazu.
Wenn ich vor Ort bin könnte ich die AD-Firewall auch einmal komplett ausschalten um zu überprüfen ob es daran liegt…..
Schon mal Danke und ein schönes Wochenende
Peter


Bzw.: besser der Text

---------IP-Paramter------------------------------------------

Gegenstelle IP-Adresse Netzmaske Mask.-IP-Adresse Standard-Gateway Erster DNS Zweiter DNS Erster NBNS Zweiter NBNS
xxxxxxxx 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 192.168.71.18 192.168.72.18 0.0.0.0 0.0.0.0


---------DNS - Weiterleitung------------------------------
Domäne Tag Gegenstelle
192.168.71.18 0 xxxxxxxx

[Bernie137]

Hallo Peter,

Der Anmeldeserver ist immer noch nicht erreichbar, wenn ich einen Domänen-Benutzer anmelden will der auf der Client-Maschine noch nicht angemeldet war.

Systematisch vom Client PC mit einem "bekannten" Konto ping ausführen, auch auf die DNS Namen der Server (am DNS wird vermutlich das Problem noch liegen).

Muss ich ggf. noch weitere Ports freischalten? Bzw. der Anmeldedienst auf dem AD-Server hatte noch keinen Haken in der Firewall , dass er „zugelassen“ wird.

Durchaus möglich und der Anmeldedienst wird auf alle Fälle benötigt. Jedoch musst Du systematisch vorgehen: Von dem besagtem Client mit einem "bekannten" Konto der Reihe nach alles anpingen: lokales Gateway (192.168.72.18), entferntes Gateway (192.168.71.18), Server im anderen Netz auf IP (192.168.71.x), dann auf Name (server.DeineDomain.local). Wenn diese Kette funktioniert, dann ist die letzte Suche in der Windows Firewall des entsprechenden Servers zu suchen (sofern die Windows Firewall Pings/Antworten erlaubt).

Ich habe mal Screenshots von den beiden letzten Änderungen gemacht. Passen die? Lancom Router sind immer die 192.168.xx.18 in den beiden Netzen. Irgendwann kommt auch noch ein dritter Standort dazu. ...

---------IP-Paramter------------------------------------------

Gegenstelle IP-Adresse Netzmaske Mask.-IP-Adresse Standard-Gateway Erster DNS Zweiter DNS Erster NBNS Zweiter NBNS
xxxxxxxx 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 192.168.71.18 192.168.72.18 0.0.0.0 0.0.0.0

Nein!
Im Standort B (da wo der einzelne Client ist), nehme ich an ist der IP-Kreis 192.168.72.0/24. Nur im Router 192.168.72.18 ist folgendes einzutragen:

Code: Alles auswählen

Gegenstelle IP-Adresse Netzmaske Mask.-IP-Adresse Standard-Gateway Erster DNS Zweiter DNS Erster NBNS Zweiter NBNS
xxxxxxxx 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 192.168.71.50 192.168.71.51 0.0.0.0 0.0.0.0

Meine Annahme ist, dass 192.168.71.50 und 192.168.71.51 die DNS Server im Standort A sind. Diese müssen nämlich befragt werden für die Domain im Standort A, wozu der einzelne Client im Standort B gehört.

---------DNS - Weiterleitung------------------------------
Domäne Tag Gegenstelle
192.168.71.18 0 xxxxxxxx

Nein, nicht korrekt!
Nur im Router 192.168.72.18 (Standort B) muss stehen, wenn 192.168.71.50 ein DNS Server im Standort A ist:

Code: Alles auswählen

Domäne Tag Gegenstelle
<*.DeineDomain.local> 0 192.168.71.50

oder

Code: Alles auswählen

Domäne Tag Gegenstelle
<*.DeineDomain.local> 0 <Gegenstelle-Standort-A>

vg Heiko