Indlejrede VPN-tunneler: hvorfor den indre går i stå på store pakker

DNS slår op, SSH-sessionen holder, og så fryser en stor upload, mens en ping til den samme vært stadig svarer. Den opdeling peger på pakkestørrelse snarere end på en brudt tunnel. Indlejrede tunneler rammer det ved størrelser, som ingen af tunnelerne ville ramme alene. Den indre session har det fint; den får bare udleveret pakker, der ikke længere passer.

Hvor MTU’en på ruten egentlig går hen

Hver indkapsling bruger bytes, før det næste lag får sin tur. En Ethernet-rute tilbyder 1500 bytes til den ydre pakke, og den ydre tunnel tager sin del, før noget indeni kan adresseres. Én gættet overheadværdi vil være forkert med præcis det beløb, der betyder noget.

List lagene i rækkefølge: adgangsrute, ydre transport, ydre tunnel, indre transport, indre tunnel, applikation. Tæl hver header én gang, og hold UDP adskilt fra tunnellens egen header og tag.

To WireGuard-lag, talt én gang

Tag en IPv4-adgangsrute med én WireGuard-tunnel inde i en anden. Det ydre lag koster 20 bytes IPv4, 8 UDP og 32 til WireGuards dataheader plus dens godkendelsestag. Indeni har den indre tunnel brug for sin egen IPv4-header på 20 bytes og UDP-header på 8 bytes før sine andre 32 bytes WireGuard-overhead. Det, der er tilbage, rummer en IPv4-header, en TCP-header og dataene. En ydre IPv6-rute koster 40 i stedet for 20 og efterlader 1320.

Regnestykket lander på 1340 bytes. Ét lag efter de samme regler efterlader 1400 til TCP-nyttelasten, hvilket er 1500 minus 20, 8, 32, 20 og 20, og forskellen på 60 bytes er præcis den indre indkapsling, som den anden tunnel tilføjer.

Anvend 1400 på en indlejret rute, og den indre tunnel mangler 60 bytes, usynligt indtil en pakke er stor nok til at have brug for dem. Polstring og protokollens egen fragmenteringsmulighed flytter tallene igen, så stol på tabellen.

MTU, MSS og fragmentering virker forskellige steder

Interface-MTU begrænser, hvad interfacet sender, mens TCP-MSS-klemning ændrer, hvad en TCP-peer er villig til at sende. Klemning retter TCP-sessioner og gør intet for et stort UDP-datagram, og det er sådan en rettelse ser vellykket ud for én applikation og stille rammer ved siden af den næste. Protokollens egen fragmenteringsmulighed er en tredje løftestang med sine egne fejl. Interface-MTU er det almindelige første skridt og det groveste.

Broede og routede tunneler bærer forskellige rammer, så tal fra en anden udrulning overføres sjældent. Path-MTU-opdagelse, beskrevet i RFC 8201, hjælper kun, så længe de ICMP-beskeder, den afhænger af, slippes igennem.

Find det lag, der mangler

Kontroller hver tunnel alene, før de indlejres, hvis kravene tillader en sammenligning. En sonde med fast størrelse afgør det: ping -M do -s 1472 -c 3 10.8.0.1 sender en fuld IPv4-pakke på 1500 bytes inde i det lag. Tilføj det andet lag, og gentag den samme sonde, så enhver fejl hører til en kendt ændring.

Når en overførsel går i stå, ændr én dokumenteret parameter ad gangen, og noter den størrelse, der fejler. Kontroller også returvejen, for indlejret rute-rekursion kan efterligne et pakkestørrelsesproblem tæt nok på til at koste en eftermiddag. Et filtreret ICMP-svar kan skjule den egentlige grænse, så sonden betyder mere end ræsonnementet.

Skriv budgettet, hvor den næste person finder det

En tabel med én række pr. lag overlever en tommelfingerregel. Hold den ved siden af tunneldiagrammet, så ingen gentager regnestykket under pres.

Flere tunneler betyder flere afhængigheder, så en tilbagerulningsplan fortjener sin plads ved siden af budgettet. Hvis tallene stadig ikke går op, mål ruten i stedet for at gætte igen. Målet er et tal, du kan forsvare, ikke huske.