Waarom misluk sommige webwerwe net wanneer die VPN aan is?

Een werf wat misluk terwyl die res laai, vernou die fout vinnig. Lees die fout, toets naamoplossing en vee dan pakketgrootte uit voordat jy aan die kliënt raak.

Dat een werf misluk terwyl alles anders laai, bewys dat die tonnel verkeer dra, wat die probleem meer vernou as wat die meeste mense verwag. Drie waarnemings sorteer die res: of jy hoegenaamd 'n HTTP-antwoord gekry het, of die gasheernaam na 'n adres opgelos is, en of klein versoeke deurkom terwyl grootes vassteek. Om na die VPN te raai voordat jy daardie antwoorde het, verskuif die fout gewoonlik in plaas daarvan om dit op te los.

Werk die waarnemings in volgorde deur, want 'n werf wat geantwoord het, kon nie ook misluk het om op te los nie. As niks hoegenaamd laai nie, is jy in die verkeerde tak en geld die kontroles vir verbind maar sonder internet.

Laat die foutboodskap die tak kies

'n Weiering, 'n bot-uitdaging of 'n foutblad beteken die diens het geantwoord, dus pakkette het 'n toepassing bereik en teruggekom. Dit skuif die vraag na die werf se toegangsbeleid, wat die uitgangsadres, die rekening of versoekpatrone wat dit nie publiseer nie, kan weeg. 'n Fout met naamoplossing het die werf glad nie bereik nie, en die adres is die eerste ding om te ondersoek. 'n Tydverstreke lê tussen die twee: iets is gestuur, en niks het dit bevestig.

Sertifikaatwaarskuwings hoort by 'n vierde tak. Hulle beteken die verbinding is beantwoord deur iets wie se identiteit die blaaier nie kon verifieer nie, wat óf 'n instaanbediener aan jou kant is óf 'n werklike wanverhouding waaroor jy nie moet klik nie. Behandel dit as 'n vertrouensvraag eerder as 'n routeringsvraag.

'n Werf wat antwoord, bewys nie 'n stukkende tonnel nie

Wanneer die antwoord 'n blokkeerblad is, vergelyk dieselfde blad deur 'n tweede uitgang terwyl die blaaier en die masjien onveranderd bly. Volg die resultaat die uitgangsadres, dan behandel die werf daardie adres anders, en geen kliëntopstelling sal dit verander nie. Volg die blok eerder jou blaaier, sit die oorsaak in 'n uitbreiding, 'n gestoorde instaanbediener of 'n oplosserinstelling. Twee lopies skei daardie verklarings goedkoop.

Foute wat net in die blaaier voorkom, is algemeen genoeg om vroeg te toets. 'n Blad wat in een ondersteunde blaaier laai en in 'n ander misluk, dui op profieltoestand, 'n inhoudblokkeerder of geënkripteerde DNS wat binne die blaaier self opgestel is. Chrome se riglyne vir veilige DNS dek waar daardie instelling sit, en om dit deur die ondersteunde beheer te verander, is beter as om die toestel te herstel.

Wanneer net groot oordragte vassteek, kyk na pakketgrootte

'n Blad wat sy kop wys en dan hang, het 'n ander handtekening as 'n blad wat nooit begin nie. Klein antwoorde kan deurkom terwyl 'n vrag van volle grootte êrens laat val word wat die sender niks kan sein nie, en dit is hoe 'n pad-MTU-fout uit 'n blaaier lyk. Vergelyk 'n piepklein versoek en 'n groot een na dieselfde gasheer voordat jy oor filtering teoretiseer. Pad-MTU-ontdekking behoort die kleinste skakelgrootte langs die pad te leer, en dit hang af van ICMP-terugvoer wat gefiltreerde netwerke gereeld weggooi.

Toets daardie hipotese met 'n grootte-veeg eerder as 'n enkele ping. 'n Fout wat by 'n konsekwente vragrootte begin, is sterk bewyse, terwyl 'n fout wat rondbeweeg nie is nie.

Bevestig die oplossing op die versoek wat misluk het

Toets die oorspronklike bewerking weer, nie die tuisblad nie, want 'n gekaste skil kan wys terwyl die API-oproep agter 'n aanmelding steeds misluk. Die opdragte hieronder skei naamoplossing, 'n klein versoek en 'n groot een na dieselfde gasheer. Vervang die gasheernaam en pad met dié uit die versoek wat werklik gebreek het.

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

As die dig-antwoord verskil van wat die blaaier gebruik het, is die oplosser die veranderlike en is die blaaier se eie DNS-instelling die plek om te kyk. As die klein versoek 'n status teruggee terwyl die groot een vassteek, werk die pakketgrootte-tak. As albei tydverstreke gee, is die uitgangspad en die werf se hantering van daardie adres weer op die tafel.

Hou die verandering wat die oorspronklike versoek laat slaag het en maak die res ongedaan. 'n Klomp gelyktydige veranderinge aan blaaier, oplosser en kliënt laat jou nie meer sê watter een saak gemaak het nie.

Verwante artikels