Nesta VPN-tunnelar: kvifor den indre stoppar på store pakkar
Kvar tunnel brukar ein del av vegens pakkebudsjett før den neste byrjar. Legg saman headerane, og den indre økta feilar på store pakkar.
DNS løyser seg opp, SSH-økta held seg, og så frys ein stor opplasting medan ein ping til same vert framleis svarar. Denne delinga peikar på pakkestorleik snarare enn ein øydelagd tunnel. Nesta tunnelar når dette ved storleikar som ingen av tunnelane ville nå åleine. Den indre økta har det bra; ho får berre pakkar som ikkje lenger passar.
Kvar vegens MTU eigentleg tek vegen
Kvar innkapsling brukar byte før neste lag får sin tur. Ein Ethernet-veg tilbyr 1500 byte til den ytre pakken, og den ytre tunnelen tek sin del før noko inni han kan adresserast. Éin gjettverdi for overhead vil vere feil med nøyaktig det beløpet som betyr noko.
List opp laga i rekkjefølgje: tilgangsveg, ytre transport, ytre tunnel, indre transport, indre tunnel, applikasjon. Tel kvar header éin gong, og hald UDP skilt frå tunnelen sin eigen header og tag.
To WireGuard-lag, talde éin gong
Ta ein IPv4-tilgangsveg med éin WireGuard-tunnel inne i ein annan. Det ytre laget kostar 20 byte IPv4, 8 UDP og 32 for WireGuard sin dataheader pluss autentiseringstagen. Inni der treng den indre tunnelen sin eigen IPv4-header på 20 byte og UDP-header på 8 byte før sine andre 32 byte WireGuard-overhead. Det som er att rommar ein IPv4-header, ein TCP-header og dataa. Ein ytre IPv6-veg kostar 40 i staden for 20 og lèt att 1320.
| Layer | Bytes |
|---|---|
| Path MTU | 1500 |
| Outer IPv4 header | 20 |
| Outer UDP header | 8 |
| Outer WireGuard header and tag | 32 |
| Inner transport IPv4 header | 20 |
| Inner UDP header | 8 |
| Inner WireGuard header and tag | 32 |
| Innermost IPv4 header | 20 |
| TCP header | 20 |
| Payload that fits | 1340 |
Reknestykket landar på 1340 byte. Eitt lag etter dei same reglane lèt att 1400 til TCP-nyttelasta, som er 1500 minus 20, 8, 32, 20 og 20, og skilnaden på 60 byte er nøyaktig den indre innkapslinga som den andre tunnelen legg til.
Bruk 1400 på ein nesta veg, og den indre tunnelen manglar 60 byte, usynleg til ein pakke er stor nok til å trenge dei. Polstring og protokollen sin eigen fragmenteringsopsjon flyttar tala igjen, så stol på tabellen.
MTU, MSS og fragmentering verkar på ulike stader
Interface-MTU avgrensar kva grensesnittet sender ut, medan TCP-MSS-klemming endrar kva ein TCP-peer er villig til å sende. Klemming reparerer TCP-økter og gjer ingenting for eit stort UDP-datagram, og slik ser ei retting vellykka ut for éin applikasjon og bommar stille på den neste. Protokollen sin eigen fragmenteringsopsjon er ein tredje spak med sine eigne feil. Interface-MTU er det vanlege første trekket og det grovaste.
Brúa og ruta tunnelar ber ulike rammer, så tal frå ei anna utrulling blir sjeldan overførte. Vegens MTU-oppdaging, skildra i RFC 8201, hjelper berre så lenge ICMP-meldingane ho er avhengig av, blir sleppte gjennom.
Finne laget som manglar
Verifiser kvar tunnel åleine før dei blir nesta, om krava tillèt ei samanlikning. Ein sonde med fast storleik avgjer det: ping -M do -s 1472 -c 3 10.8.0.1 sender ein full IPv4-pakke på 1500 byte inne i det laget. Legg til det andre laget og gjer den same sonden om att, slik at kvar feil høyrer til ei kjend endring.
Når ei overføring stoppar, endre éin dokumentert parameter om gongen og noter storleiken som feilar. Sjekk returvegen òg, for nesta rute-rekursjon kan etterlikne eit pakkestorleiksproblem nært nok til å koste ein ettermiddag. Eit filtrert ICMP-svar kan skjule den verkelege grensa, så sonden betyr meir enn resonnementet.
Skriv budsjettet der den neste personen finn det
Ein tabell med éi rad per lag overlever ein tommelfingerregel. Hald han ved sida av tunneldiagrammet så ingen gjer reknestykket på nytt under press.
Fleire tunnelar betyr fleire avhengnader, så ein tilbakerullingsplan fortener plassen sin ved sida av budsjettet. Om tala framleis ikkje går opp, mål vegen i staden for å gjette igjen. Målet er eit tal du kan forsvare, ikkje hugse.