Geneste VPN-tunnels: waarom de binnenste vastloopt op grote pakketten

DNS lost op, de SSH-sessie blijft staan, en dan bevriest een grote upload terwijl een ping naar dezelfde host nog antwoordt. Die splitsing wijst op pakketgrootte in plaats van een kapotte tunnel. Geneste tunnels bereiken dat bij groottes die geen van beide tunnels alleen zou halen. De binnensessie is in orde; er worden alleen pakketten aan afgeleverd die niet meer passen.

Waar de MTU van het pad echt naartoe gaat

Elke inkapseling verbruikt bytes voordat de volgende laag aan de beurt is. Een Ethernet-pad biedt het buitenste pakket 1500 bytes, en de buitenste tunnel neemt zijn deel voordat er iets binnenin kan worden geadresseerd. Eén geraden overheadwaarde zal precies zoveel fout zijn als ertoe doet.

Noem de lagen in volgorde: toegangspad, buitenste transport, buitenste tunnel, binnenste transport, binnenste tunnel, toepassing. Tel elke header één keer, en houd UDP apart van de eigen header en tag van de tunnel.

Twee WireGuard-lagen, één keer geteld

Neem een IPv4-toegangspad met één WireGuard-tunnel in een andere. De buitenste laag kost 20 bytes IPv4, 8 UDP en 32 voor de WireGuard-datakop plus de authenticatietag. Daarbinnen heeft de binnenste tunnel zijn eigen IPv4-header van 20 bytes en UDP-header van 8 bytes nodig vóór zijn tweede 32 bytes WireGuard-overhead. Wat overblijft bevat een IPv4-header, een TCP-header en de data. Een buitenste IPv6-pad kost 40 in plaats van 20 en laat 1320 over.

De rekensom komt uit op 1340 bytes. Eén laag volgens dezelfde regels laat 1400 over voor de TCP-nuttige lading, dat is 1500 min 20, 8, 32, 20 en 20, en het verschil van 60 bytes is precies de binnenste inkapseling die de tweede tunnel toevoegt.

Pas 1400 toe op een genest pad en de binnenste tunnel komt 60 bytes tekort, onzichtbaar tot een pakket groot genoeg is om ze nodig te hebben. Opvulling en de eigen fragmentatieoptie van een protocol verschuiven de cijfers opnieuw, dus vertrouw de tabel.

MTU, MSS en fragmentatie werken op verschillende plekken

Interface-MTU beperkt wat de interface uitzendt, terwijl TCP-MSS-clamping verandert wat een TCP-peer bereid is te sturen. Clamping repareert TCP-sessies en doet niets voor een groot UDP-datagram, waardoor een oplossing succesvol lijkt voor de ene toepassing en de volgende stil mist. De eigen fragmentatieoptie van een protocol is een derde hendel met eigen fouten. Interface-MTU is de gebruikelijke eerste stap en de grofste.

Bruggen en gerouteerde tunnels dragen verschillende frames, dus cijfers uit een andere uitrol gaan zelden over. Pad-MTU-ontdekking, beschreven in RFC 8201, helpt alleen zolang de ICMP-berichten waarvan het afhangt worden doorgelaten.

De laag vinden die tekortschiet

Controleer elke tunnel afzonderlijk voordat je ze nest, als de eisen een vergelijking toestaan. Een sonde met vaste grootte beslist het: ping -M do -s 1472 -c 3 10.8.0.1 stuurt een volledig IPv4-pakket van 1500 bytes binnen die laag. Voeg de tweede laag toe en herhaal dezelfde sonde, zodat elke storing bij een bekende wijziging hoort.

Als een overdracht blijft hangen, wijzig dan één gedocumenteerde parameter tegelijk en noteer de grootte die faalt. Controleer ook het terugpad, want geneste routerecursie kan een pakketgrootteprobleem dicht genoeg nabootsen om een middag te kosten. Een gefilterd ICMP-antwoord kan de echte grens verbergen, dus de sonde is belangrijker dan de redenering.

Schrijf het budget waar de volgende persoon het vindt

Een tabel met één rij per laag overleeft een vuistregel. Houd hem naast het tunnelschema zodat niemand de rekensom onder druk opnieuw doet.

Meer tunnels betekenen meer afhankelijkheden, dus een terugdraaiplan verdient zijn plek naast het budget. Als de cijfers nog steeds niet kloppen, meet het pad in plaats van opnieuw te gissen. Het doel is een cijfer dat je kunt verdedigen, niet onthouden.