Strani se naložijo, a pošiljanja na VPN se ustavijo: kateri vzrok zmaga
Zastoj, ki je odvisen od velikosti, ustreza napaki MTU poti, pa tudi DNS, omejitvi aplikacije ali nestabilnemu tunelu. Štiri opazovanja odločijo, kateri.
Strani se naložijo, VPN poroča o povezavi, pošiljanje datoteke pa se vsakič ustavi na istem mestu. Temu opisu ustrezajo štiri razlage: težava z velikostjo paketa, težava z razreševanjem imen, omejitev aplikacije in tunel, ki se nenehno ponastavlja. Vsako od njih je mogoče potrditi ali izključiti z drugim opazovanjem, zato je odločitev izbira pravega preizkusa in ne ugibanje vzroka.
Štirje kandidati in ena oblika
Začnite z obliko okvare, ker ta odstrani večino seznama, še preden odprete katero koli orodje. Zastoj, ki se pojavi pri stalni velikosti, je težava z velikostjo, dokler ni dokazano nasprotno. Zastoj na naključnih mestih je težava z izgubami ali stabilnostjo. Okvara pred odprtjem povezave je težava z imenom.
Četrti kandidat je aplikacija. Omejitve pošiljanja, časovne omejitve zahtev in zgornje meje velikosti telesa pri posredniku ustvarjajo okvare, ki so videti kot omrežne napake, in običajno pridejo kot zavrnitev, ne kot zastoj.
Zapišite opaženo obliko, preden karkoli preizkusite. „Ustavi se pri približno enakem številu bajtov, vsakič, ko je tunel vzpostavljen“ je veliko močnejše izhodišče kot „pošiljanje ne deluje“.
Nato med preizkušanjem ohranite pot nespremenjeno. Spreminjanje izhoda, protokola in strežnika hkrati da rezultat, ki ga ne morete pripisati nobenemu od njih. Ena spremenljivka na tek, in zapišite jo.
Razdelite velikost na pol, preden se dotaknete politike
Najcenejši razlikovalnik je preizkus, ki spremeni eno število. Na cilj pošljite ping s povečujočo se velikostjo in prepovedjo drobljenja, naložite datoteko, ki jo nadzorujete, na isto storitev in nato primerjajte, kje se vsak ustavi.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadPrvi ukaz sporoči, ali paket polne velikosti sploh preide pot. Pri MTU 1500 bajtov je največja koristna obremenitev ICMP, ki se ne razdeli, 1472 bajtov, tunel pa iz tega proračuna vzame še več, preden se notranji paket začne. Drugi vam da velikost in trajanje za prenos na ravni aplikacije, in to je število, ki resnično šteje.
| 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 |
Preberite oba skupaj. Preizkusi, ki ne uspejo nad pragom, in pošiljanje, ki se ustavi blizu istega praga, so smiselna zgodba. Preizkusi, ki vsi uspejo, medtem ko se pošiljanje ustavi pri številu bajtov, ki jih pot očitno prenaša, kažejo na aplikacijo ali strežnik, in nobeno delo z MTU tega ne bo spremenilo. Ta negativni rezultat je vreden toliko kot pozitivni. Odstrani najdražjo vejo preiskave.
Nato preverite stabilnost med prenosom, ker tunel, ki osveži ključ sredi velikega pošiljanja, povzroči okvaro, ki je videti odvisna od velikosti, pa ni. Odčitek časa delovanja je najcenejši način, da to potrdite.
Odločite se med popravilom in obhodom
Če dokazi kažejo na velikost, obstajata dva poštena odgovora in eden nepošten. Poštena sta obnoviti odkrivanje MTU poti z dovoljenjem potrebne povratne informacije ICMP ali omejiti objavljeno velikost segmenta, da partnerji pošiljajo manjše segmente. Nepošten je znižati MTU vmesnika na vrednost, prepisano s foruma, in nikoli ne preveriti, kaj je spremenila.
Izbira je odvisna od tega, kaj nadzorujete. V omrežju, ki ga upravljate, je dovoljenje sporočil ICMP čistejši popravek, ker ohranja mehanizem delujoč za vsak protokol. Na poti, ki je ne nadzorujete, je omejevanje praktična možnost, in uporabiti ga je treba ozko, ne na celem strežniku.
Če dokazi kažejo na aplikacijo, popravite aplikacijo ali njeno konfiguracijo posrednika. Odgovor 413 in obešena povezava sta različni okvari, druga pa je običajno časovna omejitev nekje v verigi, ki vključuje posrednika z lastnimi omejitvami.
V vsakem primeru obdržite prvotne vrednosti in po razveljavitvi znova preizkusite. Sprememba, ki sovpada z uspešnim prenosom, ni dokaz, da ga je povzročila, in možnost razveljavitve je tisto, kar loči diagnozo od naključja.
Zapišite odločitev, da bo preživela naslednji incident
Dovolj so štiri dejstva: opažena oblika okvare, rezultati preizkusov, sprememba, ki ste jo naredili, in rezultat ponovnega preizkusa. Z njimi lahko naslednja oseba pove, ali je težava ista ali nova z enakim simptomom.
Zabeležite tudi kontekst poti, ker je ugotovitev o MTU specifična za določeno povezavo. Prenosnik, ki doma deluje in v hotelu odpove, ima dve poti, popravek, uporabljen na eni, pa ne pove nič o drugi.
Nazadnje, uprite se povzetku, da je „VPN pokvaril pošiljanje“. Tunel je bil prisoten tako v delujočem kot v neuspešnem primeru; spremenila se je velikost paketa, ki ga je pot morala prenesti, ali mesto, kjer je bil prenos ustavljen. Poimenovanje dejanskega mehanizma je tisto, kar naredi zapisek uporaben.