Problem bei verbinden von zwei Standorten per VPN

[martins 11]

Eine Reverse-Lookupzone existiert gar nicht auf dem Memberserver (Niederlassung). Ich hatte ja zuvor (vorgestern) erst DNS installiert und anschließend DCPROMO durchgeführt. Nachdem die Replikation nicht funktionierte, habe ich aus dem DC wieder einen Memberserver gemacht. Und nun sitz ich hier! :)

 

... ich versuch mal kurz die MTU auf 1450 zu reduzieren!

[grizzly999 11]

Füge auf beiden Server mal den Reg-Key hier aus Methode 1 hinzu: Recommended TCP/IP settings for WAN links with a MTU size of less than 576

 

Reboot nicht vergessen.

 

Ich bin mir sicher, das Problem ist dann erledigt ;)

 

 

grizzly999

[LukasB 10]

Füge auf beiden Server mal den Reg-Key hier aus Methode 1 hinzu: Recommended TCP/IP settings for WAN links with a MTU size of less than 576)

 

Das packt aber das Problem nicht wirklich bei der Wurzel...

[grizzly999 11]

Das packt aber das Problem nicht wirklich bei der Wurzel...

 

Doch. Aus Erfahrung ;)

Problem sind die BlackHoles und deren mangelhafte Erkennung.

Ein Heruntersetzen der MTU ist ein Try-And-Error Spiel, das dann irgendwann funktioniert, und vielleicht plötzlich nicht mehr (wenn man z.B. über eine andere Leitung geschaltet wird, auf der zusätzlich irgendwo ein VPN dazwischen ist, und damit auf dem Segemnt die MTU Size wieder zu groß ist)

 

grizzly999

[martins 11]

Füge auf beiden Servern (...)

 

 

Auf beiden Servern? Aber eigentlich sind es doch drei! ;)

[LukasB 10]

Doch. Aus Erfahrung ;)

Problem sind die BlackHoles und deren mangelhafte Erkennung.

 

Ja, solche Blackholes sollte es aber in einem VPN das man End-To-End unter Kontrolle hat aber nie geben. Auch wenn der WAN-Link noch so schlecht ist und egal welche MTU dieser hat sollten gute VPN-Appliances auch Pakete mit einer Grösse von 1500 byte übertragen können.

[grizzly999 11]

Sorry :o

Am besten auf allen Server. Wir haben den Key bei uns sogar auf allen Rechnern installiert. Seitdem gibt es keine Probleme mehr in irgendeiner Art mit MTU-Sizes.

 

Und wir hatten in den vergangenen Jahren immer wieder Probleme 13565, 13508 und Co., bei uns und bei Kunden

Früher half mal der Patch KBichweißnichtmehrgenau, dann war's mit irgendeinem Update oder SP wieder rum damit.

Seit dem einspilen des Reg-Key ist Ruhe mit Replikationsproblemen oder RDP-Anmeldeproblemen.

 

grizzly999

–

Ja, solche Blackholes sollte es aber in einem VPN das man End-To-End unter Kontrolle hat aber nie geben. Auch wenn der WAN-Link noch so schlecht ist und egal welche MTU dieser hat sollten gute VPN-Appliances auch Pakete mit einer Grösse von 1500 byte übertragen können.

 

Im Prinzip "Ja", ABER ..... ;)

Wir hatten bei Kunden schon plötzlich auftretende Repliaktionsprobleme wegen MTU-Size bei einer 2MBIT-Standleitung zwischen zwei Standorten. Keine Ahnung, was die Telekom manchmal hinten dran verschaltet :rolleyes:

 

grizzly999

[martins 11]

Das Patch ist mir bei meiner Recherche auch schon begegnet... gab es aber für 64-bittige Systeme nur als Englisch- und Japan-Version.

[LukasB 10]

Im Prinzip "Ja", ABER ..... ;)

 

Ist es nicht immer so? ;)

 

Worauf ich hinaus will: Dein Weg ist sicher leichter zu implementieren als irgendwelche SOHO-Router durch richtiges Equipment zu ersetzen oder in einer grossen Firma die Netzwerker dazu zu kriegen ihren Sche*ss zu flicken. Also auf jeden Fall ein guter Ratschlag.

 

Ich sehe die Gefahr halt da wenn man das auf einer OS Ebene löst das man dann nächstens bei Appliances die ein anderes OS haben auf die Schnauze fällt.

 

Gruss,

 

Lukas

[grizzly999 11]

Das Patch ist mir bei meiner Recherche auch schon begegnet... gab es aber für 64-bittige Systeme nur als Englisch- und Japan-Version

