Pachet IPv6 prea mare: de ce se blochează transferurile mari prin VPN

Pingul funcționează, browserul încarcă o pagină mică, iar transferul de fișiere se blochează, totul prin IPv6 în același tunel. Acest model înseamnă de obicei că expeditorul nu a aflat niciodată dimensiunea reală a căii, nu că tunelul este lent. IPv6 se așteaptă ca routerele să raporteze problema printr-un mesaj Packet Too Big, iar încapsularea adaugă suprasarcină înainte ca un pachet să ajungă în rețeaua exterioară. Dacă mesajul este filtrat, expeditorul repetă o dimensiune care nu poate trece.

Cereri mici, blocaje mari

Un tunel împachetează fiecare pachet într-un alt antet, așa că dimensiunea utilizabilă din interior este mai mică decât cea din exterior. Un pachet dimensionat pentru legătura fizică înainte de încapsulare devine prea mare după aceea. Routerele IPv4 pot fragmenta pe parcurs, în timp ce routerele IPv6 nu fac asta în numele expeditorului, așa că expeditorul trebuie să se ajusteze singur. Iar această ajustare depinde în întregime de primirea feedbackului.

Un singur mesaj pierdut este suficient pentru simptomul clasic: strângerile de mână și răspunsurile mici reușesc, iar o listare de director sau o încărcare se blochează de fiecare dată în același punct. Utilizatorii o descriu ca VPN lent, iar jurnalele nu arată nimic greșit la autentificare. Ambele observații sunt exacte și niciuna nu localizează defecțiunea.

Packet Too Big este feedback, nu trafic

Un mesaj ICMPv6 Packet Too Big poartă dimensiunea pe care următorul salt o poate accepta, iar expeditorul îl folosește pentru a-și reduce estimarea. A-l filtra echivalează cu a scoate un indicator rutier și apoi a da vina pe șoferi. O regulă care aruncă tot ICMPv6 pare strictă, dar strică descoperirea căii pe fiecare legătură care are nevoie de ea. Mesajul este informație de control despre cale, nu încărcătură utilă a aplicației.

Filtrarea selectivă rămâne rezonabilă. Cererile de ecou și descoperirea vecinilor au un rol diferit de mesajele de eroare, iar o politică le poate trata diferit. Urmați îndrumările de filtrare documentate ale platformei în loc să acceptați sau să eliminați întregul protocol, deoarece RFC 8201 definește modul în care acest feedback conduce descoperirea.

Testați ambele familii de adrese separat

Testați IPv6 separat, deoarece un transfer IPv4 reușit nu dovedește nimic despre calea IPv6. Apoi capturați mesajele de control cât timp transferul mare se blochează. Cele două înregistrări împreună arată fie că feedbackul pleacă, fie dovedesc că nu a ajuns niciodată.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

Sonda trimite un pachet cu bitul do-not-fragment setat și raportează dimensiunea la care eșuează, adică numărul pe care tunelul trebuie să îl încapă. Interogarea de rută numește interfața care ar transporta destinația, așa că știți ce MTU al legăturii se aplică. Captura filtrează ICMPv6 tip 2, mesajul Packet Too Big, și arată dacă acesta ajunge la acest host. Dacă mesajul apare în captură și transferul încă se blochează, expeditorul îl ignoră, ceea ce mută investigația în stivă, nu în rețea.

Schimbați dimensiunea tunelului doar după dovezi

Reducerea MTU-ului tunelului poate ascunde un mesaj filtrat și poate face simptomul să dispară, cu prețul unei suprasarcini mai mari la fiecare pachet. Este o ocolire, nu un diagnostic, și ar trebui să urmeze capturii în loc să o înlocuiască. O valoare arbitrar de mică nu strică nimic vizibil, motiv pentru care supraviețuiește ani în configurații. Schimbați-o deliberat, notați valoarea și precizați ce măsurătoare a justificat-o.

Când controlați gateway-ul, examinați regula care aruncă mesajul în loc să dezactivați firewall-ul. O singură regulă corectată este mai îngustă decât o excepție de politică și mult mai ușor de apărat mai târziu. Același raționament se aplică pentru time-out-uri: nu orice blocaj este o problemă de dimensiune, iar captura este cea care le separă.