Jak uniknąć opóźnień związanych z rekordami AAAA IPv6?

Nasze serwery Windows rejestrują AAAArekordy IPv6 na naszych serwerach DNS systemu Windows. Jednak w naszej sieci nie włączono routingu IPv6, więc często powoduje to zatrzymanie.

Microsoft RDP jest najgorszym przestępcą. Podczas łączenia się z serwerem, który ma AAAArekord w DNS, klient pulpitu zdalnego spróbuje najpierw IPv6 i nie spadnie do IPv4, dopóki połączenie się nie skończy. Zaawansowani użytkownicy mogą obejść ten problem, łącząc się bezpośrednio z adresem IP. Rozwiązanie adresu IPv4 z ping -4 hostname.foozawsze działa natychmiast.

Co mogę zrobić, aby uniknąć tego opóźnienia?

• Wyłączyć IPv6 na kliencie?
  • Nie, Microsoft twierdzi, że IPv6 jest obowiązkową częścią systemu operacyjnego Windows.
  • Zbyt wielu klientów, aby upewnić się, że jest to ustawione wszędzie konsekwentnie.
  • Powoduje więcej problemów później, kiedy w końcu zaimplementujemy IPv6.
• Wyłączyć IPv6 na serwerze?
  • Nie, Microsoft twierdzi, że IPv6 jest obowiązkową częścią systemu operacyjnego Windows.
  • Wymaga niewygodnego włamania do rejestru, aby wyłączyć cały stos IPv6.
  • Zapewnienie prawidłowego ustawienia na wszystkich serwerach jest niewygodne.
  • Powoduje więcej problemów później, kiedy w końcu zaimplementujemy IPv6.
• Zamaskować rekordy IPv6 w rekursorze DNS obsługującym użytkownika?
  • Nie, używamy NLNet Unbound i nie obsługuje tego .
• Zapobiegać rejestracji rekordów AAAA IPv6 na serwerze Microsoft DNS?
  • Nie sądzę, żeby to w ogóle możliwe.

W tym momencie rozważam napisanie skryptu, który usuwa wszystkie rekordy AAAA z naszych stref DNS. Pomóż mi znaleźć lepszy sposób.

AKTUALIZACJA: Rozdzielczość DNS nie stanowi problemu. Jak wskazuje @joeqwerty w swojej odpowiedzi, rekordy DNS są zwracane natychmiast. Zarówno rekordy, jak Ai AAAArekordy są natychmiast dostępne. Problem polega na tym, że niektórzy klienci ( mstsc.exe) preferencyjnie podejmą próbę nawiązania połączenia przez IPv6, a powrót do IPv4 zajmuje trochę czasu.

Wygląda to na problem z routingiem. pingPolecenie tworzy „Błąd ogólny” komunikat o błędzie, ponieważ adres docelowy jest unroutable.

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),

Nie mogę uzyskać przechwytywania pakietów tego zachowania. Uruchomienie tego (nieudanego) polecenia ping nie powoduje wygenerowania żadnych pakietów w Microsoft Network Monitor. Podobnie próba połączenia z mstsc.exehostem z AAAArekordem nie generuje ruchu, dopóki nie nastąpi powrót do IPv4.

AKTUALIZACJA: Wszyscy nasi gospodarze używają adresów IPv4 z routingiem publicznym. Myślę, że ten problem może sprowadzić się do zepsutej konfiguracji 6to4. 6to4 zachowuje się inaczej na hostach z publicznymi adresami IP w porównaniu z adresami RFC1918.

AKTUALIZACJA: W mojej sieci jest zdecydowanie coś podejrzanego z 6to4. Kiedy wyłączam 6to4 na kliencie Windows, połączenia są rozwiązywane natychmiast.

netsh int ipv6 6to4 set state disabled

Ale jak mówi @joeqwerty, to tylko maskuje problem. Wciąż próbuję dowiedzieć się, dlaczego komunikacja IPv6 w naszej sieci całkowicie nie działa.

To pytanie jest dość interesujące i muszę przyznać, że nigdy nie widziałem takiego zachowania. Próbując zrozumieć to lepiej, wziąłem fragment zapytania nslookup dla jednego z moich serwerów RDS W2K8R2 z innego serwera W2K8R2, a także przechwyciłem fragment sesji RDP na tym samym serwerze RDS z tego samego serwera testowego . Nslookup nie wykazał opóźnienia w zwrocie rekordu IPv6, a nslookup pokazał, że mój serwer testowy pyta o rekord IPv4 przed zapytaniem o rekord IPv6. Delta czasu w przechwytywaniu nie wykazuje znaczącego opóźnienia (które mogę ustalić) w żadnym zapytaniu.

EDYTOWAĆ

Teraz jesteś na czymś.

Upewnij się, że przechwytujesz ruch dla adaptera Microsoft 6To4, w przeciwnym razie nie zobaczysz IPv6:

Oto wynik nslookup dla mojego serwera RDS. Zanotuj adresy IPv6:

