De ce paginile OpenConnect se blochează până când scazi MTU-ul tunelului

Autentificarea reușește, pagina principală a portalului se randează, iar apoi un widget de panou sau un raport rămâne pe waiting for host până când browserul renunță. Site-urile publice se încarcă normal tot timpul, și nicio acreditare nu s-a schimbat. Faptul că răspunsurile mici ajung în timp ce cele mari se blochează este semnătura unui plafon de dimensiune a pachetului, nu a unei reguli de acces. Confirmă această interpretare înainte de a modifica orice altceva în profil.

Separă o problemă de dimensiune de o problemă de politică

Începe prin a exclude un refuz. Dacă gateway-ul te-ar fi refuzat, conexiunea ar fi eșuat imediat în loc să încarce o pagină pe jumătate. Un tunel care urcă și apoi se blochează doar la transferurile mai mari îți spune că calea exterioară nu poate duce pachetul interior.

Mecanismul este încapsularea. Fiecare pachet interior primește anteturi de tunel, așa că o încărcătură care încăpea în legătura fizică devine un pachet exterior care nu mai încape, iar tot ce poartă bitul do-not-fragment este aruncat fără un răspuns pe care browserul să îl poată interpreta.

Măsoară plafonul cu sonde do-not-fragment

Măsoară plafonul în loc să îl ghicești. Trimite sonde care refuză fragmentarea și scade încărcătura pas cu pas până când vine un răspuns, începând cu o comandă precum ping -M do -s 1472 host. Un răspuns care se plânge că e nevoie de fragmentare în timp ce DF este setat înseamnă că valoarea este încă prea mare. Repetă la 1462, apoi la 1452, și oprește-te la prima dimensiune care răspunde. Notează numărul împreună cu gazda pe care ai testat-o, pentru că răspunsul aparține acelei căi și nu protocolului în general.

Testează adresa către care tunelul trimite efectiv trafic. O sondă exterioară către numele public al gateway-ului și o sondă interioară către un server intern măsoară salturi diferite, iar filtrarea ICMP pe oricare dintre ele poate face o cale sănătoasă să pară stricată.

Aplică valoarea pe dispozitivul tunelului

Aplică rezultatul pe interfața creată de client, nu pe adaptorul Wi-Fi. La un client Linux aceasta este ip link set dev tun0 mtu 1300 urmată de ip link show tun0 pentru a confirma că valoarea a fost preluată. Folosește numele de dispozitiv pe care îl raportează clientul, pentru că variază în funcție de implementare și de modul în care a fost construit tunelul.

Scăderea MTU-ului tunelului micșorează încărcătura pe care o duce fiecare pachet, așa că debitul scade puțin, și acesta este prețul pentru a nu arunca răspunsurile mari într-o gaură neagră. Un număr mai mic nu este automat mai sigur. Schimbarea adaptorului fizic în schimb împrăștie paguba pe fiecare conexiune de pe acea legătură, în timp ce pachetele interioare supradimensionate rămân la fel de mari.

Folosește mai întâi cererile MTU ale clientului însuși

Când controlezi invocarea, clientul poate cere o dimensiune în loc să fie corectat după aceea. --mtu cere serverului o MTU de tunel, iar --base-mtu declară MTU-ul căii de dedesubt ca gateway-ul să poată deriva cifra tunelului. Ambele sunt cereri, iar manualul clientului nu promite că gateway-ul va onora vreuna dintre ele.

Această distincție stabilește ordinea de lucru. Încearcă mai întâi cererea și inspectează interfața pe care o produce, apoi revino la setarea locală a dispozitivului dacă valoarea aleasă de gateway încă se blochează.

Verifică cu transferul care a eșuat, apoi fă-l permanent

O modificare locală de ip link ține până când clientul reconstruiește tunelul, ceea ce se întâmplă la următoarea reconectare sau reluare. Pune valoarea acolo unde începe conexiunea: un wrapper care rulează clientul și apoi ajustează dispozitivul, o unitate systemd cu un pas ExecStartPost, sau opțiunea clientului când gateway-ul o acceptă. Ține-o lângă profil în controlul versiunilor, ca următoarea persoană să vadă de ce este numărul acolo.

Testează cu cererea care a eșuat, nu cu pagina principală. Deschide raportul, descarcă atașamentul sau rulează aducerea din depozit care s-a blocat, și notează exact unde se oprește dacă încă se oprește. O pagină care se randează după modificare dovedește puțin, pentru că se randa și înainte.

Dacă același transfer se blochează în același punct, teoria MTU nu este dovedită. Capturează traficul pe tunel și verifică ce parte se oprește din trimis înainte de a schimba din nou numărul, și ține valoarea anterioară notată ca revenirea să rămână o singură comandă.