Prenos pevného vnútorného paketu 1,500 bajtov cez VPN

Máte požiadavku, ktorá sa neohne: druhá strana musí dostať ten istý IP paket 1,500 bajtov, ktorý vysiela odosielateľ, vrátane hlavičiek. Tunel nemôže zabaliť ten paket spolu s vlastným rámovaním do druhého IP paketu 1,500 bajtov, takže niečo v návrhu musí ustúpiť. Poradie nižšie je to, ktoré používam v okne zmien: zapíšte rozpočet v bajtoch, dokážte, čo podklad naozaj unesie, potom vyberte presne jeden mechanizmus prenosu a potvrďte vnútorný paket na druhej strane.

Zapíšte rozpočet v bajtoch pred úpravou profilu

Zapuzdrenie pridáva bajty na viacerých vrstvách a súčet je vlastnosťou vášho profilu, nie konštanta, ktorú možno vyhľadať. Rodina adries, voľba šifry, transportný protokol a akákoľvek voľba kompresie alebo rámovania posúvajú číslo, preto je odčítanie skopírované z iného nasadenia ako rozpočet bezcenné. Začnite vnútornou požiadavkou, pridajte nameranú réžiu na paket vlastnej konfigurácie a zapíšte výslednú vonkajšiu veľkosť do tiketu zmeny, skôr než niekto upraví súbor.

O návrhu rozhodujú dve čísla: najväčší vonkajší paket, ktorý cesta unesie bez fragmentácie, a ďalšie bajty, ktoré potrebuje vaše zapuzdrenie. Keď je prvé menšie ako druhé plus 1,500, jedno z nich sa musí zmeniť. Voľba sa potom stáva úzkou a nie tvorivou, preto si obe čísla zapisujem pred rozhovorom o možnostiach. Nič na vrstve tunela tie bajty nekomprimuje a žiadne jediné celé číslo MTU neodstráni požiadavku, ktorú ste dostali.

Preskúmajte podklad pingom do-not-fragment

Merajte cestu namiesto dôvery v MTU rozhrania, pretože najmenší článok vo vonkajšej ceste je ten, na ktorom záleží. Na Linuxe, -M do nastaví bit do-not-fragment a -s prevezme užitočné zaťaženie ICMP, takže rám 1,500 bajtov odpovedá s 1,472 bajtmi zaťaženia po odčítaní 20-bajtovej IP hlavičky a 8-bajtovej ICMP hlavičky. Zvyšujte zaťaženie, kým test nezlyhá, potom skočte na veľkosť jumbo a zistite, či ho cesta vôbec unesie.

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, ktorá prejde 1,472 a zlyhá na 8,972, nemôže uniesť vnútorný paket 1,500 bajtov s réžiou v jednom vonkajšom pakete. To je odpoveď, ktorú ste potrebovali pred otvorením konfigurácie VPN. Rozhoduje aj o tom, ktorá z dvoch nasledujúcich častí sa vás týka, preto držte oba výsledky testu pri tikete. Hádanie tu stojí jedno servisné okno, pretože tunel, ktorý sa hlási ako up, vám nič nepovie o najväčšom pakete, ktorý cesta prijme.

Zvyšujte MTU cesty len tam, kde súhlasí každý skok

Jumbo rámce sú vlastnosťou end-to-end, nie nastavenie, ktoré zapnete na dvoch koncových bodoch, ktoré náhodou ovládate. Každý prepínač, router a odovzdanie u poskytovateľa na vonkajšej ceste sa musia zhodnúť na väčšej veľkosti a jeden skok 1,500 bajtov potichu zahodí paket, ktorý ste práve zväčšili. Zdvihnutie iba lokálneho rozhrania je klasická polovičná zmena, po ktorej tunel vyzerá pokazený, kým podklad potichu zahadzuje.

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

Zmeňte rozhranie, potom znova preverte tú istú cestu, skôr než zmeníte čokoľvek iné. Ak test stále zlyháva, vráťte zmenu pomocou ip link set dev eth1 mtu 1500 a prejdite na fragmentáciu namiesto hádky s poskytovateľom o linke, ktorá nie je vaša.

Použite fragmentáciu tunela, keď podklad nemôže rásť

Podporovaný mechanizmus fragmentácie pod vnútorným paketom umožňuje viacerým vonkajším paketom preniesť jeden vnútorný paket a protiľahlý koncový bod tunela ich zloží predtým, než odovzdá originál zásobníku. Voľba UDP fragment v Community OpenVPN je jednou implementáciou tej myšlienky a nie je to to isté ako bežná IP fragmentácia vonkajšieho paketu. Obaja peeri musia spúšťať verziu, ktorá formát podporuje, a dátová cesta musí byť tá, ktorú si myslíte: klienti OpenVPN 3 a jadrom zrýchlené dátové kanály majú rôzne limity, preto profil, ktorý funguje na jednom klientovi, môže na inom zlyhať.

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

Bežná vonkajšia fragmentácia je druhá možnosť a je tá slabšia. Routery IPv6 vôbec nefragmentujú preposielaný paket, takže príliš veľký vonkajší paket jednoducho zomrie a odosielateľ sa to dozvie len vtedy, ak príslušná správa ICMPv6 prežije cestu. Fragmenty tiež pozývajú filtrovanie a zosilnenie strát, preto to beriem ako záložné riešenie, nie ako plán.

Vonkajší nosič založený na toku obchádza otázku veľkosti segmentovaním vlastného toku bajtov a rekonštruovaný vnútorný paket môže mať stále 1,500 bajtov. Je to transportné rozhodnutie s vlastnou cenou, vrátane známeho správania TCP v TCP, preto ho urobte vedome a nie ako vedľajší efekt sporu o MTU.

Potvrďte, že vnútorný paket prichádza nezmenený

Overenie nie je úspešný handshake. Zachyťte na rozhraní tunela na oboch koncoch a porovnajte veľkosť a obsah paketu, ktorý aplikácia skutočne odoslala, s tým, čo prijala druhá strana.

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'

Ak záznam ukazuje plnovýrazný vnútorný paket na druhom konci, voľba prenosu funguje a zostáva ju zdokumentovať. Ak neukazuje nič, kým sa tunel hlási ako up, vonkajší paket sa niekde medzi koncovými bodmi zahadzuje, čo vás vráti k testu a nie k nastaveniam šifry.

Pred zatvorením tiketu zmeny doň zapíšte tri veci: nameraný vonkajší rozpočet, zvolený mechanizmus a príkaz, ktorý dokázal, že vnútorný paket prežil. Ďalší človek, ktorý sa dotkne tohto tunela, bude potrebovať všetky tri a žiadny z nich nemožno rekonštruovať len z konfiguračného súboru.