Siden lade, mar uploads blokkearje op in VPN: hokker oarsaak wint
In blokkade dy't fan de grutte ôfhinget, past by in MTU-flater fan it paad, en ek by DNS, in beheining fan de applikaasje of in wyngeljende tunnel. Fjouwer waarnimmings beslisse hokker.
Siden lade, de VPN meldt ferbûn, en in bestânsupload befriest elke kear op itselde punt. Fjouwer ferklearrings passe by dy beskriuwing: in probleem mei pakketgrutte, in probleem mei nammebepaling, in beheining fan 'e applikaasje en in tunnel dy't hieltyd wer opnij set. Elk fan dy kin mei in oare waarnimming befêstige of útsletten wurde, dus de beslissing is in kwestje fan de juste test kieze ynstee fan de oarsaak riede.
Fjouwer kandidaten en ien foarm
Begjin mei de foarm fan 'e flater, want dy skrast it grutste part fan 'e list fuort foardat elk helpmiddel iepene wurdt. In blokkade by in konstante grutte is in grutteprobleem oant it tsjinoerstelde bewiisd is. In blokkade op tafalige punten is in ferlies- of stabiliteitsprobleem. In flater foardat de ferbining iepene wurdt is in nammerprobleem.
De fjirde kandidaat is de applikaasje. Uploadbeheiningen, tiidlimits fan oanfragen en maxima foar lichemsgrutte by de proxy meitsje flaters dy't fan 'e browser ôf op netwurkflaters lykje, en se komme meastentiids as in ôfwizing ynstee fan in hingjen.
Skriuw de waarnommen foarm op foardatst wat testest. "Stoppet by likernôch itselde byte-oantal, elke kear, mei de tunnel omheech" is in folle sterker útgongspunt as "uploads wurkje net".
Hâld dan it paad fêst wylstst testest. It feroarjen fan 'e útgong, it protokol en de tsjinner tagelyk jout in resultaat datst oan gjinien fan dy taskriuwe kinst. Ien fariabele per rint, en skriuw dy op.
Healje de grutte foardatst oan belied komst
De bêste ûnderskieder is in probe dy't ien getal feroaret. Stjoer ping-s fan tanimmende grutte sûnder fragmintaasje nei de bestimming, en upload in bestân datst behearskest nei deselde tsjinst, en fergelykje dan wêr't elk stoppet.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadIt earste kommando rapportearret oft in pakket fan folsleine grutte it paad hielendal oerlibbet. By in MTU fan 1500 bytes is de grutste ICMP-lading dy't net fragmintearret 1472 bytes, en in tunnel nimt noch mear fan dat budzjet foardat it binnenste pakket begjint. It twadde jout dy in grutte en in doer foar in oerdracht op applikaasjenivo, en dat is it getal dat echt fan belang is.
| 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 |
Lês it pear tegearre. Probes dy't boppe in drompel misse en in upload dy't tichtby deselde drompel stoppet, is in gearhingjend ferhaal. Probes dy't allegear slagje wylst de upload blokkearret by in byte-oantal dat it paad dúdlik draacht, wize op 'e applikaasje of de tsjinner, en gjin inkele MTU-arbeid sil dat feroarje. Dat negative resultaat is likefolle wurdich as in posityf. It hellet de djoerste tûke fan it ûndersyk fuort.
Kontrolearje dan de stabiliteit by de oerdracht, want in tunnel dy't yn 'e midden fan in grutte upload de kaai fernijt, makket in flater dy't grutte-ôfhinklik liket sûnder it te wêzen. It uptime-lêzen is de bêste manier om dat te befêstigjen.
Kies tusken in reparaasje en in omwei
As it bewiis op grutte wiist, binne der twa earlike antwurden en ien ûnearlike. De earlike binne it werstellen fan paad-MTU-ûntdekking troch de nedige ICMP-feedback ta te stean, of it beheinen fan 'e oankundige segmintgrutte sadat partners lytsere segminten stjoere. De ûnearlike is it ferleegjen fan in ynterface-MTU nei in wearde dy't fan in foarum kopyeare is en nea te kontrolearjen wat it feroare hat.
De kar hinget ôf fan watst behearskest. Op in netwurk datst beheart, is it tastean fan 'e ICMP-berjochten de skjinere reparaasje, want it hâldt it meganisme foar elk protokol wurkjend. Op in paad datst net behearskest, is beheinen de praktyske opsje, en it moat smel tapast wurde ynstee fan op 'e hiele tsjinner.
As it bewiis op 'e applikaasje wiist, reparearje de applikaasje of syn proxy-konfiguraasje. In 413-antwurd en in hinge ferbining binne ferskillende flaters, en it twadde is meastentiids in tiidlimit earne yn in keatling dy't in proxy mei eigen grinzen befettet.
Hoe dan ek, hâld de oarspronklike wearden en test opnij nei it weromdraaien. In feroaring dy't gearfalt mei in wurkjende oerdracht is gjin bewiis dat dy it feroarsake hat, en it fermogen om werom te draaien is wat in diagnoaze fan in tafal skiedt.
Skriuw de beslissing op sadat dy it folgjende ynsidint oerlibbet
Fjouwer feiten binne genôch: de waarnommen flaterfoarm, de resultaten fan 'e probes, de feroaring dy'tst makke hast en it resultaat fan 'e werhellingstest. Dêrmei kin de folgjende persoan sjen oft it probleem itselde is of in nij ien mei itselde symptoom.
Notearje ek de paadkontekst, want in MTU-befining is spesifyk foar in keppeling. In laptop dy't thús wurket en yn in hotel mist, hat twa paden, en in reparaasje tapast op ien fan dy seit neat oer de oare.
Ta beslút, wjerstean de gearfetting dat "de VPN de uploads brutsen hat". De tunnel wie oanwêzich yn sawol it wurkjende as it missende gefal; wat feroare wie de grutte fan it pakket dat it paad drage moast, of wêr't de oerdracht stoppe waard. It neamen fan it wiere meganisme is wat de notysje nuttich makket.