OpenVPN mssfix: miért akad meg egy kliens a nagy átvitelnél

Egyetlen laptop akad meg a feltöltéseknél az alagúton keresztül, miközben ugyanazon a szerveren minden más eszköz tovább működik. Ez a minta egy útra mutat, nem a szerver konfigurációjára, és ez a szokásos belépő az mssfix kérdésébe. A beállítás segíthet, de csak azoknál a TCP-kapcsolatoknál, amelyeket valóban átír. A hatókörének ismerete megóvja attól, hogy egy működő szervert módosítson egyetlen kliens megmentéséért.

Mit ír át a beállítás

Az mssfix szerkeszti az alagúton áthaladó TCP-kézfogásokban hirdetett maximális szegmensméretet, hogy a küldő fél akkora szegmenseket válasszon, amelyek beleférnek a beágyazott keretbe. A kézfogásra hat, ami azt jelenti, hogy a változtatás előtt megnyitott kapcsolat megtartja az egyeztetett értéket.

Nem zsugorítja az UDP-datagramokat, és nem állítja be az alagút MTU-ját. Két különböző probléma ugyanazt a tünetet okozza: egy TCP-küldő, amely figyelmen kívül hagyja az útvonal korlátját, és egy útvonal, amely csendben eldobja a nagy csomagokat bármilyen méretben. Az mssfix az elsőt kezeli, a másodikkal nem tesz semmit.

Ez a különbség magyarázza a kiábrándító kísérleteket. Ha egy fekete lyukas útvonalon kisebb értéket állítunk be, az megváltoztatja a szegmensméretet, de nem a következő dobást, ezért az átvitel más ponton hiúsul meg.

A hatókör az alagúton belüli TCP

Csak a TCP-forgalom íródik át. Egy QUIC-munkamenet, egy játék vagy egy nagy UDP-datagramokat küldő alkalmazás megtartja a saját csomagméreteit, és ha éppen ezek az átvitelek akadnak meg, a javítás inkább az alagút vagy az útvonal MTU-jához tartozik. Olvassa el, milyen protokollt használ a sikertelen átvitel, mielőtt TCP-beállításhoz nyúlna, mert a rossz rétegnek saját javítása van.

Az irány is számít. Egy kliensbeállítás a kliens által az alagútba küldött forgalomra hat, míg a szerver azokat a folyamokat fedi le, amelyeket a kliensek felé továbbít. Ha csak a bejövő letöltések akadnak meg, a kliens oldali érték nem a teljes történet.

A szám és a kulcsszó nem hordozható

Az OpenVPN 2.6 közösségi verziója elfogad egy opcionális kulcsszót az érték után. Az mtu kulcsszóval a szám a külső csomag méretét írja le az IP- és UDP-fejlécekkel együtt; nélküle az argumentum más számítási konvenciót követ. Ezért a verziók között másolt sor nem ugyanazt a csomagkeretet írja le. Nézze meg a kézikönyv oldalát, amely a ténylegesen futtatott buildhez tartozik, ne egy másik kiadás oktatóanyagát.

A szintaxis így néz ki:

mssfix 1400 mtu

Az 1400-at helyőrzőnek tekintse, nem az útvonalára vonatkozó javaslatnak. Az értéket a mért útvonalból és a ténylegesen használt beágyazásból vezesse le, és ne feledje, hogy a régebbi verziókon vagy más implementációkon lévő kliensek elutasíthatják vagy másként értelmezhetik a kulcsszót.

Először az egyetlen kliensen erősítse meg

Mérje meg az útvonalat a hibás gépről, mielőtt bármit módosítana. Az a hasznos teher, amelyet az útvonal töredezés nélkül el tud vinni, az a szám, amelyet keres:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

Az első próba egy 1500 bájtos csomagba fér bele, ha hozzáadjuk a 28 bájt fejlécet. Ha töredezési hibával meghiúsul, és a kisebb sikerül, a használható méret valahol a kettő között van, és az alagút többlete felülről levonódik.

Ezután ismételje meg az elakadt átvitelt egy új kapcsolaton, és hasonlítsa össze. Ha az egyetlen kliens javul, míg a többi érintetlen marad, megtalálta a probléma hatókörét. Ha minden kliens elakad, a szerver oldali értéket kell felülvizsgálni. A két eredmény egyike sem indokolja a változtatást olyan hardveren, amely soha nem volt a hibás útvonalon.