IPv4 fragmentuje w tranzycie; IPv6 wysyła zamiast tego komunikat o zbyt dużym pakiecie

Awarie IPv6 są znacznie częściej zrzucane na protokół niż na rozmiar pakietu, który je spowodował. Obie rodziny naprawdę inaczej obchodzą się z zbyt dużym pakietem, a to tunel sprawia, że ta różnica ma znaczenie. Routery IPv4 mogą fragmentować pakiet, gdy reguły na to pozwalają, natomiast routery IPv6 nie mogą fragmentować w tranzycie w ogóle. IPv6 mówi o tym zamiast tego nadawcy, a od nadawcy oczekuje się reakcji. Wszystko, co potem idzie nie tak, wynika z tego, czy ten komunikat dotrze.

Co robi każda rodzina

Tabela to mechanizm w czterech wierszach, a jeden wiersz wyjaśnia większość zamieszania.

IPv6 nie ma fragmentacji w tranzycie ani flagi DF do wyczyszczenia, więc nie ma na czym się oprzeć, gdy pakiet jest zbyt duży. Nadawcę trzeba o tym powiadomić, a nadawca musi w to uwierzyć.

Tunel po cichu zwęża ścieżkę

VPN dodaje zewnętrzne nagłówki, a w przypadku szyfrowanym także dane integralności, zanim pakiet opuści host. Pakiet wewnętrzny może zmieścić się w MTU interfejsu, który widzi, podczas gdy pakiet zewnętrzny przekracza limit następnego łącza, i dlatego to pojawia się najpierw w tunelu. Celowo obniż MTU interfejsu tunelu albo dociśnij TCP MSS na ścieżce, i zapisz, którą wartość wybrałeś i dlaczego.

Narzut ESP zależy od trybu i algorytmów, więc właściwe MTU tunelu to obliczenie, a nie konwencja. Cokolwiek wybierzesz, musi zostawić miejsce na pełny wewnętrzny pakiet IPv6 o rozmiarze 1280 bajtów, ponieważ każde łącze IPv6 musi tyle przenosić. Tunel, który nie potrafi przenieść 1280 bajtów IPv6, nie jest problemem strojenia; to zepsuta ścieżka dla tej rodziny. Właśnie to ograniczenie znika, gdy wartość MTU jest kopiowana z wdrożenia obsługującego tylko IPv4.

Dlaczego objaw jest zawieszeniem

Awaria nie jest czystym błędem, i dlatego jest źle diagnozowana. Uścisk dłoni TCP kończy się, małe odpowiedzi docierają, a połączenie zastyga, gdy tylko zaczyna się duża odpowiedź albo duże wysyłanie, bo to pierwsze pakiety wystarczająco duże, by je odrzucić. SSH łączy się i zawiesza na pierwszym dużym wyjściu, a nagłówek strony się ładuje, podczas gdy treść nigdy się nie kończy.

Jeśli komunikaty ICMPv6 o zbyt dużym pakiecie są filtrowane, nadawca nigdy się o tym nie dowie i wciąż ponawia ten sam rozmiar. To czarna dziura, a nie wolna ścieżka, a jej sygnaturą jest powtarzalna granica rozmiaru, nie losowa utrata. Przepuszczanie odpowiedniego ruchu kontrolnego jest częścią działającego wdrożenia IPv6, a nie uprzejmością.

Nie wyłączaj komunikatów, od których zależy twoja własna ścieżka, a potem nie opisuj wyniku jako awarii IPv6. Ten sam argument dotyczy komunikatów Fragmentation Needed w IPv4, równie niepopularnych wśród autorów zapór i równie koniecznych.

Zmierz granicę, a potem napraw warstwę

Sprawdzaj, zamiast zgadywać: użyj flagi don't-fragment w IPv4 i stałych rozmiarów ładunku w IPv6, i zapisz, gdzie odpowiedzi się zatrzymują. ping -M do -s 1472 i ping -6 -s 1400 wystarczą, by ustalić kształt problemu, a tracepath raportuje odkryte MTU ścieżki po drodze.

Potem napraw warstwę, która jest właścicielem liczby: MTU interfejsu tunelu, zaciskanie MSS dla TCP albo samą ścieżkę. RFC 8200 jest referencją dla reguły IPv6 i czyta się ją krócej niż incydent, któremu zapobiega.

Testuj rodzinę, której aplikacja naprawdę używa, bo nazwa dwustosowa może odpowiadać w jednej rodzinie, a nie w drugiej, a aplikacja może się przełączyć po zmianie sieci. Zapisz adres, który testowałeś, bo wynik względem rekordu A nic nie mówi o rekordzie AAAA.

Traktuj granicę rozmiaru jako dowód

Powtarzalna granica rozmiaru to jedna z niewielu awarii sieci, które odtwarzają się dokładnie, przy tej samej liczbie bajtów, z tego samego źródła, za każdym razem. To czyni ją prezentem, a nie zagadką, i oznacza też, że poprawkę można zweryfikować, a nie mieć nadzieję.

Zapisz w zgłoszeniu odkryte MTU, skonfigurowane MTU tunelu i test, który dowiódł różnicy. Następna osoba spotka tę samą arytmetykę na innym łączu.