Paginile se încarcă, dar încărcările se blochează pe un VPN: care cauză câștigă
O blocare care depinde de dimensiune se potrivește cu o defecțiune MTU a căii, dar și cu DNS, cu o limită a aplicației sau cu un tunel instabil. Patru observații decid care.
Paginile se încarcă, VPN-ul raportează conectarea, iar încărcarea unui fișier îngheață de fiecare dată în același punct. Patru explicații se potrivesc acestei descrieri: o problemă de dimensiune a pachetului, o problemă de rezolvare a numelor, o limită a aplicației și un tunel care se resetează continuu. Fiecare poate fi confirmată sau exclusă printr-o observație diferită, așa că decizia este alegerea testului corect, nu ghicirea cauzei.
Patru candidați și o singură formă
Începe cu forma defecțiunii, pentru că elimină cea mai mare parte a listei înainte de a deschide vreun instrument. O blocare care apare la o dimensiune constantă este o problemă de dimensiune până la proba contrarie. O blocare în puncte aleatorii este o problemă de pierdere sau de stabilitate. O defecțiune înainte de deschiderea conexiunii este o problemă de nume.
Al patrulea candidat este aplicația. Limitele de încărcare, expirările cererilor și plafoanele de dimensiune a corpului la proxy produc defecțiuni care din browser arată ca defecțiuni de rețea, și de obicei sosesc ca respingere, nu ca blocare.
Notează forma observată înainte de a testa ceva. „Se oprește la aproximativ același număr de octeți, de fiecare dată, cu tunelul activ” este un punct de plecare mult mai solid decât „încărcările nu funcționează”.
Apoi păstrează calea neschimbată în timpul testelor. Schimbarea ieșirii, a protocolului și a serverului simultan produce un rezultat pe care nu îl poți atribui niciunuia. O singură variabilă pe rulare, și notează-o.
Împarte dimensiunea în două înainte de a atinge politica
Cel mai ieftin discriminator este o sondă care variază un singur număr. Trimite pinguri fără fragmentare, cu dimensiune crescătoare, către destinație, încarcă un fișier pe care îl controlezi la același serviciu, apoi compară unde se oprește fiecare.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadPrima comandă raportează dacă un pachet de dimensiune completă trece deloc de cale. La un MTU de 1500 de octeți, cea mai mare încărcătură ICMP care nu este fragmentată este de 1472 de octeți, iar un tunel ia și mai mult din acest buget înainte ca pachetul interior să înceapă. A doua îți dă o dimensiune și o durată pentru un transfer la nivel de aplicație, și acesta este numărul care contează cu adevărat.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
Citește perechea împreună. Sonde care eșuează peste un prag și o încărcare care se oprește aproape de același prag formează o poveste coerentă. Sonde care reușesc toate în timp ce încărcarea se blochează la un număr de octeți pe care calea îl transportă clar indică aplicația sau serverul, și nicio lucrare la MTU nu va schimba asta. Acel rezultat negativ valorează cât unul pozitiv. Elimină ramura cea mai scumpă a investigației.
Apoi verifică stabilitatea în timpul transferului, pentru că un tunel care reînnoiește cheia la mijlocul unei încărcări mari produce o defecțiune care pare dependentă de dimensiune fără să fie. Citirea timpului de funcționare este cea mai ieftină cale de a confirma asta.
Alege între o reparație și o soluție provizorie
Dacă dovezile indică dimensiunea, există două răspunsuri oneste și unul necinstit. Cele oneste sunt să restaurezi descoperirea MTU a căii permițând feedbackul ICMP necesar, sau să limitezi dimensiunea anunțată a segmentului pentru ca partenerii să trimită segmente mai mici. Cel necinstit este să scazi MTU-ul unei interfețe la o valoare copiată de pe un forum și să nu verifici niciodată ce a schimbat.
Alegerea depinde de ce controlezi. Într-o rețea pe care o administrezi, permiterea mesajelor ICMP este corectura mai curată, pentru că menține mecanismul funcțional pentru fiecare protocol. Pe o cale pe care nu o controlezi, limitarea este opțiunea practică, și ar trebui aplicată îngust, nu pe tot serverul.
Dacă dovezile indică aplicația, repară aplicația sau configurația ei de proxy. Un răspuns 413 și o conexiune blocată sunt defecțiuni diferite, iar a doua este de obicei o expirare undeva într-un lanț care include un proxy cu propriile limite.
În orice caz, păstrează valorile originale și testează din nou după revenire. O schimbare care coincide cu un transfer reușit nu este dovada că l-a cauzat, iar capacitatea de a o anula este ce desparte un diagnostic de o coincidență.
Notează decizia ca să supraviețuiască următorului incident
Patru fapte sunt suficiente: forma observată a defecțiunii, rezultatele sondelor, schimbarea pe care ai făcut-o și rezultatul retestării. Cu ele, următoarea persoană poate spune dacă problema este aceeași sau una nouă cu același simptom.
Notează și contextul căii, pentru că o constatare de MTU este specifică unei legături. Un laptop care funcționează acasă și eșuează într-un hotel are două căi, iar o corectură aplicată uneia nu spune nimic despre cealaltă.
În final, rezistă rezumatului că „VPN-ul a stricat încărcările”. Tunelul era prezent atât în cazul funcțional, cât și în cel eșuat; ce s-a schimbat a fost dimensiunea pachetului pe care calea trebuia să îl transporte, sau locul unde transferul a fost oprit. Numirea mecanismului real este ce face nota utilă.