Wie im Thema zuvor haben wir ein Problem beim Zugriff auf Resourcen zwischen zwei Standorten.
Situation:
Standort A (W2k3 Domain), LANCOM 1721 , Netzwerk 192.168.111.0/24
Standort B mobile Clients (Mitgleider der Domain von Standort A), LANCOM 1811, Netzwerk 192.168.63.0/24
Routing zwischen beiden Netzen funktioniert. DNS am Standort A übernimmt der W2k3 Server (Eintrag unter TCP/IP im 1721). Am Standort B ist der Eintrag weiterhin 0.0.0.0 mit Domäne "intern". Ein hinzufügen des DNS Servers von Standort A führte dazu, dass eine DNS Auflösung nicht mehr funktioniert (DynDns schlägt fehlt.)
Für die Verbindung über den SDSL habe ich am Standort A ein Routing TAG=2 vergeben, welches im IP-Router als auch im VPN Verbindungliste vergeben ist. Die Routing Regel sagt alles was zum Standort-B.DynDNS.org geht soll über die Route mit Tag=2.
Problem 1)
Standort A ist seit kurzem per Loadbalancer an ADSL und SDSL Leitung angeschlossen. die VPN Verbindung wird nun über SDSL abgewickelt. Seit der Umstellung bekommen nun alle Clients am Standort B die Meldung "Windows Systemfehler-Ein gleicher Name ist bereits im Netzwerk vorhanden."
Die Mitarbeiter bekommen von Windows die Meldung: "Es wurde kein Zertifikat gefunden um sie am Netzwerk anzumelden." Es wird kein WLAN verwendet !
Problem 2)
von Standort A kann ich nicht auf die Rechner am Standort B zugreifen. EIn Ping ist jedoch möglich. Ein Zugriff auf Freigaben von B nach A sind möglich.
Interessanterweise hat der 1811 am Standort B alle Netbios Informationen von A und B.
Habt Ihr eine Idee ?
Gruß Laboe
DNS Server und Netzwerkzugriff
Moderator: Lancom-Systems Moderatoren
DNS Server und Netzwerkzugriff
LANCOM 1721 VPN
LANCOM 1811
LANCOM 1811
Hi laboe
Du mußt stattdessen ein forwarding für die (interne!) Domain des Standorts A in der DNS-Weiterleitungstabelle (TCP/IP -> DNS -> Weiterleitungen) eintragen. Die Domain muß hier mit führendem "*." angegeben werden, also z.B. *.standort-a.meinefirma
Für den Traffic zwischen Standort A und Standort B selbst brauchst du somit auch weder eine getaggte Route noch eine taggende Firewallregel. Hier reicht einfach eine normale Route aus, die als Ziel die VPN-Verbindung hat.
Daher dürften auch deine beiden anderen Probleme rühren...
Gruß
Backslash
Dann wird auch die DynDns-Anfrage zum DNS-Server in Standort A geschickt. Die soll doch aber weiterhin ins Internet!Ein hinzufügen des DNS Servers von Standort A führte dazu, dass eine DNS Auflösung nicht mehr funktioniert (DynDns schlägt fehlt.)
Du mußt stattdessen ein forwarding für die (interne!) Domain des Standorts A in der DNS-Weiterleitungstabelle (TCP/IP -> DNS -> Weiterleitungen) eintragen. Die Domain muß hier mit führendem "*." angegeben werden, also z.B. *.standort-a.meinefirma
soweit, so gutFür die Verbindung über den SDSL habe ich am Standort A ein Routing TAG=2 vergeben, welches im IP-Router als auch im VPN Verbindungliste vergeben ist.
Wie willst du denn das machen? in der Firewall kannst du keine FQDNs angeben - brauchst du ja auch nicht, da ja durch die Angabe der Routing-Tags an der VPN-Verbindung schon vorgegeben wird, welcher Kanal verwendet wird.Die Routing Regel sagt alles was zum Standort-B.DynDNS.org geht soll über die Route mit Tag=2.
Für den Traffic zwischen Standort A und Standort B selbst brauchst du somit auch weder eine getaggte Route noch eine taggende Firewallregel. Hier reicht einfach eine normale Route aus, die als Ziel die VPN-Verbindung hat.
Daher dürften auch deine beiden anderen Probleme rühren...
Gruß
Backslash
Thx Backslash. Die Lösung mit der DNS Weiterleitung hat mir geholfen. Ich kann immerhin einen Rechner von Standort B erreichen. Ich habe auch alle Regeln die das Routing zwsichen den Netzen a und B gelöscht und nur das Tag für die VPN Verbindungliste übrig gelassen.
Kann man auch irgendwie DNS Einträge von Standort B auf den Server Standort A übertragen. Momentan hab ich nur den DNS Eintrag von Rechner nb01 für das 192.168.111.0 Netz. Ist es möglich das man nach Vergabe der neuen Adresse vom 1811 am Standort B die neue IP an den Server am Standort A weiterreicht ?
Kann man auch irgendwie DNS Einträge von Standort B auf den Server Standort A übertragen. Momentan hab ich nur den DNS Eintrag von Rechner nb01 für das 192.168.111.0 Netz. Ist es möglich das man nach Vergabe der neuen Adresse vom 1811 am Standort B die neue IP an den Server am Standort A weiterreicht ?
LANCOM 1721 VPN
LANCOM 1811
LANCOM 1811
Hi laboe
Gruß
Backslash
Das nicht, aber du kannst ja in Standort A entsprechend eine Weiterleitung für die Domain des Standort B einrichten...Kann man auch irgendwie DNS Einträge von Standort B auf den Server Standort A übertragen.
nein, die DNS-Server im LANCOM synchronisieren sich nicht. Du kannst das nur mit der oben beschriebenen Weiterleitung lösenIst es möglich das man nach Vergabe der neuen Adresse vom 1811 am Standort B die neue IP an den Server am Standort A weiterreicht ?
Gruß
Backslash
Hi Backslash,
Danke für den Tipp. Auch wenn die DSN-Weiterleitung nicht funktioniert, würde ich gern die Rechner von Standort B in der Netzwerkumgebung sehen. Leider sehe ich sie nur nachdem ich sie direkt per UNC(IP) anspreche.
Per Name geht z.z. nicht das Sie ja den gleichen FQN haben wie an Standort A.
Um die Weiterleitung der Domain von A nach B einzutragen, muss ich doch im LANCOM unter TCp/IP->DNS->Eigene Domain einen Domainnamen definieren der nicht "intern" ist oder ?
Gruß Laboe
Danke für den Tipp. Auch wenn die DSN-Weiterleitung nicht funktioniert, würde ich gern die Rechner von Standort B in der Netzwerkumgebung sehen. Leider sehe ich sie nur nachdem ich sie direkt per UNC(IP) anspreche.
Per Name geht z.z. nicht das Sie ja den gleichen FQN haben wie an Standort A.
Um die Weiterleitung der Domain von A nach B einzutragen, muss ich doch im LANCOM unter TCp/IP->DNS->Eigene Domain einen Domainnamen definieren der nicht "intern" ist oder ?
Gruß Laboe
LANCOM 1721 VPN
LANCOM 1811
LANCOM 1811
Hi laboe
Es liegt daran, daß die Mobliclients nicht in der Domäne sind...
genauer: du hast keinen Masterbrowser in Standort A für die Arbeitsgruppen in Standort B (und natürlich ungekehrt). Wenn die Clients in Standort B in die Domäne integriert wären, dann wäre der Domain-Controller der für sie zuständige Masterbrowser...
Ohne Domänenzugehörigkeit funktioniert das mit der Netzwerkumgebung nur, wenn du auf beiden Seiten je einen echten WINS hinstellst, die sich untereinander synchronisieren. Dadurch ist WINS dann Masterbrowser für die jeweils gegegenüberliegende Seite.
Gruß
Backslash
Das Thema ist hier im Forum schon mehrfach behandelt worden, daher eine kurze Zusammenfassung:wenn die DSN-Weiterleitung nicht funktioniert, würde ich gern die Rechner von Standort B in der Netzwerkumgebung sehen. Leider sehe ich sie nur nachdem ich sie direkt per UNC(IP) anspreche.
Es liegt daran, daß die Mobliclients nicht in der Domäne sind...
genauer: du hast keinen Masterbrowser in Standort A für die Arbeitsgruppen in Standort B (und natürlich ungekehrt). Wenn die Clients in Standort B in die Domäne integriert wären, dann wäre der Domain-Controller der für sie zuständige Masterbrowser...
Ohne Domänenzugehörigkeit funktioniert das mit der Netzwerkumgebung nur, wenn du auf beiden Seiten je einen echten WINS hinstellst, die sich untereinander synchronisieren. Dadurch ist WINS dann Masterbrowser für die jeweils gegegenüberliegende Seite.
Gruß
Backslash
Ich glaube es gibt ein kleines Missverständnis.
Alle Rechner am Standort B sind auch Mitglied der Domäne am Standort A.
So melden sich meine Kollegen wie gewohnt an. Die Rechner sind sowohl am Standort A als auch in B im Einsatz. Die VPN Verbindung steht doch 24/7 somit ist die Domänenanmeldung auch möglich.
Sollte ich auf dem Windows Clients nur den WINS Server (AD Server am Standort A) nachträglich eintragen um das Problem zu lösen?
Alle Rechner am Standort B sind auch Mitglied der Domäne am Standort A.
So melden sich meine Kollegen wie gewohnt an. Die Rechner sind sowohl am Standort A als auch in B im Einsatz. Die VPN Verbindung steht doch 24/7 somit ist die Domänenanmeldung auch möglich.
Sollte ich auf dem Windows Clients nur den WINS Server (AD Server am Standort A) nachträglich eintragen um das Problem zu lösen?
LANCOM 1721 VPN
LANCOM 1811
LANCOM 1811
Hallo Backslash,
Sorry Backslash - lies dir doch einfach mal die Whitepapers zu dem Thema bei MS durch.
Gruß
Mario
Nein - ein Masterbrowser ist nur für eine Broadcast-Domain zuständig. Masterbrowser in unterschiedlichen Broadcast-Domains synchronisieren jedoch nicht ihre Browse-Table (damit man eine vollständige Netzwerkumgebung hat) - das machen nur Domain-Masterbrowser. Und die gibt es unter Windows nur auf Domaincontrollern.genauer: du hast keinen Masterbrowser in Standort A für die Arbeitsgruppen in Standort B (und natürlich ungekehrt). Wenn die Clients in Standort B in die Domäne integriert wären, dann wäre der Domain-Controller der für sie zuständige Masterbrowser...
Auch das ist falsch. WINS hat primär nichts mit Browsing zu tun. Ein WINS ist nicht zwangsläufig Masterbrowser und ein Masterbrowser muss nicht WINS installiert haben. Zudem reicht ein WINS über alle Broadcast-Domains aus. Die Domain-Masterbrowser befragen jedoch den WINS nach 1B Einträgen und basteln daraus eine komplette Browselist.Ohne Domänenzugehörigkeit funktioniert das mit der Netzwerkumgebung nur, wenn du auf beiden Seiten je einen echten WINS hinstellst, die sich untereinander synchronisieren. Dadurch ist WINS dann Masterbrowser für die jeweils gegegenüberliegende Seite.
Sorry Backslash - lies dir doch einfach mal die Whitepapers zu dem Thema bei MS durch.
Gruß
Mario
Hi eddia
Andersherum wird ein Schuh draus: Der (echte) WINS wird immer Masterbrowser für die ihm bekannten nicht lokalen Arbeitsgruppen, er gewinnt die Browserverhandlung immer, es sei denn es gibt einen Domain-Masterbrowser...
Genau das ist ja der Unterschied zwischen dem NBNS im LANCOM und einem echten WINS
Gruß
Backslash
Haarspalter...Nein - ein Masterbrowser ist nur für eine Broadcast-Domain zuständig. Masterbrowser in unterschiedlichen Broadcast-Domains synchronisieren jedoch nicht ihre Browse-Table (damit man eine vollständige Netzwerkumgebung hat) - das machen nur Domain-Masterbrowser. Und die gibt es unter Windows nur auf Domaincontrollern
Auch das ist falsch. WINS hat primär nichts mit Browsing zu tun. Ein WINS ist nicht zwangsläufig Masterbrowser und ein Masterbrowser muss nicht WINS installiert haben.
Andersherum wird ein Schuh draus: Der (echte) WINS wird immer Masterbrowser für die ihm bekannten nicht lokalen Arbeitsgruppen, er gewinnt die Browserverhandlung immer, es sei denn es gibt einen Domain-Masterbrowser...
Aber nur, wenn du eine reine Namenauflösung haben willst. Wenn du in einem Arbeitsgruppen-Netz die Netzwerkumgebung auch mit entfernten Hosts gefüllt haben willst, dann mußt du überall einen Masterbrowser für die entfernten Arbeitsgruppen haben - und genau diese Aufgabe übernimmt der (echte) WINS.Zudem reicht ein WINS über alle Broadcast-Domains aus.
Genau das ist ja der Unterschied zwischen dem NBNS im LANCOM und einem echten WINS
Wir reden hier von zwei Dingen. Für einen Domain-Masterbrowser reicht ein einziger NBNS (das könnte auch der NBNS im LANCOM sein!). Für Arbeitsgruppen brauchst du in jedem Standort einen Masterbrowser für die entfernten Standorte (die sind ja nicht in der selben Broadcast-Domain)Die Domain-Masterbrowser befragen jedoch den WINS nach 1B Einträgen und basteln daraus eine komplette Browselist.
Gruß
Backslash
Hallo Backslash,
Dein Fehler ist, WINS automatisch mit einem Masterbrwoser gleichzusetzen. Daraus entsteht auch deine falsche Auffassung, dass es für eine vollständige Netzwerkumgebung in jedem Netz eines WINS bedürfte.
Da das alles mit Lancoms nichts zu tun hat, höre ich an dieser Stelle auf und bitte dich, doch einfach mal folgendes genau durchzulesen (darum hatte ich dich bereits vor mehr als einem Jahr wegen einer ähnlichen Diskussion gebeten):
http://www.microsoft.com/germany/techne ... _appc.mspx
Gruß
Mario
WINS hat nichts mit der Aushandlung von Masterbrowsern zu tun! Das ist einfach nur ein Dienst. Die Aushandlungsstrategie für Browser geschieht nach ganz anderen Kriterien. Und ein Browser ist nie für nicht lokale Arbeitsgruppen zuständig - kann er gar nicht.Andersherum wird ein Schuh draus: Der (echte) WINS wird immer Masterbrowser für die ihm bekannten nicht lokalen Arbeitsgruppen, er gewinnt die Browserverhandlung immer, es sei denn es gibt einen Domain-Masterbrowser...
Dein Fehler ist, WINS automatisch mit einem Masterbrwoser gleichzusetzen. Daraus entsteht auch deine falsche Auffassung, dass es für eine vollständige Netzwerkumgebung in jedem Netz eines WINS bedürfte.
Da das alles mit Lancoms nichts zu tun hat, höre ich an dieser Stelle auf und bitte dich, doch einfach mal folgendes genau durchzulesen (darum hatte ich dich bereits vor mehr als einem Jahr wegen einer ähnlichen Diskussion gebeten):
http://www.microsoft.com/germany/techne ... _appc.mspx
Gruß
Mario
Hi eddia
OK, ich hab's mir jetzt duchrgelesen... Der einzige Unterschied zwischen meiner Aussage und dem Dokument ist der, daß ich bisher davon ausgegangen bin, daß entfertne Arbeitsgruppen auf der lokalen einen eigenen Masterbrowser brauchen und daß diese Aufgabe vom dem Server übernommen wird, auf dem auch der WINS läuft - was auch naheliegend ist, da es nunmal mit zwei WINS auch funktioniert.
Tatsächlich ist es halt so, daß nur ein "Forwarder" für Domain-Announces vorhanden sein muß, damit die Masterbrowser der lokalen Arbeitsgruppen mitbekommen, daß es noch entfernte Arbeitsgruppen gibt:
Und genau hier setzt dann wohl der lokale WINS für entfernte Arbeitsgruppen an..
Aber immerhin sehe ich nun doch noch einen Ansatzpunkt, um auch mit dem NetBIOS-Proxy des LANCOM die entfernte Seite sichtbar zu machen, ohne das Browser-Protokoll im LANCOM zu implementieren... (zumindest, wenn man auf beiden Seiten verschiedene Arbeitsgruppen verwendet, denn das Szenario C-8 ist auch weiterhin nur lösbar, wenn das LANCOM Masterbrowser für die verteilte Arbeitsgruppe wird)
Gruß
Backslash
OK, ich hab's mir jetzt duchrgelesen... Der einzige Unterschied zwischen meiner Aussage und dem Dokument ist der, daß ich bisher davon ausgegangen bin, daß entfertne Arbeitsgruppen auf der lokalen einen eigenen Masterbrowser brauchen und daß diese Aufgabe vom dem Server übernommen wird, auf dem auch der WINS läuft - was auch naheliegend ist, da es nunmal mit zwei WINS auch funktioniert.
Tatsächlich ist es halt so, daß nur ein "Forwarder" für Domain-Announces vorhanden sein muß, damit die Masterbrowser der lokalen Arbeitsgruppen mitbekommen, daß es noch entfernte Arbeitsgruppen gibt:
Aber ohne diesen Forwarder gibt es auch keine entfernten Arbeitsgruppen in der Netzwerkumgebung, denn von alleine kommen die Domain-Announces nicht in dein LAN - und ohne kann der Schritt 1 von Abb. C-6 nicht "aus dem Nichts heraus" stattfinden...Jeder Hauptsuchserver einer LAN-Gruppe sendet in regelmäßigen Abständen einen Broadcast mit einem Domänenankündigungs- oder einem Arbeitsgruppenankündigungspaket an den NetBIOS-Namen [01][02]__MSBROWSE__[01][02].
(...)
1. Der Suchclient stellt eine Verbindung zum lokalen Hauptsuchserver her und fordert den Namen des Hauptsuchservers der gewünschten LAN-Gruppe an.
(...)
In Abbildung C-6 ist der beschriebene Prozess dargestellt.
Und genau hier setzt dann wohl der lokale WINS für entfernte Arbeitsgruppen an..
Aber immerhin sehe ich nun doch noch einen Ansatzpunkt, um auch mit dem NetBIOS-Proxy des LANCOM die entfernte Seite sichtbar zu machen, ohne das Browser-Protokoll im LANCOM zu implementieren... (zumindest, wenn man auf beiden Seiten verschiedene Arbeitsgruppen verwendet, denn das Szenario C-8 ist auch weiterhin nur lösbar, wenn das LANCOM Masterbrowser für die verteilte Arbeitsgruppe wird)
Gruß
Backslash
Hi eddia,
es gibt nun tatsächlich eine Lösung für das Problem, nur funktioniert das nicht wirklich so, wie in dem Dokument beschrieben...
Ab der nächsten Firmware, sind nun auch entfernte Arbeitsgruppen in der Netzwerkumgebung sichtbar. Im Gegensatz zur Äußerung des Dokuments, funktioniert das sogar mit verteilten Arbeitsgruppen ( Szenario C-8 ) ohne, daß das LANCOM Masterbrowser wird...
Nur bei RAS-Einwahlen - sprich, wenn der einwählende kein LANCOM ist - funktioniert das leider nicht. Aber das ist ja bei Microsofts eigenen Produkten auch so, d.h. auch bei einer RAS-Einwahl auf einen Microsoft-Server sieht man die Netzwerkumgebung nur, wenn man sich bei einer Domäne anmeldet...
Gruß
Backslash
es gibt nun tatsächlich eine Lösung für das Problem, nur funktioniert das nicht wirklich so, wie in dem Dokument beschrieben...
Ab der nächsten Firmware, sind nun auch entfernte Arbeitsgruppen in der Netzwerkumgebung sichtbar. Im Gegensatz zur Äußerung des Dokuments, funktioniert das sogar mit verteilten Arbeitsgruppen ( Szenario C-8 ) ohne, daß das LANCOM Masterbrowser wird...
Nur bei RAS-Einwahlen - sprich, wenn der einwählende kein LANCOM ist - funktioniert das leider nicht. Aber das ist ja bei Microsofts eigenen Produkten auch so, d.h. auch bei einer RAS-Einwahl auf einen Microsoft-Server sieht man die Netzwerkumgebung nur, wenn man sich bei einer Domäne anmeldet...
Gruß
Backslash