IPv6-pakket te groot: waarom grote VPN-overdrachten vastlopen

Ping werkt, de browser laadt een kleine pagina en de bestandsoverdracht blijft hangen, allemaal via IPv6 door dezelfde tunnel. Dat patroon betekent meestal dat de afzender de werkelijke grootte van het pad nooit heeft geleerd, niet dat de tunnel traag is. IPv6 verwacht dat routers het probleem melden met een Packet Too Big-bericht, en inkapseling voegt overhead toe voordat een pakket ooit het buitenste netwerk bereikt. Wordt dat bericht gefilterd, dan blijft de afzender een grootte herhalen die er niet doorheen kan.

Kleine verzoeken, grote stagnaties

Een tunnel verpakt elk pakket in nog een header, dus de bruikbare grootte binnenin is kleiner dan de grootte buiten. Een pakket dat vóór de inkapseling op de fysieke link was afgestemd, wordt daarna te groot. IPv4-routers mogen onderweg fragmenteren, IPv6-routers doen dat niet namens de afzender, dus de afzender moet zichzelf aanpassen. En die aanpassing hangt volledig af van het ontvangen van de terugkoppeling.

Eén verloren bericht is genoeg voor het klassieke symptoom: handshakes en kleine antwoorden slagen, en een mapweergave of een upload blijft elke keer op hetzelfde punt hangen. Gebruikers noemen het een trage VPN, en de logboeken tonen niets mis met de authenticatie. Beide observaties kloppen, en geen van beide vindt de storing.

Packet Too Big is terugkoppeling, geen verkeer

Een ICMPv6 Packet Too Big-bericht draagt de grootte die de volgende hop kan accepteren, en de afzender gebruikt die om zijn schatting te verlagen. Het filteren ervan staat gelijk aan een verkeersbord weghalen en daarna de bestuurders de schuld geven. Een regel die alle ICMPv6 weggooit, lijkt streng maar breekt padontdekking op elke link die het nodig heeft. Het bericht is sturingsinformatie over het pad, geen toepassingspayload.

Selectief filteren blijft redelijk. Echo-verzoeken en buurontdekking spelen een andere rol dan foutberichten, en een beleid kan ze anders behandelen. Volg de gedocumenteerde filterrichtlijnen van het platform in plaats van het hele protocol te accepteren of weg te gooien, omdat RFC 8201 bepaalt hoe die terugkoppeling de ontdekking stuurt.

Test beide adresfamilies apart

Test IPv6 apart, want een geslaagde IPv4-overdracht bewijst niets over het IPv6-pad. Leg daarna sturingsberichten vast terwijl de grote overdracht hangt. De twee opnamen samen laten zien dat de terugkoppeling vertrekt, of bewijzen dat die nooit aankwam.

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'

De sonde stuurt een pakket met de do-not-fragment-bit gezet en meldt de grootte waarbij het mislukt, dat is het getal dat de tunnel moet opvangen. De routevraag noemt de interface die de bestemming zou dragen, zodat je weet welke MTU van de link geldt. De opname filtert ICMPv6 type 2, het Packet Too Big-bericht, en laat zien of het deze host überhaupt bereikt. Als het bericht in de opname verschijnt en de overdracht hangt nog steeds, negeert de afzender het, wat het onderzoek naar de stack verschuift in plaats van naar het netwerk.

Pas de tunnelgrootte pas na het bewijs aan

De MTU van de tunnel verlagen kan een gefilterd bericht verbergen en het symptoom laten verdwijnen, ten koste van meer overhead per pakket. Dat is een omweg en geen diagnose, en die moet de opname volgen in plaats van die te vervangen. Een willekeurig lage waarde breekt ook niets zichtbaars, en daarom overleeft die jaren in configuraties. Wijzig hem bewust, leg de waarde vast en noteer welke meting hem rechtvaardigde.

Als je de gateway beheert, onderzoek dan de regel die het bericht weggooit in plaats van de firewall uit te zetten. Eén gecorrigeerde regel is smaller dan een beleidsuitzondering en later veel makkelijker te verdedigen. Dezelfde redenering geldt voor time-outs: niet elke stagnatie is een grootteprobleem, en een opname is wat de twee scheidt.