Nästlade VPN-tunnlar: varför den inre fastnar på stora paket
Varje tunnel gör av med en del av vägens paketbudget innan nästa börjar. Summera headrarna och den inre sessionen misslyckas på stora paket.
DNS löses, SSH-sessionen håller, och sedan fryser en stor uppladdning medan ping till samma värd fortfarande svarar. Den uppdelningen pekar på paketstorlek snarare än en trasig tunnel. Nästlade tunnlar når det vid storlekar som ingen av tunnlarna skulle nå ensam. Den inre sessionen mår bra; den får bara paket som inte längre får plats.
Vart vägens MTU egentligen tar vägen
Varje inkapsling gör av med byte innan nästa lager får sin tur. En Ethernet-väg erbjuder det yttre paketet 1500 byte, och den yttre tunneln tar sin del innan något inuti kan adresseras. Ett gissat overheadvärde kommer att vara fel med exakt det belopp som spelar roll.
Lista lagren i ordning: åtkomstväg, yttre transport, yttre tunnel, inre transport, inre tunnel, applikation. Räkna varje header en gång, och håll UDP skilt från tunnelns egen header och tagg.
Två WireGuard-lager, räknade en gång
Ta en IPv4-åtkomstväg med en WireGuard-tunnel inuti en annan. Det yttre lagret kostar 20 byte IPv4, 8 UDP och 32 för WireGuards dataheader plus dess autentiseringstagg. Inuti det behöver den inre tunneln sin egen IPv4-header på 20 byte och UDP-header på 8 byte före sina andra 32 byte WireGuard-overhead. Det som återstår rymmer en IPv4-header, en TCP-header och data. En yttre IPv6-väg kostar 40 i stället för 20 och lämnar 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 |
Aritmetiken landar på 1340 byte. Ett lager enligt samma regler lämnar 1400 för TCP-nyttolasten, vilket är 1500 minus 20, 8, 32, 20 och 20, och skillnaden på 60 byte är exakt den inre inkapsling som den andra tunneln lägger till.
Använd 1400 på en nästlad väg och den inre tunneln saknar 60 byte, osynligt tills ett paket är stort nog att behöva dem. Utfyllnad och protokollets egen fragmenteringsoption flyttar siffrorna igen, så lita på tabellen.
MTU, MSS och fragmentering verkar på olika ställen
Gränssnittets MTU begränsar vad gränssnittet sänder ut, medan TCP:s MSS-klämning ändrar vad en TCP-peer är villig att skicka. Klämningen reparerar TCP-sessioner och gör ingenting för ett stort UDP-datagram, och det är så en rättelse ser framgångsrik ut för en applikation och tyst missar nästa. Protokollets egen fragmenteringsoption är en tredje spak med sina egna misslyckanden. Gränssnittets MTU är det vanliga första draget och det grövsta.
Bryggade och routade tunnlar bär olika ramar, så siffror från en annan driftsättning överförs sällan. Vägens MTU-upptäckt, beskriven i RFC 8201, hjälper bara så länge ICMP-meddelandena den är beroende av släpps igenom.
Hitta lagret som saknas
Verifiera varje tunnel för sig innan de nästlas, om kraven tillåter en jämförelse. En sond med fast storlek avgör det: ping -M do -s 1472 -c 3 10.8.0.1 skickar ett fullt IPv4-paket på 1500 byte inuti det lagret. Lägg till det andra lagret och upprepa samma sond, så att varje fel hör till en känd ändring.
När en överföring fastnar, ändra en dokumenterad parameter i taget och notera storleken som misslyckas. Kontrollera returvägen också, eftersom nästlad rutt-rekursion kan efterlikna ett paketstorleksproblem tillräckligt nära för att kosta en eftermiddag. Ett filtrerat ICMP-svar kan dölja den verkliga gränsen, så sonden betyder mer än resonemanget.
Skriv budgeten där nästa person hittar den
En tabell med en rad per lager överlever en tumregel. Håll den bredvid tunneldiagrammet så att ingen gör om aritmetiken under press.
Fler tunnlar betyder fler beroenden, så en återställningsplan förtjänar sin plats bredvid budgeten. Om siffrorna fortfarande inte går ihop, mät vägen i stället för att gissa igen. Målet är en siffra du kan försvara, inte komma ihåg.