Vnorené tunely VPN: prečo sa vnútorný zasekáva pri veľkých paketoch
Každý tunel spotrebuje časť rozpočtu paketov cesty, kým sa začne ďalší. Sčítajte hlavičky a vnútorná relácia pri veľkých paketoch zlyhá.
DNS sa preloží, SSH relácia drží, a potom sa veľké nahrávanie zasekne, zatiaľ čo ping na ten istý hostiteľ stále odpovedá. Toto rozdelenie ukazuje na veľkosť paketu, nie na pokazený tunel. Vnorené tunely to dosahujú pri veľkostiach, ktoré by ani jeden tunel sám nedosiahol. Vnútorná relácia je v poriadku; dostáva len pakety, ktoré sa už nezmestia.
Kam MTU cesty skutočne odchádza
Každá enkapsulácia spotrebuje bajty, kým sa ďalšia vrstva dostane na rad. Ethernetová cesta ponúka vonkajšiemu paketu 1500 bajtov a vonkajší tunel si vezme svoj podiel, kým sa čokoľvek vnútri môže adresovať. Jedna odhadnutá hodnota réžie bude nesprávna presne o toľko, o koľko ide.
Vymenujte vrstvy v poradí: prístupová cesta, vonkajší transport, vonkajší tunel, vnútorný transport, vnútorný tunel, aplikácia. Každú hlavičku počítajte raz a UDP držte oddelene od vlastnej hlavičky tunela a jeho značky.
Dve vrstvy WireGuard, počítané raz
Vezmite prístupovú cestu IPv4 s jedným tunelom WireGuard vnútri druhého. Vonkajšia vrstva stojí 20 bajtov IPv4, 8 UDP a 32 za dátovú hlavičku WireGuard plus jej overovaciu značku. Vnútri toho vnútorný tunel potrebuje vlastnú 20-bajtovú hlavičku IPv4 a 8-bajtovú hlavičku UDP pred svojimi druhými 32 bajtmi réžie WireGuard. Čo zostane, pojme hlavičku IPv4, hlavičku TCP a dáta. Vonkajšia cesta IPv6 stojí 40 namiesto 20 a necháva 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 |
Aritmetika končí na 1340 bajtoch. Jedna vrstva podľa rovnakých pravidiel necháva 1400 pre užitočné zaťaženie TCP, čo je 1500 mínus 20, 8, 32, 20 a 20, a rozdiel 60 bajtov je presne vnútorná enkapsulácia, ktorú pridáva druhý tunel.
Použite 1400 na vnorenú cestu a vnútornému tunelu chýba 60 bajtov, neviditeľne, kým paket nie je dosť veľký, aby ich potreboval. Výplň a vlastná možnosť fragmentácie protokolu znova posúvajú čísla, takže verte tabuľke.
MTU, MSS a fragmentácia pôsobia na rôznych miestach
MTU rozhrania obmedzuje, čo rozhranie odošle, zatiaľ čo zovretie MSS v TCP mení, čo je TCP partner ochotný poslať. Zovretie opravuje relácie TCP a pre veľký datagram UDP nerobí nič, a tak oprava vyzerá úspešne pre jednu aplikáciu a ticho minie ďalšiu. Vlastná možnosť fragmentácie protokolu je treťou pákou s vlastnými zlyhaniami. MTU rozhrania je obvyklý prvý krok a ten najhrubší.
Premostené a smerované tunely nesú rôzne rámce, takže čísla z iného nasadenia sa málokedy prenesú. Zisťovanie MTU cesty, opísané v RFC 8201, pomáha len dovtedy, kým sú správy ICMP, na ktorých závisí, prepúšťané.
Nájsť vrstvu, ktorej chýba
Overte každý tunel samostatne, kým ich vnoríte, ak to požiadavky dovoľujú porovnať. Sonda pevnej veľkosti to rozhodne: ping -M do -s 1472 -c 3 10.8.0.1 pošle plný paket IPv4 s 1500 bajtmi v tejto vrstve. Pridajte druhú vrstvu a zopakujte tú istú sondu, aby každé zlyhanie patrilo známej zmene.
Keď sa prenos zasekne, meňte jeden zdokumentovaný parameter naraz a zaznamenajte veľkosť, na ktorej zlyháva. Skontrolujte aj spiatočnú cestu, pretože vnorená rekurzia trás dokáže napodobniť problém s veľkosťou paketu dosť verne na to, aby stál celé popoludnie. Filtrovaná odpoveď ICMP môže skryť skutočný limit, takže sonda je dôležitejšia než uvažovanie.
Napíšte rozpočet tam, kde ho nájde ďalší človek
Tabuľka s jedným riadkom na vrstvu prežije pravidlo palca. Majte ju vedľa schémy tunela, aby nikto neprepočítaval aritmetiku pod tlakom.
Viac tunelov znamená viac závislostí, preto si plán návratu zaslúži miesto vedľa rozpočtu. Ak čísla stále nesedia, zmerajte cestu namiesto ďalšieho hádania. Cieľom je číslo, ktoré dokážete obhájiť, nie si zapamätať.