OpenVPN mssfix: de ce un client se blochează la transferuri mari

Un singur laptop se blochează la încărcările prin tunel, în timp ce fiecare alt dispozitiv de pe același server continuă să funcționeze. Acest model indică o singură cale, nu configurația serverului, și este intrarea obișnuită în întrebarea mssfix. Opțiunea poate ajuta, dar numai pentru conexiunile TCP pe care le rescrie efectiv. Cunoașterea sferei sale vă împiedică să modificați un server funcțional pentru a salva un singur client.

Ce rescrie opțiunea

mssfix editează dimensiunea maximă a segmentului anunțată în handshake-urile TCP care trec prin tunel, astfel încât partea care trimite să aleagă segmente care se încadrează în bugetul încapsulat. Acționează asupra handshake-ului, ceea ce înseamnă că o conexiune deschisă înainte de schimbare păstrează valoarea negociată.

Nu micșorează datagramele UDP și nu setează MTU-ul tunelului. Două probleme diferite produc același simptom: un expeditor TCP care ignoră limita căii și o cale care aruncă în tăcere pachete mari de orice dimensiune. mssfix tratează prima și nu face nimic pentru a doua.

Această distincție explică experimentele dezamăgitoare. Setarea unei valori mai mici pe o cale cu gaură neagră schimbă dimensiunea segmentului, dar nu și căderea care urmează, așa că transferul eșuează în alt punct.

Sfera este TCP în interiorul tunelului

Doar traficul TCP este rescris. O sesiune QUIC, un joc sau o aplicație care trimite datagrame UDP mari își păstrează propriile dimensiuni ale pachetelor, iar dacă acelea sunt transferurile care se blochează, corectarea aparține mai degrabă MTU-ului tunelului sau al căii. Citiți ce protocol folosește transferul care eșuează înainte de a recurge la o opțiune TCP, pentru că stratul greșit are propria corectare.

Și direcția contează. O setare a clientului afectează traficul pe care acel client îl trimite în tunel, în timp ce serverul acoperă fluxurile pe care le redirecționează către clienți. Dacă se blochează doar descărcările de intrare, valoarea din partea clientului nu este toată povestea.

Numărul și cuvântul-cheie nu sunt portabile

Versiunea comunitară a OpenVPN 2.6 acceptă un cuvânt-cheie opțional după valoare. Cu mtu, numărul descrie dimensiunea pachetului exterior, inclusiv antetele IP și UDP; fără el, argumentul urmează o altă convenție de calcul. Prin urmare, o linie copiată între versiuni nu descrie același buget de pachete. Consultați pagina de manual care însoțește compilarea pe care o rulați efectiv, în locul unui tutorial pentru altă versiune.

Sintaxa arată astfel:

mssfix 1400 mtu

Tratați 1400 ca pe un substituent, nu ca pe o recomandare pentru calea dumneavoastră. Deduceți valoarea din calea măsurată și din încapsularea folosită efectiv, și rețineți că clienții pe versiuni mai vechi sau alte implementări pot respinge sau reinterpreta cuvântul-cheie.

Confirmați mai întâi pe singurul client

Măsurați calea de la mașina care eșuează înainte de a schimba ceva. O sarcină utilă pe care calea o poate transporta fără fragmentare este numărul pe care îl căutați:

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

Prima sondă încape într-un pachet de 1500 de octeți după ce se adaugă cei 28 de octeți de antete. Dacă eșuează cu o eroare de fragmentare și cea mai mică reușește, dimensiunea utilizabilă este undeva între ele, iar suprasarcina tunelului se scade de sus.

Apoi repetați transferul care s-a blocat, pe o conexiune nouă, și comparați. Dacă singurul client se îmbunătățește în timp ce ceilalți rămân neatinși, ați găsit sfera problemei. Dacă toți clienții se blochează, valoarea din partea serverului este cea care trebuie revizuită. Niciunul dintre cele două rezultate nu justifică o schimbare pe hardware care nu a fost niciodată pe calea defectă.