Faqet ngarkohen por ngarkimet bllokohen në VPN: cila shkak fiton
Një bllokim që varet nga madhësia përshtatet me një defekt MTU të rrugës, dhe gjithashtu me DNS, një kufi të aplikacionit ose një tunel të paqëndrueshëm. Katër vëzhgime vendosin cila.
Faqet ngarkohen, VPN raporton të lidhur, dhe ngarkimi i një skedari ngrin çdo herë në të njëjtën pikë. Katër shpjegime përshtaten me atë përshkrim: një problem i madhësisë së paketës, një problem i zgjidhjes së emrave, një kufi i aplikacionit dhe një tunel që rindërtohet vazhdimisht. Secili prej tyre mund të konfirmohet ose përjashtohet nga një vëzhgim tjetër, prandaj vendimi është zgjedhja e provës së duhur dhe jo hamendja e shkakut.
Katër kandidatë dhe një formë
Filloni me formën e dështimit, sepse ajo eliminon pjesën më të madhe të listës përpara se të hapet ndonjë mjet. Një bllokim që ndodh në një madhësi konstante është problem i madhësisë derisa të vërtetohet e kundërta. Një bllokim në pika të rastësishme është problem i humbjes ose i qëndrueshmërisë. Një dështim përpara se të hapet lidhja është problem emri.
Kandidati i katërt është aplikacioni. Kufijtë e ngarkimit, afatet e kërkesave dhe tavanet e madhësisë së trupit në proxy prodhojnë dështime që nga shfletuesi duken si defekte rrjeti, dhe zakonisht vijnë si refuzim dhe jo si bllokim.
Shënoni formën e vëzhguar përpara se të provoni çdo gjë. „Ndalohet afërsisht në të njëjtin numër bajtësh, çdo herë, me tunelin lart“ është një pikënisje shumë më e fortë sesa „ngarkimet nuk funksionojnë“.
Më pas mbajeni rrugën të pandryshuar gjatë provës. Ndryshimi i daljes, protokollit dhe serverit njëkohësisht jep një rezultat që nuk mund t'ia atribuosh asnjërit prej tyre. Një variabël për çdo ekzekutim, dhe shënoje.
Ndajeni madhësinë në dysh përpara se të prekni politikën
Diskriminuesi më i lirë është një provë që ndryshon një numër. Dërgoni ping pa fragmentim me madhësi në rritje drejt destinacionit, ngarkoni një skedar që ju kontrolloni në të njëjtin shërbim, pastaj krahasoni ku ndalon secili.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadKomanda e parë raporton nëse një paketë me madhësi të plotë e kalon rrugën fare. Me një MTU prej 1500 bajtësh, ngarkesa më e madhe ICMP që nuk fragmentohet është 1472 bajtë, dhe një tunel merr edhe më shumë nga ky buxhet përpara se të fillojë paketa e brendshme. E dyta ju jep një madhësi dhe një kohëzgjatje për një transferim në nivel aplikacioni, dhe ky është numri që ka vërtet rëndësi.
| 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 |
Lexojini të dyja së bashku. Provat që dështojnë mbi një prag dhe një ngarkim që ndalon pranë të njëjtit prag janë një histori koherente. Provat që të gjitha kalojnë ndërsa ngarkimi bllokohet në një numër bajtësh që rruga qartësisht mban tregojnë aplikacionin ose serverin, dhe asnjë punë me MTU nuk do ta ndryshojë atë. Ai rezultat negativ vlen sa një pozitiv. Ai heq degën më të shtrenjtë të hetimit.
Më pas kontrolloni qëndrueshmërinë gjatë transferimit, sepse një tunel që rinovon çelësin në mes të një ngarkimi të madh prodhon një dështim që duket i varur nga madhësia pa qenë i tillë. Leximi i kohës së funksionimit është mënyra më e lirë për ta konfirmuar.
Zgjidhni midis një riparimi dhe një shmangieje
Nëse provat tregojnë madhësinë, ka dy përgjigje të ndershme dhe një jo të ndershme. Të ndershmet janë të rivendoset zbulimi i MTU-së së rrugës duke lejuar reagimin e nevojshëm ICMP, ose të kufizohet madhësia e segmentit të shpallur që palët të dërgojnë segmente më të vogla. E pandershme është të ulësh MTU-në e një ndërfaqeje në një vlerë të kopjuar nga një forum dhe të mos verifikosh kurrë çfarë ndryshoi.
Zgjedhja varet nga ajo që ju kontrolloni. Në një rrjet që ju administroni, lejimi i mesazheve ICMP është rregullimi më i pastër, sepse e mban mekanizmin në punë për çdo protokoll. Në një rrugë që nuk e kontrolloni, kufizimi është opsioni praktik, dhe duhet të aplikohet ngushtë dhe jo në të gjithë serverin.
Nëse provat tregojnë aplikacionin, rregulloni aplikacionin ose konfigurimin e proxy-t të tij. Një përgjigje 413 dhe një lidhje e varur janë dështime të ndryshme, dhe e dyta është zakonisht një afat kohe diku në një zinxhir që përfshin një proxy me kufijtë e vet.
Në çdo rast, ruani vlerat origjinale dhe provoni përsëri pas kthimit. Një ndryshim që përkon me një transferim të suksesshëm nuk është provë se ai e shkaktoi, dhe aftësia për ta zhbërë është ajo që ndan diagnozën nga rastësia.
Regjistroni vendimin që të mbijetojë incidentin e radhës
Katër fakte mjaftojnë: forma e vëzhguar e dështimit, rezultatet e provave, ndryshimi që bëtë dhe rezultati i riprovës. Me to, personi tjetër mund të thotë nëse problemi është i njëjti ose një i ri me të njëjtin simptomë.
Shënoni edhe kontekstin e rrugës, sepse një gjetje MTU është specifike për një lidhje të caktuar. Një laptop që punon në shtëpi dhe dështon në hotel ka dy rrugë, dhe një rregullim i aplikuar në njërën nuk thotë asgjë për tjetrën.
Së fundi, kundërshtoni përmbledhjen se „VPN-ja prishi ngarkimet“. Tuneli ishte i pranishëm si në rastin që punonte ashtu edhe në atë që dështonte; ajo që ndryshoi ishte madhësia e paketës që rruga duhej të mbante, ose vendi ku transferimi u ndal. Emërtimi i mekanizmit të vërtetë është ajo që e bën shënimin të dobishëm.