Oto fragment mojego przechwytywania:

I na koniec, oto fragment z netstat pokazujący połączenie:

Tak wyraźnie, jak potwierdziłeś, rozwiązywanie DNS nie stanowi problemu. Problem polega na tym, że połączenie RDP woli IPv6 niż IPv4 (co jest domyślne dla Windows - Windows preferuje IPv6 zamiast IPv4), a ponieważ IPv6 nie działa poprawnie, powoduje opóźnienie (jak już wspomniano) podczas powrotu z IPv6 do IPv4. Można to naprawić, konfigurując klientów tak, aby woleli IPv4 niż IPv6, ale myślę, że to tylko maskowałoby problem. Lepszym rozwiązaniem byłoby dowiedzieć się, dlaczego IPv6 nie działa i to naprawić. Nie wiem wystarczająco dużo o IPv6, aby pomóc, ale zgaduję, że rekordy IPv6 zwracane przez DNS są adresami „lokalnymi” ważnymi tylko w podsieci, w której istnieją hosty RDS, a ponieważ klienci znajdują się w innej podsieci, mogą „ dotrzeć do tych adresów IPv6.

Technologia przejścia IPv6 o nazwie 6to4 jest niesławna z powodu powodowania problemów takich jak ten. W pracy jest kilka czynników. Indywidualnie są one nieszkodliwe, ale połączony efekt polega na tym, że użytkownicy końcowi mogą doświadczać opóźnień połączeń.

Lista czynników sprzyjających i przemyślenia na temat ich łagodzenia przedstawiono poniżej.

Windows domyślnie włącza 6to4

Jeśli na hostach jest zainstalowana najnowsza wersja systemu Windows (Vista lub nowsza), system Windows w sposób oportunistyczny umożliwi tunelowanie 6to4, gdy dostępny jest publicznie rutowalny adres IPv4. Krytycznie dotyczy to zarówno serwerów, jak i klientów.

Aby dowiedzieć się, czy system używa 6to4, uruchom ipconfigi poszukaj adresu IPv6, który zaczyna się od prefiksu 6to4 2002:. Wyglądałoby to mniej więcej tak.

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

• Jeśli punkty końcowe są połączone z usługą Active Directory, możesz użyć zasad grupy, aby wyłączyć protokoły przejścia, takie jak 6to4 i Teredo. Jest to dobrze udokumentowane w KB929852 . (Zastosowanie tego do klientów lub serwerów byłoby wystarczające, ale jeśli wykonasz ten krok, prawdopodobnie warto go wyłączyć wszędzie, zarówno na klientach, jak i serwerach).
• Jeśli zarządzasz tylko kilkoma hostami, możesz wyłączyć 6to4 indywidualnie dla każdego przypadku. Jest to o wiele lepsze niż całkowite wyłączenie IPv6.netsh int ipv6 6to4 set state disabled
• Użyj innego systemu operacyjnego klienta. Na przykład system Mac OS X nie ma domyślnie włączonej funkcji 6to4.

Używane są publicznie rutowalne adresy IPv4

6to4 działa tylko na hostach, które mają publicznie rutowalne adresy IPv4, więc ten problem nigdy nie wpływa na hosty za zaporą NAT.

• Możesz przenieść klientów i / lub serwery za zaporę NAT i zacząć używać adresowania RFC1918. Ale w niektórych przypadkach publicznie routowalne adresy są faktycznie preferowane. Zmiana adresowania całej sieci może być również nierealnym wyborem.

6to4 nie działa poprawnie w sieci

Niesamowicie trudne jest rozwiązywanie problemów z 6to4 w trybie anycast. Jest to tak kłopotliwe, że do IETF została formalnie złożona prośba o zmianę klasyfikacji 6to4 na historyczną . W opinii tego autora 6to4 jest przestarzałe.

W skrócie, 6to4 działa poprzez enkapsulację pakietów IPv6 w pakiety IPv4 przy użyciu protokołu o nazwie 6in4 (protokół IP = 41). Pakiety IPv4 są adresowane na dowolny adres 192.88.99.1w nadziei, że dotrze on do działającego przekaźnika 6to4 gdzieś w Internecie. Może być nawet geograficznie blisko, jeśli masz szczęście.

W praktyce niektóre przekaźniki 6to4 są niepoprawnie skonfigurowane, a wiele sieci nawet nie pozwala na przekroczenie zapory przez ruch 6w4. Zwykle dzieje się tak, gdy zapora zezwala na cały ruch wychodzący, ale nie pozwala jawnie na zwrot 41 pakietów IP przez zaporę. (DO ZROBIENIA zwróć uwagę na odpowiedni RFC do rozwiązywania problemów.) Ta awaria („przychodząca czarna dziura”) i wiele innych opisano w RFC 6343 .

