Pingul prin VPN funcționează, dar site-ul se blochează: verificați dimensiunea
Un răspuns de ecou mic nu testează nici un ascultător TCP, nici un transfer mare. Separați politica de acces de dimensiunea pachetului înainte de a reduce MTU-ul unui tunel.
Răspunsurile de ecou sosesc, desktopul la distanță funcționează, iar browserul rămâne pe o pagină goală până când renunță. Două explicații se potrivesc acestui model, și nu sunt variante ale aceleiași probleme: o politică ce nu a permis niciodată serviciul, sau pachete care nu mai încap atunci când transferul crește. Răspunsul de ecou nu exclude niciuna.
Mergeți de la cea mai mică întrebare la cea mai mare și notați ce a dovedit de fapt fiecare pas.
Un răspuns de ecou răspunde la o întrebare mult mai mică
Un răspuns de ecou spune că stiva IP a destinației a răspuns la o cerere ICMP din sursa dumneavoastră. Nu spune nimic despre existența unui ascultător TCP pe portul de care aveți nevoie, despre faptul că o politică permite acel port sau despre faptul că gazda de destinație filtrează traficul independent de gateway. Un gateway care permite un serviciu poate elimina altul în timp ce ambele ținte răspund la ping. Citiți răspunsul ca un singur fapt despre un singur pachet și o singură direcție.
Confirmați destinația și portul serviciului înainte de a interpreta orice altceva. Adresa pe care ați testat-o și adresa pe care o folosește aplicația sunt uneori înregistrări diferite, iar un nume care se rezolvă la două adrese face acest lucru probabil.
Aflați dacă conexiunea a început
O conexiune refuzată imediat este un răspuns al ascultătorului sau al politicii: ceva a răspuns și a spus nu. O conexiune care se deschide și apoi se blochează când datele încep să circule indică dimensiunea. O conexiune care nu finalizează deloc strângerea de mână este de obicei o problemă de politică sau de rutare și arată ca un timeout, nu ca un refuz.
curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'
Notați care dintre cele trei cazuri l-ați observat înainte de a atinge setările MTU. Schimbarea dimensiunii tunelului pentru a repara o conexiune refuzată irosește schimbarea și ascunde cauza reală o vreme.
Măsurați dimensiunea cu un număr declarat
Când blocajul apare sub sarcină, testați o dimensiune de pachet cu bitul de interdicție a fragmentării setat și declarați aritmetica pentru ca rezultatul să însemne ceva. În Linux cu iputils, o încărcătură utilă de 1392 de octeți plus antetul ICMP de 8 octeți și antetul IPv4 de 20 de octeți produce un pachet interior de exact 1420 de octeți. Declarați această aritmetică în tichet, pentru că un ping gol care ajunge la gateway nu dovedește nimic despre o aplicație.
ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10
Ambele sonde sunt puncte de măsurare, nu recomandări de dimensiune a tunelului. Dacă ICMP este filtrat oriunde pe traseu, un timeout nu vă spune nimic despre dimensiune, pentru că filtrarea și un pachet prea mare arată la fel din partea clientului. Un succes nu spune nimic nici despre direcția inversă sau despre altă destinație.
Țineți cont de traseul exterior
Încapsularea adaugă propriile anteturi, așa că pachetul de pe fir este mai mare decât pachetul pe care l-ați măsurat în interiorul tunelului. Exact diferența dintre cele două face posibile simultan o cerere mică funcțională și una mare care eșuează.
Descoperirea MTU a traseului în IPv4 depinde de feedback despre pachete care nu pot fi înaintate fără fragmentare, iar IPv6 folosește mesaje Packet Too Big. Specificația IPv4 descrie acel mecanism. Filtrarea feedback-ului distruge capacitatea expeditorului de a învăța și îl lasă să retrimită pachete care nu vor încăpea niciodată. De aceea o cerere mică funcțională și una mare care eșuează coexistă atât de confortabil.
Schimbați un număr și retestați aplicația
Reduceți MTU-ul tunelului sau limitați dimensiunea maximă a segmentului pentru TCP, apoi repetați testul original al aplicației în locul sondei. O sondă care reușește după schimbare și o aplicație care încă se blochează sunt o problemă diferită cu o formă asemănătoare, și doar testul aplicației le distinge.
Păstrați aritmetica în înregistrarea schimbării: dimensiunea măsurată, suprasarcina presupusă și valoarea setată. Oricine o va revizui mai târziu poate verifica presupunerea în loc să o deducă din nou dintr-o captură de ecran a unui ping.
Dacă aplicația funcționează la fiecare dimensiune încercată, opriți ajustarea numerelor și priviți politica ce separă serviciul funcțional de cel care eșuează.