Miért akad meg a VPN a nagy átviteleknél, a kicsiknél pedig nem
A kis kérések válaszolnak, a nagy átvitelek lefagynak. Hasonlítsa össze az interfész korlátját, az útvonal korlátját és a meghirdetett TCP terhet, mielőtt fix MTU-t másol.
Egy oldal betöltődik, egy ping sikerül, és a fájlmásolás minden alkalommal ugyanannál a pontnál akad meg. Ez a minta a csomagméretre utal, nem a sávszélességre vagy a hitelesítő adatokra. A beágyazás bájtokat ad minden csomaghoz, ezért egy hasznos teher, amely az eredeti útvonalon elfért, a csatornán átjutva túllépheti a határt. Ezekben a beszélgetésekben három különböző számot neveznek MTU-nak, és összekeverésük olyan beállításhoz vezet, amely az egyik alkalmazást megjavítja, a másikat elrontja.
Három szám, amit az emberek MTU-nak neveznek
Az interfész MTU az adott kapcsolaton beállított csomagkorlát. Az útvonal MTU a legkisebb korlát az útvonal mentén, és felderítik, nem beállítják. A TCP MSS az a hasznos teherméret, amelyet a partner fogadhatónak jelent be, és a másik kettőből származik, nem külön fizikai korlát.
A csatornának belső és külső nézete van. A külső csomag a beágyazottat és a protokoll által igényelt fejléceket szállítja, ezért a használható belső méret kisebb annál, mint amit a külső útvonal enged. A VPN-kiszolgálóhoz vezető útvonal is eltér a kiszolgáló célig vezető útvonalától.
Az útvonal-MTU felderítése lehetővé teszi a küldő számára a működő méret megismerését, de függ attól, hogy megérkezik-e a visszajelzés. Amikor egy köztes eszköz szűri a vonatkozó ICMP-üzeneteket, a küldő továbbra is olyan csomagokat küld, amelyek soha nem fejeződnek be, és ez a klasszikus fekete lyuk. A tünet jellegzetes, ha ismerjük: a kézfogás sikerül, az első teljes méretű teher eltűnik, és a kapcsolat végül alaphelyzetbe áll vagy megakad. Semmi sem úgy néz ki az alkalmazás naplójában, mint egy hálózati probléma.
Vizsgálja meg az útvonalat az Ön által vezérelt teherrel
A próba egy útvonalról és egy méretről szóló bizonyíték, nem javasolt beállítás. Használjon válaszoló gazdagépet, és csak a teher méretét változtassa.
ping -M do -s 1372 -c 2 203.0.113.20 ping -4 -f -l 1372 vpn.example
Az első parancs Linux-próbát küld kikapcsolt töredezés mellett 1372 bájtos teherrel, a második pedig ugyanezt teszi Windowson, ahol a terhet a -l állítja be. A válasz azt jelenti, hogy ez a méret átjutott az útvonalon. A töredezés szükségességéről szóló üzenet informatív, míg az időtúllépés kétértelmű, mert a gazdagép vagy egy köztes eszköz egyszerűen eldobhatja az ICMP-t.
Néhány lépésben csökkentse a méretet, ne bájtra pontos bináris kereséssel. Azt próbálja megállapítani, hogy létezik-e méretplafon, nem pedig számot közzétenni minden hálózatra. A talált szám erre az útvonalra, erre a protokollra és erre a címcsaládra érvényes.
Az IPv4 és az IPv6 eltérően töredezik, ezért az egyik családból származó próbaeredmény semmit sem mond a másikról. Tesztelje azt a családot, amelyet az alkalmazás ténylegesen használ.
Az MSS-szorítás csak a TCP-nek segít
A TCP-nél a tényleges terhet a kézfogás során tárgyalják meg, és az útvonalon lévő útválasztó ezt az értéket lefelé átírhatja, hogy mindkét végpont kisebb szegmenseket küldjön. Ezt teszi az MSS-szorítás, és úgy működik, hogy a klienst egyáltalán nem érinti.
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu ip link show tun0
Az első szabály a meghirdetett MSS-t az útvonal-MTU-hoz szorítja a továbbított TCP-kézfogásoknál, a második pedig az alagút-interfész saját MTU-ját mutatja, hogy összevesse azzal, amit az útvonal enged. A szorítás a legkevésbé invazív javítás egy olyan TCP-alkalmazásnál, amely a kézfogás után megakad.
UDP esetén semmit sem tesz. Egy nagy adatgramokat küldő hang- vagy játék-kliens teljesen figyelmen kívül hagyja az MSS-beállítást, mert nincs mit átírni kézfogás nélkül. Ha a hibázó alkalmazás UDP-t használ, nézze meg inkább a kliens saját csomagméret-beállításait. A két protokoll eltérően hibázik és különböző eszközökkel javítható, ezért a protokoll a jegy első mondatába tartozik.
OpenVPN olyan opciókat kínál, mint a tun-mtu, a mssfix és a töredezéssel kapcsolatos beállítások, és viselkedésük a verziótól és attól függ, hogy az adatcsatorna AEAD-e. Olvassa el a használt verzió kézikönyvét, és egyszerre egy opciót változtasson.
Változtasson egy támogatott beállítást, és ismételje meg mindkét futást
Tartsa meg az eredeti profilt, változtasson egyetlen támogatott értéket, és ismételje meg a működő kicsi kérést és a hibázó nagy átvitelt is. Ha csak a nagy változik, a méretet kergette. Ha mindkettő változik, valami más is elmozdult vele.
Az alacsonyabb érték enyhítheti a tünetet, miközben többletterhet ad, ezért nem a lehető legkisebb szám a cél. A cél egy méret, amelyet az útvonal megbízhatóan, a legkevesebb pazarlással szállít. Jegyezze fel az értéket, az útvonalat és a kliens verzióját a jegybe, mert ugyanazt a számot máshol alkalmazni találgatás.
Ha ugyanaz a profil egy másik megbízható hálózatról működik, tartsa meg ezt a különbséget a diagnózisban, ahelyett hogy a klienst javítottnak nyilvánítja. A megváltozott változó az útvonal, és az útvonal az, amit a próba mért.