• Skonfiguruj zaporę sieciową, aby głośno odrzucała protokół IP 41 (z resetami TCP) po wysłaniu z hostów wewnętrznych do sieci. Powinno to skutkować „szybkim awarią”, które ma większy sens niż niedeterministyczne opóźnienia połączeń. Zostało wykazane do pracy w ograniczonych środowiskach testowych .
• Poproś dostawcę usług internetowych lub dostawcę przesiadek o pierwszym przeskoku o skonfigurowanie działającego przekaźnika 6to4. Jeśli zrobisz to dobrze, zapewni to najlepsze wrażenia dla użytkowników końcowych. Każdy użytkownik końcowy z publicznie routowalnym adresem IPv4 będzie mógł uczestniczyć w Internecie IPv6.

Dynamiczna rejestracja DNS

W typowym środowisku Active Directory każdy komputer może zarejestrować własne adresy na serwerze DNS. Kiedy host jest wielodomowy, zarejestruje wszystkie swoje adresy, nawet z tunelu 6to4.

Większość usług internetowych nie korzysta z dynamicznego DNS, więc ten problem jest zwykle ograniczony do witryn korporacyjnych, w których klienci i serwery są „wewnętrzni” w tej samej sieci.

• Możesz wyłączyć dynamiczne aktualizacje DNS. Następnie, jeśli nie umieścisz żadnych rekordów zasobów AAAA w pliku strefy, nigdy nie zostaną one dostarczone. Jednak dynamiczny DNS jest często pożądany w przypadku wewnętrznych serwerów DNS. (Jeśli to zrobisz, pamiętaj również o usunięciu wszelkich rekordów AAAA, które mogą już być obecne).
• Skonfiguruj serwer DNS, aby nie udzielał odpowiedzi na rekordy zasobów AAAA. Ale nie rób tego, ponieważ naprawdę sprawi ci to kłopotów, gdy zaczniesz wdrażać IPv6. (Czy ktoś wie o darmowej / otwartej zaporze DNS?)

Aplikacja kliencka nie zawiedzie płynnie

Klient RDP firmy Microsoft to jeden przykład aplikacji klienckiej, która nie radzi sobie z problemami z routingiem IPv6. Większość przeglądarek internetowych lepiej radzi sobie z przypadkami takimi jak ten IPv6, więc nie wykazują takiego zachowania.

• Spróbuj użyć innego klienta. Może będziesz miał szczęście.

Zdaję sobie sprawę, że nie jest to bardzo pomocne w tej sytuacji, ale dla implementatorów stojących przed podobnym dylematem istnieje technika implementacji znana jako „Happy Eyeballs” (RFC 6555), która określa technikę jednoczesnego łączenia się z ipv4 i ipv6 i wybierania tego, co nastąpi najpierw.

Oto moje rozwiązanie. Domyślnie system Windows nadaje trasom IPv6 wyższy priorytet niż trasy IPv4. Jeśli edytujesz zasady prefiksu IPv6, możesz zmienić to zachowanie, aby korzystało z IPv4 zamiast IPv6.

Aby upewnić się, że wszystkie systemy w mojej sieci są skonfigurowane w ten sam sposób, umieściłem następujące polecenia w skrypcie .bat uruchomionym podczas instalacji oprogramowania po zbudowaniu lub odnowie komputera.

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

Aby wyjaśnić, co to robi:

Pierwsze 3 linie wyłączają wbudowane interfejsy tunelowania, ponieważ są one nadmiarowe dla większości sieci. Możesz nie używać tych 3 linii, jeśli nie podajesz swoim komputerom własnych adresów IPv6, w moim przypadku mam serwer DHCPv6 i powiązaną infrastrukturę przypisującą IPv6 dla tunelowanej łączności

Drugi blok poleceń usuwa wszystkie istniejące zasady prefiksów routingu IPv6.

Trzeci blok następnie odtwarza zasady dotyczące prefiksów IPv6, ale używa innego zestawu priorytetów. Podobnie prefiks odpowiadający IPv4 ma pierwszeństwo przed IPv6, a maszyna będzie wtedy chciała używać IPv4, chyba że aplikacja określi użycie IPv6.

To rozwiązanie zachowuje funkcjonalną funkcję podwójnego stosu, ale preferencja korzystania z IPv4 oznacza, że ​​strony z niepełnym, zawodnym lub słabo działającym IPv6 unikną go, chyba że program w systemie o tym poinformuje.

Moim zdaniem zmuszenie systemów operacyjnych do używania IPv6 zamiast IPv4 w rzeczywistości utrudnia adopcję. W okresie przejściowym będą chwile, gdy host będzie myślał, że ma połączenie IPv6, ale tak naprawdę nie ma w pełni funkcjonalnego połączenia, co prowadzi do wadliwego działania oprogramowania i dużych opóźnień. Wiele osób, które znam, całkowicie wyłączyło IPv6 na swoim routerze jako obejście dla dostawców usług internetowych wdrażających IPv6 w sposób przerywany na początku przed ustanowieniem pełnej łączności, a ci ludzie po prostu zapomną włączyć tę funkcję ponownie, pozostawiając im bez IPv6, dopóki ponownie nie skonfigurują routera.