2x 1721 VPN - DNS Problem
Moderator: Lancom-Systems Moderatoren
2x 1721 VPN - DNS Problem
Hallo zusammen,
sicherlich ist das Thema hier schon 100x besprochen worden, aber ich finde in der Suche einfach keine entsprechende Lösung.
Zwei 1721er am ADSL sind per VPN mit PreShared Key verbunden. VPN geht wunderbar. Routing steht.
Ping der IP von Standort A nach Standort B (Jeweil ein Server im jeweiligen Netz) klappt wunderbar.
Am Standort A steht eine Domäne mit AD (Windows 2003) und DNS & WINS.
Server ist 10.0.0.1
An Standort B laufen 5 PCs in einer Arbeitsgruppe / KEINE Domänenclients.
Was nicht funktioniert ist die Namensauflösung ohne FQDN. Ich habe im Lancom einen dns-forewarder für die Domäne mit gesetzt, und den Netbios Proxy am Standort B aktiviert. Netbios über Routing ist auf beiden Geräten aktiv.
Ein nslookup servername.domaene.local klappt (FQDN)
Ein nslookup servername (ohne FQDN) funktioniert nur wenn die Clients in der Domäne aufgenommen sind.
Auch Zugriffe auf Freigaben z.B. \\servername gehen nur bei Domänenzugehörigen Clients, nicht bei Arbeitsgruppen PCs.
Zudem sehen sich die verschiendenen Standorte in der Netzwerkumgebung nicht, was am fehlenden Broadcast via VPN liegt?
Vielleicht ist jemand so nett und schreibt kurz wie die Einstellungen zu machen sind.
Liebe Grüße
subby
sicherlich ist das Thema hier schon 100x besprochen worden, aber ich finde in der Suche einfach keine entsprechende Lösung.
Zwei 1721er am ADSL sind per VPN mit PreShared Key verbunden. VPN geht wunderbar. Routing steht.
Ping der IP von Standort A nach Standort B (Jeweil ein Server im jeweiligen Netz) klappt wunderbar.
Am Standort A steht eine Domäne mit AD (Windows 2003) und DNS & WINS.
Server ist 10.0.0.1
An Standort B laufen 5 PCs in einer Arbeitsgruppe / KEINE Domänenclients.
Was nicht funktioniert ist die Namensauflösung ohne FQDN. Ich habe im Lancom einen dns-forewarder für die Domäne mit gesetzt, und den Netbios Proxy am Standort B aktiviert. Netbios über Routing ist auf beiden Geräten aktiv.
Ein nslookup servername.domaene.local klappt (FQDN)
Ein nslookup servername (ohne FQDN) funktioniert nur wenn die Clients in der Domäne aufgenommen sind.
Auch Zugriffe auf Freigaben z.B. \\servername gehen nur bei Domänenzugehörigen Clients, nicht bei Arbeitsgruppen PCs.
Zudem sehen sich die verschiendenen Standorte in der Netzwerkumgebung nicht, was am fehlenden Broadcast via VPN liegt?
Vielleicht ist jemand so nett und schreibt kurz wie die Einstellungen zu machen sind.
Liebe Grüße
subby
Re: 2x 1721 VPN - DNS Problem
Hallo subby,
das hat zwar fast nichts mit den Lancoms zu tun...
Gruß
Mario
das hat zwar fast nichts mit den Lancoms zu tun...
Also das ist erst mal reines DNS. Clients unter Windows hängen zuerst ihr primäres DNS-Suffix an eine DNS-Abfrage ran. Falls es also auch ohne FQDN funktionieren soll, musst du dieses an den PCs im Standort B ändern (Das wird standardmässig für Mitglieder der Domain so gesetzt).Ein nslookup servername.domaene.local klappt (FQDN)
Ein nslookup servername (ohne FQDN) funktioniert nur wenn die Clients in der Domäne aufgenommen sind.
Und das ist jetzt zuerst DNS und bei Fehlschlagen NetBIOS. Falls du also wie oben beschrieben das Suffix änderst, funktioniert auch das problemlos. Falls diese Änderung nicht möglich ist, bleibt nur noch die Auflösung per NetBIOS. Auch wenn jetzt Backslash mit den Zähnen knirscht - aber vergiss mal gleich den NetBIOS-Proxy des Lancoms. Der ist rein für Arbeitsgruppen ohne WINS. Trag einfach bei den PCs im Standort B den WINS von Standort A ein.Auch Zugriffe auf Freigaben z.B. \\servername gehen nur bei Domänenzugehörigen Clients, nicht bei Arbeitsgruppen PCs.
Nein - das liegt am fehlenden Domain-Master-Browser in Standort B. Als solche können unter Windows nur Domain-Controller agieren.Zudem sehen sich die verschiendenen Standorte in der Netzwerkumgebung nicht, was am fehlenden Broadcast via VPN liegt?
Gruß
Mario
Ok,
ich habe also die Möglichkeit den Clients an Standort B einen zusätzlichen DNS Suffix mitzugeben, was nicht so toll ist.
Wenn ich allerdings an Standort B per DHCP DNS und WINS Server aus Standort A angebe, dann geht der gesammte DNS Traffic durch das VPN, also auch für Webseiten die augelöst werden sollen.
Gibt es im Lancom eine Möglichkeit eine Art von Bedingter Weiterleitung zu erstellen?
subby
ich habe also die Möglichkeit den Clients an Standort B einen zusätzlichen DNS Suffix mitzugeben, was nicht so toll ist.
Wenn ich allerdings an Standort B per DHCP DNS und WINS Server aus Standort A angebe, dann geht der gesammte DNS Traffic durch das VPN, also auch für Webseiten die augelöst werden sollen.
Gibt es im Lancom eine Möglichkeit eine Art von Bedingter Weiterleitung zu erstellen?
subby
Hi subby
Gruß
Backslash
Du sollst laut eddia nur den WINS-Server zuweisen! Der WINS-Server wird im LANCOM i.Ü. allgemeiner als NBNS (NetBIOS-Name-Service) bezeichnetWenn ich allerdings an Standort B per DHCP DNS und WINS Server aus Standort A angebe, dann geht der gesammte DNS Traffic durch das VPN, also auch für Webseiten die augelöst werden sollen.
Nur bei Angabe eines FQDN - aber genau das willst du ja nicht. DNS-mäßig beißt sich hier die Katze irgendwo in den Schwanz...Gibt es im Lancom eine Möglichkeit eine Art von Bedingter Weiterleitung zu erstellen?
Gruß
Backslash
OK,
also ich habe bisher unter TCP/IP -> DNS eine Weiterleitung für *.domainname.local eingerichtet und Verteile als WINS per DHCP den Server aus Standort A. Config auf Client neu gemacht. (ipconfig /release und flushdns)
Netbios Proxy an Standort B ist aktiviert und sollte es nach möglichkeit auch bleiben.
nslookup beispielserver liefert
Server: NameRouter.intern
Adress: Routeradresse
Servername wurde von NameRouter.intern nicht gefunden: Non-existent domain.
subby
also ich habe bisher unter TCP/IP -> DNS eine Weiterleitung für *.domainname.local eingerichtet und Verteile als WINS per DHCP den Server aus Standort A. Config auf Client neu gemacht. (ipconfig /release und flushdns)
Netbios Proxy an Standort B ist aktiviert und sollte es nach möglichkeit auch bleiben.
nslookup beispielserver liefert
Server: NameRouter.intern
Adress: Routeradresse
Servername wurde von NameRouter.intern nicht gefunden: Non-existent domain.
subby
Hallo Backslash,
Ergebnis: Null. Weder im Hauptsitz noch in der Außenstelle tauchen irgendwelche Einträge der anderen Seite auf.
Aber selbst wenn das funktionieren würde, ginge eines definitiv nicht. Die Clients im Hauptsitz würden nie per NetBIOS Hosts in der Außenstelle auflösen können, da sie immer ihren WINS befragen und da dieser sich nicht mit dem NBNS des Lancoms synchronisiert...
Gruß
Mario
ich hab das jetzt mal nachgestellt. NetBIOS Proxy in beiden Lancoms aktiviert und in der Außenstelle die lokale Arbeitsgruppe sowie im Hauptsitz die lokale Domain unter "Arbeitsgruppenname" eingetragen. Natürlich die NetBIOS Routingtabelle auf beiden Seiten gefüllt.Würde in diesem Szenario aber auch funktionieren - denn schließlich sind ja am Standort B nur Arbeitsgruppen...
Ergebnis: Null. Weder im Hauptsitz noch in der Außenstelle tauchen irgendwelche Einträge der anderen Seite auf.
Aber selbst wenn das funktionieren würde, ginge eines definitiv nicht. Die Clients im Hauptsitz würden nie per NetBIOS Hosts in der Außenstelle auflösen können, da sie immer ihren WINS befragen und da dieser sich nicht mit dem NBNS des Lancoms synchronisiert...
Gruß
Mario
Hi eddia
Gruß
Backslash
Du must natürlich auch auf beiden Seiten das LANCOM als WINS entweder manuell eintragen oder per DHCP zuweisen. Dann registriert sich jeder PC (ob in oder außerhalb der Domäne) brav mit seinem NetBIOS-Namen beim LANCOM und schon funktioniert die entfernte NetBIOS-Auflösung über den NetBIOS-Proxy...ich hab das jetzt mal nachgestellt. NetBIOS Proxy in beiden Lancoms aktiviert und in der Außenstelle die lokale Arbeitsgruppe sowie im Hauptsitz die lokale Domain unter "Arbeitsgruppenname" eingetragen. Natürlich die NetBIOS Routingtabelle auf beiden Seiten gefüllt.
Ergebnis: Null. Weder im Hauptsitz noch in der Außenstelle tauchen irgendwelche Einträge der anderen Seite auf.
Der echte WINS, den subby in der Zentrale betreibt, ist eh relativ wertfrei, da er ja auf der Filialseite keinen weiteren WINS stehen hat, der sich mit dem Zentral-WINS synchronisiert. Daher kann er auch problemlos das LANCOM als WINS einsetzen, das macht in diesem Szenario überhaupt keinen Unterschied. Der Unterschied zwischen echten WINS und dem NetBIOS-Proxy wird erst dann wichtig, wenn die jeweils andere Seite in der Netzwerkumgebung auftauchen soll - aber das Thema kennst du ja...Aber selbst wenn das funktionieren würde, ginge eines definitiv nicht. Die Clients im Hauptsitz würden nie per NetBIOS Hosts in der Außenstelle auflösen können, da sie immer ihren WINS befragen und da dieser sich nicht mit dem NBNS des Lancoms synchronisiert...
Gruß
Backslash
Hallo Backslash,
Gruß
Mario
obwohl der Lancom im Hauptsitz alle lokalen NetBIOS Einträge aufführt? Der scheint ja irgendwie eine Art Sniffer für NetBIOS zu sein, da er auch ohne dass irgendein Client im Hauptsitz den NBNS des Lancoms eingetragen bekommt, eine komplette Liste erstellt. Wo ist da der Unterschied?Du must natürlich auch auf beiden Seiten das LANCOM als WINS entweder manuell eintragen oder per DHCP zuweisen. Dann registriert sich jeder PC (ob in oder außerhalb der Domäne) brav mit seinem NetBIOS-Namen beim LANCOM und schon funktioniert die entfernte NetBIOS-Auflösung über den NetBIOS-Proxy...
Gruß
Mario
Hi eddia,
es kommt immer darauf an, was für Knotentypen im Netz vorhanden sind. Sind nur P-Knoten im Netz, hat das LANCOM keine Chance, die Liste zu erstellen, wenn es nicht selbst der WINS ist. Hast du aber B-, M- oder H-Knoten im Netz, Broadcasten diese ihren Namen und Arbeitsgruppe/Domain ins Netz - und dann hat das LANCOM einen Angelpunkt, um die Liste aufbauen zu können.
Ach ja: Die Angabe der Arbeitsgruppe im NetBIOS-Proxy dient dazu, dem LANCOM einen Startpunkt für die Scan zu geben, damit es nicht darauf warten muß, bis irgendwer seinen Namen und Arbeitsgruppe/Domain broadcasted...
In jedem Fall gilt: Sobald die Liste auf die andere Seite übertragen wurde und dort das LANCOM als WINS eingetragen wurde, ist die Auflösung der entfernten Namen durch das LANCOM - auch in Domänen(!) - möglich. Natürlich löst das LANCOM auch Broadcast-Anfragen für entfernte Namen auf.
Ist aber ein anderer Rechner als WINS eingetragen, dann funktioniert der NetBIOS-Proxy im LANCOM nicht, da M- und H- Knoten nur dann eine Broadcast-Anfrage stellen, wenn der WINS gar nicht antwortet. Antwortet er aber mit einem "no name", dann geben sich M- und H-Knoten damit zufrieden (ein P-Konten stellt i.Ü. niemals eine Broadcast-Anfrage)...
Gruß
Backslash
es kommt immer darauf an, was für Knotentypen im Netz vorhanden sind. Sind nur P-Knoten im Netz, hat das LANCOM keine Chance, die Liste zu erstellen, wenn es nicht selbst der WINS ist. Hast du aber B-, M- oder H-Knoten im Netz, Broadcasten diese ihren Namen und Arbeitsgruppe/Domain ins Netz - und dann hat das LANCOM einen Angelpunkt, um die Liste aufbauen zu können.
Ach ja: Die Angabe der Arbeitsgruppe im NetBIOS-Proxy dient dazu, dem LANCOM einen Startpunkt für die Scan zu geben, damit es nicht darauf warten muß, bis irgendwer seinen Namen und Arbeitsgruppe/Domain broadcasted...
In jedem Fall gilt: Sobald die Liste auf die andere Seite übertragen wurde und dort das LANCOM als WINS eingetragen wurde, ist die Auflösung der entfernten Namen durch das LANCOM - auch in Domänen(!) - möglich. Natürlich löst das LANCOM auch Broadcast-Anfragen für entfernte Namen auf.
Ist aber ein anderer Rechner als WINS eingetragen, dann funktioniert der NetBIOS-Proxy im LANCOM nicht, da M- und H- Knoten nur dann eine Broadcast-Anfrage stellen, wenn der WINS gar nicht antwortet. Antwortet er aber mit einem "no name", dann geben sich M- und H-Knoten damit zufrieden (ein P-Konten stellt i.Ü. niemals eine Broadcast-Anfrage)...
Gruß
Backslash