Das war der hier: Installing security update MS05-019 or Windows Server 2003 Service Pack 1 may cause network connectivity between clients and servers to fail (der wird auch in dem von mir zitierten Artikel erwähnt).

Nach Installtion von SP1 ist bei vielen die Replikation über VPN Strecken auf die Schn**ze gefallen. Der Patch half eine Zeit lang.

 

Wie gesagt, irgendwann fing der Ärger wieder an :mad:

 

 

grizzly999

–

–

Ist es nicht immer so? ;)

 

Worauf ich hinaus will: Dein Weg ist sicher leichter zu implementieren als irgendwelche SOHO-Router durch richtiges Equipment zu ersetzen oder in einer grossen Firma die Netzwerker dazu zu kriegen ihren Sche*ss zu flicken. Also auf jeden Fall ein guter Ratschlag.

 

Ich sehe die Gefahr halt da wenn man das auf einer OS Ebene löst das man dann nächstens bei Appliances die ein anderes OS haben auf die Schnauze fällt.

 

Gruss,

 

Lukas

 

Ja, aber ist ja in dem Fall auch ein OS-Problem. Daher bin ich der Meinung, man sollte es auch dort beheben.

Die MTU Size manchmal bis zum Schwindligwerden heruntersetzen (bei einem Kunden waren wir erst bei rd. 800 Bytes stabil) kann ja auch nicht die Lösung sein.

[martins 11]

au backe... jetzt hab ich mich echt vertippt. Statt "EnablePMTUBHDetect" hab ich "EnablePMTUDiscovery" angelegt. Glücklicherweise lebten die Kisten noch nach dem reboot. Verdammt.

[LukasB 10]

au backe... jetzt hab ich mich echt vertippt. Statt "EnablePMTUBHDetect" hab ich "EnablePMTUDiscovery" angelegt. Glücklicherweise lebten die Kisten noch nach dem reboot. Verdammt.

 

Ansonsten kannst du während der Fahrzeit deinen Chef verfluchen das er keinen iLO/RSA/DRAC whatever gekauft hat.

 

(Techniker machen bekanntlich nie Fehler ;) )

[martins 11]

scheint den Kisten nichts ausgemacht zu haben! ;)

 

... aber nslookup mault noch immer "non-existent domain" :(

 

Das kann doch nicht sein. By the way... das Ereignisprotoll auf dem Memberserver spuckt mir 'nen 1054 aus:

 

___________

Ereignistyp: Fehler

Ereignisquelle: Userenv

Ereigniskategorie: Keine

Ereigniskennung: 1054

Datum: 30.05.2008

Zeit: 23:12:47

Benutzer: NT-AUTORITÄT\SYSTEM

Computer: SRV01-DA

Beschreibung:

Der Domänencontrollername für das Computernetzwerk konnte nicht ermittelt werden. (Unerwarteter Netzwerkfehler. ). Die Verarbeitung der Gruppenrichtlinie wurde abgebrochen.

_________

–

(Techniker machen bekanntlich nie Fehler ;) )

 

Ich hab die Dinger ja angeschafft... sollten auch ursprünglich nur für ein Videokonferenz-System sein. Naja, da hab ich mir gedacht, dass man da prima die Niederlassung noch mit anbinden könnte. 2 Mbit SDSL müssen ja auch genutzt werden.

 

Naja, wenn's klappen tät! :D

–

... und mein ping 192.168.8.200 -l 1500 zeigt noch das exakt gleiche Verhalten wie zuvor. Bis 1472 alles iO, darüber hinaus gibt's eine Zeitüberschreitung. :mad:

[grizzly999 11]

... und mein ping 192.168.8.200 -l 1500 zeigt noch das exakt gleiche Verhalten wie zuvor. Bis 1472 alles iO, darüber hinaus gibt's eine Zeitüberschreitung. :mad:

Ist doch aboslut korrekt! 1472 +28 (ping Overhead) = 1500

:)

 

 

grizzly999

[LukasB 10]

Ist doch aboslut korrekt! 1472 +28 (ping Overhead) = 1500

 

Sehe ich anders: (Erste Seite ADSL, VPN Link, andere Seite SDSL)

 

C:\Users\z-l.beeler>ping -l 2000 10.34.0.11

Pinging 10.34.0.11 with 2000 bytes of data:
Reply from 10.34.0.11: bytes=2000 time=39ms TTL=126
Reply from 10.34.0.11: bytes=2000 time=47ms TTL=126
Reply from 10.34.0.11: bytes=2000 time=43ms TTL=126

Ping statistics for 10.34.0.11:
   Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 39ms, Maximum = 47ms, Average = 43ms
Control-C
^C