Unsere Windows-Server registrieren IPv6- AAAAEinträge bei unseren Windows-DNS-Servern. In unserem Netzwerk ist das IPv6-Routing jedoch nicht aktiviert, sodass dies häufig zu Blockierverhalten führt.
Microsoft RDP ist der schlimmste Täter. Wenn Sie eine Verbindung zu einem Server mit einem AAAADNS-Eintrag herstellen, versucht der Remotedesktop-Client zuerst IPv6 und greift erst nach Ablauf der Verbindungszeit auf IPv4 zurück. Hauptbenutzer können dies umgehen, indem sie sich direkt mit der IP-Adresse verbinden. Das Auflösen der IPv4-Adresse mit ping -4 hostname.foofunktioniert immer sofort.
Was kann ich tun, um diese Verzögerung zu vermeiden?
- IPv6 auf Client deaktivieren?
- Nein, laut Microsoft ist IPv6 ein obligatorischer Bestandteil des Windows-Betriebssystems.
- Zu viele Clients, um sicherzustellen, dass dies überall einheitlich festgelegt wird.
- Wird später weitere Probleme verursachen, wenn wir IPv6 endlich implementieren.
- IPv6 auf dem Server deaktivieren?
- Nein, laut Microsoft ist IPv6 ein obligatorischer Bestandteil des Windows-Betriebssystems.
- Erfordert einen unbequemen Registrierungs-Hack , um den gesamten IPv6-Stack zu deaktivieren.
- Es ist unpraktisch sicherzustellen, dass dies auf allen Servern richtig eingestellt ist.
- Wird später weitere Probleme verursachen, wenn wir IPv6 endlich implementieren.
- IPv6-Einträge auf dem benutzerfreundlichen DNS-Rekorder maskieren?
- Nein, wir verwenden NLNet Unbound und das wird nicht unterstützt .
- Registrierung von IPv6-AAAA-Einträgen auf dem Microsoft DNS-Server verhindern?
- Ich denke nicht, dass das überhaupt möglich ist.
An dieser Stelle denke ich darüber nach, ein Skript zu schreiben, das alle AAAA-Einträge aus unseren DNS-Zonen löscht. Bitte helfen Sie mir, einen besseren Weg zu finden.
UPDATE: DNS-Auflösung ist nicht das Problem. Wie @joeqwerty in seiner Antwort hervorhebt, werden die DNS-Einträge sofort zurückgegeben. Beide Aund AAAADatensätze sind sofort verfügbar. Das Problem ist, dass einige Clients ( mstsc.exe) vorzugsweise versuchen, eine Verbindung über IPv6 herzustellen, und es eine Weile dauert, bis sie auf IPv4 zurückgreifen.
Dies scheint ein Routing-Problem zu sein. Der pingBefehl erzeugt eine Fehlermeldung "Allgemeiner Fehler", da die Zieladresse nicht routingfähig ist.
C:\Windows\system32>ping myhost.mydomain
Pinging myhost.mydomain [2002:1234:1234::1234:1234] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for 2002:1234:1234::1234:1234:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Ich kann keine Paketerfassung für dieses Verhalten erhalten. Wenn Sie diesen (fehlgeschlagenen) Ping-Befehl ausführen, werden in Microsoft Network Monitor keine Pakete erzeugt. In ähnlicher Weise erzeugt der Versuch, eine Verbindung mit mstsc.exeeinem Host mit einem AAAADatensatz herzustellen , keinen Datenverkehr, bis ein Fallback auf IPv4 durchgeführt wird.
UPDATE: Unsere Hosts verwenden alle öffentlich routbare IPv4-Adressen. Ich denke, dieses Problem könnte auf eine kaputte 6to4-Konfiguration zurückzuführen sein. 6to4 verhält sich auf Hosts mit öffentlichen IP-Adressen anders als auf RFC1918-Adressen.
UPDATE: In meinem Netzwerk gibt es definitiv etwas faul mit 6to4. Wenn ich 6to4 auf dem Windows-Client deaktiviere, werden die Verbindungen sofort aufgelöst.
netsh int ipv6 6to4 set state disabled
Aber wie @joeqwerty sagt, maskiert dies nur das Problem. Ich versuche immer noch herauszufinden, warum die IPv6-Kommunikation in unserem Netzwerk überhaupt nicht funktioniert.
Antworten:
Diese Frage ist ziemlich interessant und ich muss zugeben, dass ich dieses Verhalten noch nie gesehen habe. Beim Herumspielen, um es besser zu verstehen, habe ich einen Ausschnitt aus nslookup genommen, der einen meiner W2K8R2-RDS-Server von einem anderen W2K8R2-Server abfragt, und ich habe auch einen Ausschnitt einer RDP-Sitzung auf demselben RDS-Server vom selben Testserver erfasst . Nslookup zeigte keine Verzögerung bei der Rückgabe des IPv6-Datensatzes und der nslookup zeigte, dass mein Testserver nach dem IPv4-Datensatz abfragte, bevor er nach dem IPv6-Datensatz abfragte. Das Zeitdelta in der Erfassung zeigt in keiner der Abfragen eine nennenswerte Verzögerung (die ich feststellen kann).
BEARBEITEN
Jetzt bist du bei etwas.
Stellen Sie sicher, dass Sie Datenverkehr für den Microsoft 6To4-Adapter erfassen, da sonst IPv6 nicht angezeigt wird:
Hier ist das nslookup-Ergebnis für meinen RDS-Server. Notieren Sie sich die IPv6-Adressen:
Hier ist ein Ausschnitt meiner Aufnahme:
Und zum Schluss hier ein Ausschnitt aus netstat, der die Verbindung zeigt:
Wie Sie bestätigt haben, ist die DNS-Auflösung also nicht das Problem. Das Problem ist, dass die RDP-Verbindung IPv6 gegenüber IPv4 bevorzugt (dies ist die Standardeinstellung für Windows - Windows bevorzugt IPv6 gegenüber IPv4). Da IPv6 nicht ordnungsgemäß funktioniert, führt dies (wie angegeben) zu einer Verzögerung beim Zurücksetzen von IPv6 auf IPv4. Sie könnten dies beheben, indem Sie die Clients so konfigurieren, dass IPv4 IPv6 vorgezogen wird, aber ich denke, das würde das Problem lediglich maskieren. Die bessere Lösung wäre, herauszufinden, warum IPv6 nicht funktioniert, und das zu beheben. Ich weiß nicht genug über IPv6, um zu helfen, aber ich vermute, dass die von DNS zurückgegebenen IPv6-Einträge "lokale" Adressen sind, die nur in dem Subnetz gültig sind, in dem sich die RDS-Hosts befinden, und da sich die Clients in einem anderen Subnetz befinden, können sie ' t diese IPv6-Adressen nicht erreichen.
quelle
Die IPv6-Übergangstechnologie namens 6to4 ist berüchtigt dafür, Probleme wie dieses zu verursachen. Es gibt mehrere Faktoren bei der Arbeit. Individuell sind sie harmlos, aber der kombinierte Effekt ist, dass Endbenutzer Verbindungsverzögerungen erfahren können.
Nachfolgend finden Sie eine Liste der Faktoren und Überlegungen zu ihrer Minderung.
Windows aktiviert standardmäßig 6to4
Wenn auf Ihren Hosts eine neuere Version von Windows (Vista oder höher) ausgeführt wird, aktiviert Windows opportunistisch das 6to4-Tunneling, wenn eine öffentlich routbare IPv4-Adresse verfügbar ist. Dies gilt sowohl für Server als auch für Clients.
Um herauszufinden, ob ein System 6to4 verwendet, führen Sie es aus
ipconfigund suchen Sie nach einer IPv6-Adresse, die mit dem Präfix 6to4 beginnt2002:. Es würde ungefähr so aussehen.netsh int ipv6 6to4 set state disabledEs werden öffentlich routbare IPv4-Adressen verwendet
6to4 funktioniert nur auf Hosts mit öffentlich routbaren IPv4-Adressen, sodass dieses Problem niemals Hosts hinter einer NAT-Firewall betrifft.
6to4 funktioniert im Netzwerk nicht richtig
Es ist äußerst schwierig, 6to4 im Anycast-Modus zu beheben. Es ist so problematisch, dass es eine formelle Anfrage an die IETF gab, dass 6to4 als historisch eingestuft werden sollte . Nach Meinung dieses Autors ist 6to4 veraltet.
Kurz gesagt, 6to4 kapselt IPv6-Pakete unter Verwendung eines Protokolls namens 6in4 (IP-Protokoll = 41) in IPv4-Pakete. Die IPv4-Pakete werden an die Anycast-Adresse adressiert,
192.88.99.1in der Hoffnung, dass sie irgendwo im Internet zu einem funktionierenden 6to4-Relay gelangen. Wenn Sie Glück haben, kann es sogar geografisch in der Nähe sein.In der Praxis sind einige 6to4-Relais falsch eingerichtet, und in vielen Netzwerken kann nicht einmal 6in4-Verkehr die Firewall passieren. In der Regel geschieht dies, wenn eine Firewall den gesamten ausgehenden Datenverkehr zulässt, jedoch nicht ausdrücklich zulässt, dass IP-Protokoll 41-Pakete durch die Firewall zurückkehren. (Beachten Sie auch den entsprechenden RFC für die Fehlerbehebung.) Dieser Fehler ("eingehendes Schwarzes Loch") und viele andere sind in RFC 6343 beschrieben .
Dynamische DNS-Registrierung
In einer typischen Active Directory-Umgebung kann jeder Computer seine eigenen Adressen beim DNS-Server registrieren. Wenn ein Host über mehrere Hosts verfügt, registriert er alle seine Adressen, auch aus einem 6to4-Tunnel.
Die meisten Internetdienste verwenden kein dynamisches DNS. Daher ist dieses Problem normalerweise auf Unternehmensstandorte beschränkt, auf denen die Clients und Server alle "intern" im selben Netzwerk sind.
Die Clientanwendung schlägt nicht ordnungsgemäß fehl
Der RDP-Client von Microsoft ist ein Beispiel für eine Clientanwendung, die IPv6-Routingprobleme nicht ordnungsgemäß behandelt. Die meisten Webbrowser können IPv6-Edge-Fälle wie diesen besser verarbeiten, sodass sie dieses Verhalten nicht zeigen.
quelle
Mir ist klar, dass dies für diese Situation nicht sehr hilfreich ist, aber für Implementierer, die sich einem ähnlichen Dilemma gegenübersehen, gibt es eine Implementierungstechnik namens "Happy Eyeballs" (RFC 6555), die eine Technik für die gleichzeitige Verbindung mit ipv4 und ipv6 und die Auswahl der zuerst verbundenen Verbindung angibt.
quelle
Hier war meine Lösung. Standardmäßig gibt Windows IPv6-Routen eine höhere Priorität als IPv4-Routen. Wenn Sie die IPv6-Präfixrichtlinie bearbeiten, können Sie dieses Verhalten so ändern, dass IPv4 IPv6 vorgezogen wird.
Um sicherzustellen, dass alle Systeme in meinem Netzwerk auf dieselbe Weise eingerichtet sind, habe ich die folgenden Befehle in ein .bat-Skript eingefügt, das während der Softwareinstallation nach dem Erstellen oder Überholen einer Maschine ausgeführt wird.
Um zu erklären, was dies bewirkt:
Die ersten drei Leitungen deaktivieren die integrierten Tunnelschnittstellen, da sie für die meisten Netzwerke redundant sind. Möglicherweise möchten Sie diese drei Leitungen nicht verwenden, wenn Sie Ihren Computern keine eigenen IPv6-Adressen geben. In meinem Fall habe ich einen DHCPv6-Server und eine zugehörige Infrastruktur, die IPv6 für die Tunnelkonnektivität zuweist
Der zweite Befehlsblock löscht alle vorhandenen IPv6-Routing-Präfixrichtlinien.
Der dritte Block erstellt dann die IPv6-Präfixrichtlinien neu, verwendet jedoch andere Prioritäten. Auf diese Weise wird das IPv4 entsprechende Präfix gegenüber IPv6 bevorzugt, und der Computer möchte dann IPv4 verwenden, es sei denn, die Anwendung gibt die Verwendung von IPv6 an.
Diese Lösung behält die funktionale Dual-Stack-Fähigkeit bei, aber die Bevorzugung der Verwendung von IPv4 bedeutet, dass Sites mit unvollständiger, unzuverlässiger oder leistungsschwacher IPv6-Funktion die Verwendung vermeiden, es sei denn, dies wird von einem Programm auf dem System angewiesen.
Ich bin der Meinung, dass die Verwendung von IPv6 durch Betriebssysteme gegenüber IPv4 die Akzeptanz tatsächlich behindert. Während der Übergangszeit wird es Zeiten geben, in denen ein Host glaubt, IPv6-Konnektivität zu haben, aber keine voll funktionsfähige Verbindung hat, was zu Softwarefehlern und großen Verzögerungen führt. Viele Personen, die ich kenne, haben IPv6 an ihrem Router vollständig deaktiviert, um ISPs zu umgehen, die IPv6 zunächst fehlerhaft bereitstellen, bevor sie die vollständige Konnektivität herstellen. Diese Personen werden einfach vergessen, es erneut zu aktivieren, ohne IPv6 zu verwenden, bis sie ihren Router erneut konfigurieren.
quelle