Wie vermeide ich Verzögerungen im Zusammenhang mit IPv6-AAAA-Datensätzen?

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.

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.

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 beginnt 2002:. Es würde ungefähr so ​​aussehen.

C:\> ipconfig
Tunnel adapter 6TO4 Adapter:
IPv6 Address. . . . . . . . . . . : 2002:1111:2222::1111:2222

• Wenn Ihre Endpunkte mit Active Directory verbunden sind, können Sie mithilfe von Gruppenrichtlinien Übergangsprotokolle wie 6to4 und Teredo deaktivieren. Dies ist in KB929852 gut dokumentiert . (Dies auf Ihre Clients oder Server anzuwenden, würde ausreichen, aber wenn Sie diesen Schritt ausführen, ist es wahrscheinlich sinnvoll, ihn überall zu deaktivieren, sowohl auf Clients als auch auf Servern.)
• Wenn Sie nur wenige Hosts verwalten, können Sie 6to4 von Fall zu Fall deaktivieren. Dies ist viel besser als das vollständige Deaktivieren von IPv6.netsh int ipv6 6to4 set state disabled
• Verwenden Sie ein anderes Client-Betriebssystem. In Mac OS X ist beispielsweise 6to4 standardmäßig nicht aktiviert.

Es 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.

• Sie können Clients und / oder Server hinter eine NAT-Firewall verschieben und die RFC1918-Adressierung verwenden. In einigen Fällen werden jedoch öffentlich routbare Adressen bevorzugt. Das Ändern der Adressierung eines gesamten Netzwerks kann ebenfalls eine unrealistische Entscheidung sein.

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 .

• Richten Sie Ihre Firewall so ein, dass das IP-Protokoll 41 (mit TCP-Resets) lautstark abgelehnt wird, wenn es von Hosts in Ihrem Netzwerk gesendet wird. Dies sollte zu einem "schnell fehlgeschlagenen" Verhalten führen, das sinnvoller ist als nicht deterministische Verbindungsverzögerungen. Es wurde gezeigt, dass dies in begrenzten Testumgebungen funktioniert .
• Bitten Sie Ihren ISP oder First-Hop-Transitanbieter, ein funktionierendes 6to4-Relais einzurichten. Wenn dies richtig gemacht wird, führt dies zu der besten Erfahrung für Endbenutzer. Jeder Endbenutzer mit einer öffentlich routbaren IPv4-Adresse kann am IPv6-Internet teilnehmen.

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.

• Sie können dynamische DNS-Updates deaktivieren. Wenn Sie dann keine AAAA-Ressourceneinträge in die Zonendatei einfügen, werden diese niemals bereitgestellt. Dynamisches DNS ist jedoch häufig für interne DNS-Server wünschenswert. (Wenn Sie dies tun, stellen Sie sicher, dass Sie auch alle AAAA-Einträge löschen, die möglicherweise bereits vorhanden sind.)
• Richten Sie den DNS-Server so ein, dass keine Antworten für AAAA-Ressourceneinträge bereitgestellt werden. Tun Sie dies jedoch nicht, da es Ihnen wirklich Probleme bereiten wird, wenn Sie mit der Implementierung von IPv6 beginnen möchten. (Kennt jemand eine Free / Open Source DNS Firewall?)

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.

• Versuchen Sie es mit einem anderen Client. Vielleicht hast du Glück.

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.

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.

netsh int ipv6 isatap set state disabled
netsh int ipv6 6to4 set state disabled
netsh interface teredo set state disable

netsh interface ipv6 delete prefixpolicy ::1/128
netsh interface ipv6 delete prefixpolicy ::/0
netsh interface ipv6 delete prefixpolicy 2002::/16
netsh interface ipv6 delete prefixpolicy ::/96
netsh interface ipv6 delete prefixpolicy ::ffff:0:0/96
netsh interface ipv6 delete prefixpolicy 2001::/32

netsh interface ipv6 add prefixpolicy ::1/128 50 0
netsh interface ipv6 add prefixpolicy ::ffff:0:0/96 40 1
netsh interface ipv6 add prefixpolicy ::/0 30 2
netsh interface ipv6 add prefixpolicy 2002::/16 20 3
netsh interface ipv6 add prefixpolicy ::/96 10 4
netsh interface ipv6 add prefixpolicy 2001::/32 5 5

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.