Vnořené tunely VPN: proč se vnitřní zasekává u velkých paketů
Každý tunel spotřebuje část rozpočtu paketů cesty, než začne další. Sečtěte hlavičky a vnitřní relace u velkých paketů selže.
DNS se přeloží, SSH relace drží, a pak se velké nahrávání zasekne, zatímco ping na stejný hostitel stále odpovídá. Toto rozdělení ukazuje na velikost paketu, ne na rozbitý tunel. Vnořené tunely toho dosahují při velikostech, kterých by žádný tunel sám nedosáhl. Vnitřní relace je v pořádku; dostávají se jí pakety, které se už nevejdou.
Kam MTU cesty skutečně odchází
Každá enkapsulace spotřebuje bajty, než se další vrstva dostane na řadu. Ethernetová cesta nabízí vnějšímu paketu 1500 bajtů a vnější tunel si vezme svůj podíl, než lze cokoli uvnitř adresovat. Jedna odhadnutá hodnota režie bude špatná přesně o tolik, o kolik jde.
Vyjmenujte vrstvy v pořadí: přístupová cesta, vnější transport, vnější tunel, vnitřní transport, vnitřní tunel, aplikace. Každou hlavičku počítejte jednou a UDP držte oddělené od vlastní hlavičky tunelu a jeho značky.
Dvě vrstvy WireGuard, počítané jednou
Vezměte přístupovou cestu IPv4 s jedním tunelem WireGuard uvnitř druhého. Vnější vrstva stojí 20 bajtů IPv4, 8 UDP a 32 za datovou hlavičku WireGuard plus její ověřovací značku. Uvnitř toho vnitřní tunel potřebuje vlastní 20bajtovou hlavičku IPv4 a 8bajtovou hlavičku UDP před svými druhými 32 bajty režie WireGuard. Co zbývá, pojme hlavičku IPv4, hlavičku TCP a data. Vnější cesta IPv6 stojí 40 místo 20 a nechává 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 bajtech. Jedna vrstva podle stejných pravidel nechává 1400 pro užitečné zatížení TCP, což je 1500 minus 20, 8, 32, 20 a 20, a rozdíl 60 bajtů je přesně vnitřní enkapsulace, kterou přidává druhý tunel.
Použijte 1400 na vnořenou cestu a vnitřnímu tunelu chybí 60 bajtů, neviditelně, dokud paket není dost velký, aby je potřeboval. Výplň a vlastní možnost fragmentace protokolu čísla znovu posouvají, takže věřte tabulce.
MTU, MSS a fragmentace působí na různých místech
MTU rozhraní omezuje, co rozhraní vyšle, zatímco sevření MSS v TCP mění, co je TCP protějšek ochoten poslat. Sevření opravuje relace TCP a pro velký datagram UDP nedělá nic, a tak oprava vypadá úspěšně pro jednu aplikaci a tiše mine další. Vlastní možnost fragmentace protokolu je třetí páka s vlastními selháními. MTU rozhraní je obvyklý první krok a ten nejhrubší.
Přemostěné a směrované tunely nesou různé rámce, takže čísla z jiného nasazení se málokdy přenesou. Zjišťování MTU cesty, popsané v RFC 8201, pomáhá jen tehdy, dokud jsou zprávy ICMP, na nichž závisí, propouštěny.
Nalezení vrstvy, které chybí
Ověřte každý tunel samostatně, než je vnoříte, pokud to požadavky dovolují srovnat. Sonda pevné velikosti to rozhodne: ping -M do -s 1472 -c 3 10.8.0.1 pošle plný paket IPv4 o 1500 bajtech uvnitř této vrstvy. Přidejte druhou vrstvu a zopakujte stejnou sondu, aby každé selhání patřilo známé změně.
Když se přenos zasekne, měňte jeden zdokumentovaný parametr najednou a zaznamenejte velikost, na které selhává. Zkontrolujte i zpáteční cestu, protože vnořená rekurze tras může napodobit problém s velikostí paketu dost blízko na to, aby stál celé odpoledne. Filtrovaná odpověď ICMP může skrýt skutečný limit, takže sonda je důležitější než uvažování.
Napište rozpočet tam, kde ho najde další člověk
Tabulka s jedním řádkem na vrstvu přežije pravidlo palce. Mějte ji vedle schématu tunelu, aby nikdo nepřepočítával aritmetiku pod tlakem.
Více tunelů znamená více závislostí, takže plán návratu si zaslouží místo vedle rozpočtu. Pokud čísla stále nesedí, změřte cestu, místo abyste znovu hádali. Cílem je číslo, které dokážete obhájit, ne si zapamatovat.