Nestede VPN-tunneler: hvorfor den indre stopper på store pakker

DNS løses opp, SSH-økten holder seg, og så fryser en stor opplasting mens en ping til samme vert fortsatt svarer. Denne delingen peker på pakkestørrelse snarere enn en ødelagt tunnel. Nestede tunneler når dette ved størrelser som ingen av tunnelene ville nå alene. Den indre økten har det bra; den får bare pakker som ikke lenger passer.

Hvor veiens MTU egentlig tar veien

Hver innkapsling bruker bytes før neste lag får sin tur. En Ethernet-vei tilbyr 1500 bytes til den ytre pakken, og den ytre tunnelen tar sin del før noe inni den kan adresseres. Én gjettet overheadverdi vil være feil med nøyaktig det beløpet som betyr noe.

List opp lagene i rekkefølge: tilgangsvei, ytre transport, ytre tunnel, indre transport, indre tunnel, applikasjon. Tell hver header én gang, og hold UDP atskilt fra tunnelens egen header og tag.

To WireGuard-lag, talt én gang

Ta en IPv4-tilgangsvei med én WireGuard-tunnel inne i en annen. Det ytre laget koster 20 bytes IPv4, 8 UDP og 32 for WireGuards dataheader pluss autentiseringstagen. Inni der trenger den indre tunnelen sin egen IPv4-header på 20 bytes og UDP-header på 8 bytes før sine andre 32 bytes WireGuard-overhead. Det som er igjen rommer en IPv4-header, en TCP-header og dataene. En ytre IPv6-vei koster 40 i stedet for 20 og etterlater 1320.

Regnestykket lander på 1340 bytes. Ett lag etter de samme reglene etterlater 1400 til TCP-nyttelasten, som er 1500 minus 20, 8, 32, 20 og 20, og forskjellen på 60 bytes er nøyaktig den indre innkapslingen som den andre tunnelen legger til.

Bruk 1400 på en nestet vei, og den indre tunnelen mangler 60 bytes, usynlig til en pakke er stor nok til å trenge dem. Polstring og protokollens egen fragmenteringsopsjon flytter tallene igjen, så stol på tabellen.

MTU, MSS og fragmentering virker på forskjellige steder

Interface-MTU begrenser hva interfacet sender ut, mens TCP-MSS-klemming endrer hva en TCP-peer er villig til å sende. Klemming reparerer TCP-økter og gjør ingenting for et stort UDP-datagram, og det er slik en rettelse ser vellykket ut for én applikasjon og stille bommer på den neste. Protokollens egen fragmenteringsopsjon er en tredje spak med sine egne feil. Interface-MTU er det vanlige første trekket og det groveste.

Broede og rutede tunneler bærer forskjellige rammer, så tall fra en annen utrulling overføres sjelden. Veiens MTU-oppdagelse, beskrevet i RFC 8201, hjelper bare så lenge ICMP-meldingene den avhenger av, slippes gjennom.

Finne laget som mangler

Verifiser hver tunnel alene før de nestede, hvis kravene tillater en sammenligning. En sonde med fast størrelse avgjør det: ping -M do -s 1472 -c 3 10.8.0.1 sender en full IPv4-pakke på 1500 bytes inne i det laget. Legg til det andre laget og gjenta den samme sonden, slik at enhver feil hører til en kjent endring.

Når en overføring stopper, endre én dokumentert parameter om gangen og noter størrelsen som feiler. Sjekk returveien også, for nestet rute-rekursjon kan etterligne et pakkestørrelsesproblem nært nok til å koste en ettermiddag. En filtrert ICMP-respons kan skjule den egentlige grensen, så sonden betyr mer enn resonnementet.

Skriv budsjettet der den neste personen finner det

En tabell med én rad per lag overlever en tommelfingerregel. Hold den ved siden av tunneldiagrammet så ingen gjør regnestykket på nytt under press.

Flere tunneler betyr flere avhengigheter, så en tilbakerullingsplan fortjener plassen sin ved siden av budsjettet. Hvis tallene fortsatt ikke går opp, mål veien i stedet for å gjette igjen. Målet er et tall du kan forsvare, ikke huske.