De ce un VPN se blochează la transferurile mari, dar nu la cele mici
Cererile mici primesc răspuns, iar transferurile mari îngheață. Comparați limita interfeței, limita căii și sarcina utilă TCP anunțată înainte de a copia un MTU fix.
O pagină se încarcă, un ping reușește, iar copierea unui fișier se blochează de fiecare dată în același punct. Acest model indică dimensiunea pachetului, nu lățimea de bandă sau datele de autentificare. Încapsularea adaugă octeți la fiecare pachet, așa că o sarcină utilă care încăpea pe calea inițială poate depăși limita după ce trece printr-un tunel. În aceste discuții trei numere diferite se numesc MTU, iar confundarea lor duce la o setare care repară o aplicație și o strică pe alta.
Trei numere pe care oamenii le numesc MTU
MTU al interfeței este limita configurată pentru un pachet pe acea legătură. MTU al căii este cea mai mică limită de-a lungul rutei și se descoperă în loc să fie configurată. TCP MSS este dimensiunea sarcinii utile pe care un partener declară că o poate primi, și derivă din celelalte două în loc să fie o limită fizică separată.
Un tunel are o vedere interioară și una exterioară. Pachetul exterior transportă pachetul încapsulat plus antetele de care are nevoie protocolul, deci dimensiunea interioară utilizabilă este mai mică decât permite calea exterioară. Calea către serverul VPN este și ea diferită de calea serverului către destinație.
Descoperirea MTU a căii permite expeditorului să afle dimensiunea care funcționează, dar depinde de sosirea feedback-ului. Când un dispozitiv intermediar filtrează mesajele ICMP relevante, expeditorul continuă să trimită pachete care nu se finalizează niciodată, iar aceasta este gaura neagră clasică. Simptomul este distinct odată ce îl cunoști: handshake-ul reușește, prima sarcină utilă de dimensiune completă dispare, iar conexiunea sfârșește prin a se reseta sau bloca. Nimic din jurnalul aplicației nu arată ca o problemă de rețea.
Sondați calea cu o sarcină utilă pe care o controlați
Un test este o dovadă despre o singură rută și o singură dimensiune, nu o setare recomandată. Folosiți o gazdă care răspunde și variați doar dimensiunea sarcinii utile.
ping -M do -s 1372 -c 2 203.0.113.20 ping -4 -f -l 1372 vpn.example
Prima comandă trimite o sondă Linux cu fragmentarea dezactivată și o sarcină utilă de 1372 octeți, iar a doua face la fel în Windows, unde sarcina utilă se setează cu -l. Un răspuns înseamnă că acea dimensiune a supraviețuit căii. Un mesaj că fragmentarea este necesară este informativ, în timp ce un timeout este ambiguu pentru că gazda sau un dispozitiv intermediar pot pur și simplu să arunce ICMP.
Coborâți dimensiunea în câțiva pași în loc de o căutare binară până la octet. Încercați să stabiliți dacă există un plafon de dimensiune, nu să publicați un număr pentru fiecare rețea. Numărul găsit se aplică acestei căi, acestui protocol și acestei familii de adrese.
IPv4 și IPv6 fragmentează diferit, așa că rezultatul unei familii nu spune nimic despre cealaltă. Testați familia pe care aplicația o folosește efectiv.
Limitarea MSS ajută doar TCP
În TCP, sarcina utilă efectivă este negociată în timpul handshake-ului, iar un router de pe cale poate rescrie acea valoare în jos pentru ca ambele capete să trimită segmente mai mici. Asta face limitarea MSS și funcționează fără să atingă clientul deloc.
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu ip link show tun0
Prima regulă limitează MSS anunțat la MTU al căii pentru handshake-urile TCP redirecționate, iar a doua arată MTU propriu al interfeței tunelului ca să îl comparați cu ce permite calea. Limitarea este reparația cea mai puțin invazivă pentru o aplicație TCP care se blochează după handshake.
Pentru UDP nu face nimic. Un client de voce sau de jocuri care trimite datagrame mari va ignora complet o setare MSS, pentru că nu există handshake de rescris. Dacă aplicația care eșuează este UDP, priviți în schimb opțiunile de dimensiune a pachetului ale clientului. Cele două protocoale eșuează diferit și se repară cu instrumente diferite, de aceea protocolul aparține primei propoziții din tichet.
OpenVPN expune opțiuni precum tun-mtu, mssfix și setări legate de fragmentare, iar comportamentul lor depinde de versiune și de dacă canalul de date este AEAD. Citiți manualul pentru versiunea folosită și schimbați o singură opțiune o dată.
Schimbați o singură setare acceptată și repetați ambele rulări
Păstrați profilul original, schimbați o singură valoare acceptată și repetați atât cererea mică ce funcționa, cât și transferul mare care eșua. Dacă se schimbă doar cel mare, urmăreați dimensiunea. Dacă se schimbă ambele, altceva s-a mișcat împreună cu ea.
O valoare mai mică poate reduce simptomul adăugând cost suplimentar, deci cel mai mic număr posibil nu este scopul. Scopul este o dimensiune pe care calea o duce fiabil cu cea mai mică risipă. Notați valoarea, calea și versiunea clientului în tichet, pentru că același număr aplicat altundeva este o presupunere.
Dacă același profil funcționează dintr-o altă rețea de încredere, păstrați diferența în diagnostic în loc să declarați clientul reparat. Variabila care s-a schimbat este calea, iar calea este ce a măsurat sonda.