In unserem kleinen Unternehmen haben wir einen Server mit Windows Server 2008, der als Active Domain Directory, DNS und DHCP fungiert, und einen SonicWall-Router, auf dem unsere VPN-Dienste laufen, mit SonicWall NetExtender als Client-Software. Unser Problem ist, dass jemand, der über das VPN verbunden ist, keine Kommunikation mit irgendetwas in unserem lokalen Netzwerk initiieren kann.
SonicWall zeigt an, dass der Benutzer verbunden ist. Der DHCP auf unserem Windows Server 08-Rechner sagt mir, dass er genau die Adresse erhalten hat, die sein NetExtender-Client ihm zuweist. Ich kann den Benutzer sowohl von meinem Computer als auch von dem Server aus anpingen, auf den er zugreifen möchte, aber seine Pings laufen ab. Ich kann auch keinen Remotedesktopzugriff auf seinen Rechner herstellen.
Meines Wissens wurden weder am Server noch an der Firewall Änderungen vorgenommen. Gestern, vor einem flächendeckenden Internetausfall, sagte er, er könne sich problemlos verbinden und auf die Dateien auf unserem Server zugreifen.
Was in aller Welt ist los?
Antwort1
Ich habe die Antwort gefunden. Der für die VPN-Dienste ausgewählte IP-Bereich (190-199) lag vollständig im Bereich des DHCP-Bereichs von Server 08 (.150-.255). Um das Problem zu beheben, habe ich den VPN-Bereich auf 70-89 eingestellt, außerhalb des DHCP-Bereichs. Ich denke, die Ursache dafür ist, dass wir Geräte haben, die bei 190 und 191 geleast sind, und als ich versuchte, ihn anzupingen, habe ich tatsächlich diese Geräte angepingt. Er hatte gesagt, dass es vorher einwandfrei funktioniert hatte, und das lag daran, dass er in dem Screenshot, den er mir von der Funktion geschickt hatte, 195 erhalten hatte, eine nicht geleaste Adresse auf dem DHCP. In der Regel handelt es sich nicht unbedingt um einen VPN-DHCP-Konflikt, sondern um einen individuellen IP-Konflikt, der gelöst wird, indem die Ziel-IPs des VPN außerhalb des Bereichs der IPs eingestellt werden, die möglicherweise zufällig an andere Maschinen geleast werden.
Ich hätte wohl eher darauf achten sollen, ob die für die geleaste IP des DHCP aufgeführte MAC-Adresse mit seiner Netzwerkkarte übereinstimmt. Was mich darauf aufmerksam machte, war, dass die Lease-Ablaufzeit für 191, mit der er verbunden war, als wir am Telefon die Fehlerbehebung durchführten, auf morgen, den 24.05.13, eingestellt war, während bei den anderen der 30. oder später war.