Paĝoj ŝargiĝas, sed alŝutoj haltas ĉe VPN: kiu kaŭzo venkas
Halto dependa de grando konvenas al MTU-misondo de la vojo, kaj ankaŭ al DNS, limo de la aplikaĵo aŭ svingiĝanta tunelo. Kvar observoj decidas, kiu.
Paĝoj ŝargiĝas, la VPN raportas konekton, kaj dosiera alŝuto frostas ĉiufoje ĉe la sama punkto. Kvar klarigoj konvenas al tiu priskribo: problema paketa grando, problema nomrezolucio, limo de la aplikaĵo kaj tunelo, kiu senĉese restartiĝas. Ĉiu el ili povas esti konfirmita aŭ ekskludita per malsama observo, do la decido temas pri elekti la ĝustan teston anstataŭ diveni la kaŭzon.
Kvar kandidatoj kaj unu formo
Komencu per la formo de la malsukceso, ĉar ĝi forigas la plejparton de la listo antaŭ ol malfermiĝas iu ajn ilo. Halto, kiu okazas ĉe konstanta grando, estas grando-problemo ĝis pruviĝos la malo. Halto ĉe hazardaj punktoj estas problemo de perdo aŭ stabileco. Malsukceso antaŭ ol malfermiĝas la konekto estas nomoproblemo.
La kvara kandidato estas la aplikaĵo. Alŝutaj limoj, tempolimoj de la petoj kaj supraj limoj de korpa grando ĉe la prokuro kreas malsukcesojn, kiuj aspektas kiel retaj misfunkcioj el la retumilo, kaj ili kutime alvenas kiel malakcepto anstataŭ kiel haltiĝo.
Skribu la observitan formon antaŭ ol testi ion ajn. „Haltas ĉe proksimume la sama bajta nombro, ĉiufoje, kun la tunelo supren“ estas multe pli forta deirpunkto ol „alŝutoj ne funkcias“.
Poste tenu la vojon fiksa dum vi testas. Ŝanĝi la eliron, la protokolon kaj la servilon samtempe donas rezulton, kiun vi ne povas atribui al iu ajn el ili. Unu variablo por unu kuro, kaj skribu ĝin.
Duonigu la grandon antaŭ ol tuŝi la politikon
La plej malmultekosta distingilo estas provo, kiu variigas unu nombron. Sendu pingojn sen fragmentado laŭ kreskanta grando al la celo, alŝutu dosieron, kiun vi kontrolas, al la sama servo, kaj poste komparu, kie ĉiu el ili haltas.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadLa unua komando raportas, ĉu plengranda paketo entute travivas la vojon. Ĉe MTU de 1500 bajtoj, la plej granda ICMP-ŝarĝo, kiu ne fragmentiĝas, estas 1472 bajtoj, kaj tunelo prenas pli el tiu buĝeto antaŭ ol la interna paketo komenciĝas. La dua donas al vi grandon kaj daŭron por transdono ĉe aplikaĵa nivelo, kaj tio estas la nombro, kiu vere gravas.
| 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 |
Legu la paron kune. Provoj, kiuj malsukcesas super sojlo, kaj alŝuto, kiu haltas apud la sama sojlo, estas kohera historio. Provoj, kiuj ĉiuj sukcesas dum la alŝuto haltas ĉe bajta nombro, kiun la vojo klare portas, indikas la aplikaĵon aŭ la servilon, kaj nenia MTU-laboro tion ŝanĝos. Tiu negativa rezulto valoras kiom pozitiva. Ĝi forigas la plej multekostan branĉon de la esploro.
Poste kontrolu stabilecon dum la transdono, ĉar tunelo, kiu renovigas la ŝlosilon meze de granda alŝuto, produktas malsukceson, kiu aspektas grando-dependa sen esti tia. La legado de la funkcia tempo estas la plej malmultekosta maniero konfirmi tion.
Decidu inter riparo kaj provizora solvo
Se la pruvoj indikas grandon, ekzistas du honestaj respondoj kaj unu malhonesta. La honestaj estas restarigi la malkovron de la voja MTU permesante la necesan ICMP-retrokuplon, aŭ fiksi la anoncitan segmentan grandon por ke la partneroj sendu pli malgrandajn segmentojn. La malhonesta estas malaltigi la interfacan MTU al valoro kopiita el forumo kaj neniam kontroli, kion ĝi ŝanĝis.
La elekto dependas de tio, kion vi kontrolas. En reto, kiun vi funkciigas, permesi la ICMP-mesaĝojn estas la pli pura riparo, ĉar ĝi konservas la mekanismon funkcianta por ĉiu protokolo. Sur vojo, kiun vi ne kontrolas, fiksado estas la praktika opcio, kaj ĝi aplikiĝu mallarĝe anstataŭ por la tuta servilo.
Se la pruvoj indikas la aplikaĵon, riparu la aplikaĵon aŭ ĝian prokuran agordon. Respondo 413 kaj pendanta konekto estas malsamaj malsukcesoj, kaj la dua kutime estas tempolimo ie en ĉeno, kiu inkluzivas prokuron kun propraj limoj.
Ĉiel ajn, konservu la originajn valorojn kaj retestu post la malfaro. Ŝanĝo, kiu koincidas kun funkcianta transdono, ne estas pruvo, ke ĝi kaŭzis ĝin, kaj la kapablo malfari estas tio, kio apartigas diagnozon de koincido.
Registru la decidon por ke ĝi postvivu la sekvan okazaĵon
Kvar faktoj sufiĉas: la observita malsukcesa formo, la rezultoj de la provoj, la ŝanĝo, kiun vi faris, kaj la rezulto de la retesto. Kun ili, la sekva persono povas diri, ĉu la problemo estas la sama aŭ nova kun la sama simptomo.
Notu ankaŭ la vojan kuntekston, ĉar MTU-trovo estas specifa por ligilo. Tekkomputilo, kiu funkcias hejme kaj malsukcesas en hotelo, havas du vojojn, kaj ripari unu el ili diras nenion pri la alia.
Fine, rezistu la resumon, ke „la VPN rompis la alŝutojn“. La tunelo ĉeestis kaj en la funkcianta kaj en la malsukcesa kazo; tio, kio ŝanĝiĝis, estis la grando de la paketo, kiun la vojo devis porti, aŭ la loko, kie la transdono estis haltigita. Nomado de la fakta mekanismo estas tio, kio faras la noton utila.