Bladsye laai, maar oplaaiings hang op 'n VPN: watter oorsaak wen
'n Oponthoud wat van die grootte afhang, pas by 'n roete-MTU-fout, en ook by DNS, 'n toepassingsperk of 'n wankelende tonnel. Vier waarnemings besluit watter een.
Bladsye laai, die VPN sê dit is verbind, en 'n lêeroplaaiing vries elke keer op dieselfde punt. Vier verklarings pas by dié beskrywing: 'n pakketgrootteprobleem, 'n naamoplossingsprobleem, 'n toepassingsperk en 'n tonnel wat aanhou herstel. Elkeen kan deur 'n ander waarneming in of uit gesluit word, so die besluit is 'n kwessie van die regte toets kies eerder as om die oorsaak te raai.
Vier kandidate en een vorm
Begin met die vorm van die mislukking, want dit skakel die meeste van die lys uit voordat enige gereedskap oopgemaak word. 'n Oponthoud wat by 'n konsekwente grootte gebeur, is 'n grootteprobleem tot die teendeel bewys word. 'n Oponthoud wat op lukrake punte gebeur, is 'n verlies- of stabiliteitsprobleem. 'n Mislukking voordat die verbinding oopgaan, is 'n naamprobleem.
Die vierde kandidaat is die toepassing. Oplaaiperke, versoektydperke en proxy-liggaamsgroottebeperkings veroorsaak mislukkings wat vir die blaaier soos netwerkfoute lyk, en hulle kom gewoonlik as 'n verwerping eerder as 'n hang.
Skryf die waargenome vorm neer voordat jy enigiets toets. "Stop by ongeveer dieselfde greptelling, elke keer, met die tonnel op" is 'n veel sterker beginpunt as "oplaaiings werk nie".
Hou dan die pad vas terwyl jy toets. Om die uitgang, die protokol en die bediener op dieselfde tyd te verander, lewer 'n resultaat wat jy aan nie een van hulle kan toeskryf nie. Een veranderlike per lopie, en skryf dit neer.
Halveer die grootte voordat jy aan beleid raak
Die goedkoopste onderskeier is 'n ondersoek wat een getal verander. Stuur doen-nie-fragmenteer-pings van toenemende grootte na die bestemming, en laai 'n lêer wat jy beheer by dieselfde diens op, en vergelyk dan waar elkeen stop.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadDie eerste opdrag rapporteer of 'n volgrootte pakket die pad hoegenaamd oorleef. Op 'n MTU van 1500 grepe is die grootste ICMP-lading wat nie fragmenteer nie 1472 grepe, en 'n tonnel neem meer uit daardie begroting voordat die binnepakket begin. Die tweede gee jou 'n grootte en 'n duur vir 'n toepassingsvlak-oordrag, wat die getal is wat werklik saak maak.
| 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 |
Lees die paar saam. Ondersoeke wat bo 'n drempel misluk en 'n oplaaiing wat naby dieselfde drempel stop, is 'n samehangende verhaal. Ondersoeke wat almal slaag terwyl die oplaaiing by 'n greptelling vasval wat die pad duidelik dra, wys na die toepassing of die bediener, en geen hoeveelheid MTU-werk sal dit verander nie. Daardie negatiewe resultaat is net so veel werd as 'n positiewe een. Dit verwyder die duurste tak van die ondersoek.
Kontroleer dan stabiliteit tydens die oordrag, want 'n tonnel wat in die middel van 'n groot oplaaiing weer 'n sleutel opstel, veroorsaak 'n mislukking wat grootte-afhanklik lyk sonder om dit te wees. Die opstatydlesing is die goedkoopste manier om dit in te sluit.
Kies tussen 'n herstel en 'n noodoplossing
As die bewyse na grootte wys, is daar twee eerlike response en een oneerlike. Die eerlikes is om roete-MTU-ontdekking te herstel deur die nodige ICMP-terugvoer toe te laat, of om die geadverteerde segmentgrootte vas te klem sodat eweknieë kleiner segmente stuur. Die oneerlike is om 'n koppelvlak-MTU te verlaag na 'n waarde uit 'n forum gekopieer en nooit te verifieer wat dit verander het nie.
Die keuse hang af van wat jy beheer. Op 'n netwerk wat jy bedryf, is die toelaat van die ICMP-boodskappe die skoner oplossing omdat dit die meganisme vir elke protokol laat werk. Op 'n pad wat jy nie beheer nie, is vaslem die praktiese opsie, en dit moet smal toegepas word eerder as oor die hele bediener.
As die bewyse na die toepassing wys, herstel die toepassing of sy proxy-konfigurasie. 'n 413-antwoord en 'n hangende verbinding is verskillende mislukkings, en die tweede is gewoonlik 'n tydperk ergens in 'n ketting wat 'n proxy met sy eie perke insluit.
Hoe dit ook al sy, hou die oorspronklike waardes en toets weer na terugrol. 'n Verandering wat met 'n werkende oordrag saamval, is nie bewys dat die verandering dit veroorsaak het nie, en die vermoë om terug te draai is wat 'n diagnose van 'n toeval skei.
Teken die besluit aan sodat dit die volgende voorval oorleef
Vier feite is genoeg: die waargenome mislukkingsvorm, die ondersoekresultate, die verandering wat jy gemaak het en die hertoetsresultaat. Daarmee kan die volgende persoon sien of die probleem dieselfde een is of 'n nuwe een met dieselfde simptoom.
Merk ook die padkonteks, want 'n MTU-bevinding is spesifiek vir 'n skakel. 'n Skootrekenaar wat by die huis werk en by 'n hotel misluk, het twee paaie, en 'n oplossing wat op een daarvan toegepas is, sê niks oor die ander nie.
Weerstaan laastens die opsomming dat "die VPN oplaaiings gebreek het". Die tonnel was in beide die werkende en die mislukkende geval teenwoordig; wat verander het, was die grootte van die pakket wat die pad moes dra, of waar die oordrag gestop is. Om die werklike meganisme te benoem, is wat die nota nuttig maak.