Přenos pevného vnitřního paketu o 1,500 bajtech přes VPN

Máte požadavek, který se neohýbá: protější strana musí přijmout stejný IP paket o 1,500 bajtech, který odesílatel vyšle, včetně hlaviček. Tunel nemůže tento paket spolu s vlastním rámováním zabalit do druhého IP paketu o 1,500 bajtech, takže něco v návrhu musí ustoupit. Pořadí níže je to, které používám v okně změn: zapište rozpočet bajtů, dokažte, co spodní síť skutečně unese, pak vyberte právě jeden přenosový mechanismus a potvrďte vnitřní paket na protější straně.

Zapište rozpočet bajtů dřív, než upravíte profil

Zapouzdření přidává bajty v několika vrstvách a součet je vlastnost vašeho profilu, nikoli konstanta, kterou lze dohledat. Rodina adres, volba šifry, transportní protokol a jakákoli volba komprese nebo rámování toto číslo mění, proto je odčítání zkopírované z jiného nasazení jako rozpočet bezcenné. Začněte u vnitřního požadavku, přidejte naměřenou režii na paket své konfigurace a výslednou vnější velikost zapište do tiketu změny dřív, než někdo upraví soubor.

Návrh určují dvě čísla: největší vnější paket, který cesta nese bez fragmentace, a bajty navíc, které vaše zapouzdření potřebuje. Když je první menší než druhé plus 1,500, jedno z nich se musí změnit. Volba je pak úzká, nikoli tvůrčí, proto obě čísla zapisuji před diskusí o možnostech. Nic na vrstvě tunelu ty bajty nekomprimuje a žádné jediné celé číslo MTU neodstraní požadavek, který jste dostali.

Otestujte spodní síť pingy se zákazem fragmentace

Měřte cestu, místo abyste věřili MTU rozhraní, protože rozhoduje nejmenší článek vnější cesty. V Linuxu -M do nastavuje bit zákazu fragmentace a -s přebírá užitečné zatížení ICMP, takže rámec o 1,500 bajtech odpovídá při 1,472 bajtech zatížení poté, co se odečte 20bajtová hlavička IP a 8bajtová hlavička ICMP. Zvyšujte zatížení, dokud test neselže, pak skočte na jumbo velikost, abyste zjistili, zda ji cesta vůbec unese.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

Cesta, která projde 1,472 a selže na 8,972, nemůže v jednom vnějším paketu unést vnitřní paket o 1,500 bajtech plus režii. To je odpověď, kterou jste potřebovali před otevřením konfigurace VPN. Také rozhoduje, která z následujících dvou částí se na vás vztahuje, proto držte oba výsledky testu u tiketu. Hádání zde stojí jedno servisní okno, protože tunel, který se hlásí jako aktivní, vám neřekne nic o největším paketu, který cesta přijme.

Zvyšte MTU cesty jen tam, kde s tím souhlasí každý hop

Jumbo rámce jsou vlastnost od konce ke konci, ne nastavení, které zapnete na dvou koncových bodech, které zrovna ovládáte. Každý switch, router a předávací bod poskytovatele na vnější cestě musí souhlasit s větší velikostí a jediný hop o 1,500 bajtech tiše zahodí paket, který jste právě zvětšili. Zvednutí jen místního rozhraní je klasická poloviční změna, kvůli které tunel vypadá rozbitý, zatímco spodní síť tiše zahazuje.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

Změňte rozhraní a potom znovu otestujte stejnou cestu, než změníte cokoli jiného. Pokud test stále selhává, vraťte to pomocí ip link set dev eth1 mtu 1500 a přejděte k fragmentaci, místo abyste se hádali s poskytovatelem o spoj, který nevlastníte.

Použijte fragmentaci tunelu, když spodní síť nemůže růst

Podporovaný mechanismus fragmentace pod vnitřním paketem umožňuje několika vnějším paketům nést jeden vnitřní paket a vzdálený konec tunelu je znovu složí, než předá originál do zásobníku. Volba fragmentace UDP v Community OpenVPN je jednou implementací této myšlenky a není totéž jako běžná IP fragmentace vnějšího paketu. Oba partneři musí provozovat verzi, která formát podporuje, a datová cesta musí být ta, kterou si myslíte: klienti OpenVPN 3 a jádrem zrychlené datové kanály mají různá omezení, takže profil, který funguje na jednom klientovi, může na jiném selhat.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

Běžná vnější fragmentace je druhá možnost a je slabší. Routery IPv6 přeposílaný paket vůbec nefragmentují, takže příliš velký vnější paket prostě zanikne a odesílatel se to dozví jen tehdy, pokud příslušná zpráva ICMPv6 cestu přežije. Fragmenty také zvou filtraci a zesílení ztrát, proto to beru jako záložní variantu, ne jako plán.

Vnější nosič založený na toku otázku velikosti obchází tím, že segmentuje vlastní bajtový tok, a rekonstruovaný vnitřní paket může mít stále 1,500 bajtů. To je transportní rozhodnutí s vlastní cenou, včetně známého chování TCP v TCP, takže ho udělejte vědomě, ne jako vedlejší účinek hádky o MTU.

Potvrďte, že vnitřní paket dorazí nezměněný

Ověření není úspěšný handshake. Zachyťte provoz na rozhraní tunelu na obou koncích a porovnejte velikost a obsah paketu, který aplikace skutečně odeslala, s tím, který protější strana přijala.

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

Pokud zachycení ukáže na vzdáleném konci vnitřní paket plné velikosti, volba přenosu funguje a zbývá ji jen zaznamenat. Pokud neukáže nic, zatímco se tunel hlásí jako aktivní, vnější paket se zahazuje někde mezi koncovými body, což vás vrací k testu, ne k nastavení šifry.

Zapište do tiketu tři věci, než ho zavřete: naměřený vnější rozpočet, zvolený mechanismus a příkaz, který prokázal, že vnitřní paket přežil. Další člověk, který se tohoto tunelu dotkne, bude potřebovat všechny tři a žádný z nich nelze rekonstruovat jen z konfiguračního souboru.