Hvorfor fejler nogle websteder kun, når VPN'en er tændt?

At ét websted fejler, mens alt andet indlæses, beviser, at tunnelen bærer trafik, og det indsnævrer problemet mere, end de fleste forventer. Tre observationer sorterer resten: om du overhovedet fik et HTTP-svar, om værtsnavnet blev opløst til en adresse, og om små forespørgsler går igennem, mens store hænger. At gætte på VPN'en, før du har de svar, flytter som regel fejlen i stedet for at fjerne den.

Arbejd observationerne igennem i rækkefølge, for et websted, der svarede, kan ikke også være mislykkedes med at opløse. Hvis intet indlæses overhovedet, er du i den forkerte gren, og kontrollerne for forbundet men uden internet gælder i stedet.

Lad fejlmeddelelsen vælge grenen

En afvisning, en bot-udfordring eller en fejlside betyder, at tjenesten svarede, så pakker nåede en applikation og kom tilbage. Det flytter spørgsmålet til webstedets adgangspolitik, som kan vægte udgangsadressen, kontoen eller anmodningsmønstre, den ikke offentliggør. En fejl i navneopløsningen nåede slet ikke webstedet, og adressen er det første, der skal undersøges. En timeout ligger mellem de to: noget blev sendt, og intet bekræftede det.

Certifikatadvarsler hører til en fjerde gren. De betyder, at forbindelsen blev besvaret af noget, hvis identitet browseren ikke kunne bekræfte, hvilket enten er en proxy på din side eller en ægte uoverensstemmelse, du ikke bør klikke igennem. Behandl det som et tillidsspørgsmål snarere end et routing-spørgsmål.

Et websted, der svarer, beviser ikke en brudt tunnel

Når svaret er en blokeringsside, så sammenlign den samme side gennem en anden udgang, mens browser og maskine forbliver uændrede. Følger resultatet udgangsadressen, behandler webstedet den adresse anderledes, og ingen klientkonfiguration vil ændre det. Følger blokeringen i stedet din browser, sidder årsagen i en udvidelse, en gemt proxy eller en resolverindstilling. To kørsler skiller de forklaringer billigt.

Fejl, der kun sker i browseren, er almindelige nok til at teste tidligt. En side, der indlæses i én understøttet browser og fejler i en anden, peger på profiltilstand, en indholdsblokering eller krypteret DNS, der er konfigureret inde i browseren selv. Chromes vejledning om sikker DNS dækker, hvor den indstilling ligger, og at ændre den via den understøttede kontrol slår at nulstille enheden.

Når kun store overførsler hænger, se på pakkestørrelsen

En side, der viser sin header og derefter hænger, har en anden signatur end en side, der aldrig starter. Små svar kan gå igennem, mens en nyttelast i fuld størrelse bliver droppet et sted, der ikke kan signalere til afsenderen, og det er sådan en path-MTU-fejl ser ud fra en browser. Sammenlign en bitte lille forespørgsel og en stor til den samme vært, før du teoretiserer om filtrering. Path-MTU-discovery skal lære den mindste ledstørrelse langs vejen, og den afhænger af ICMP-feedback, som filtrerede netværk rutinemæssigt kasserer.

Test den hypotese med en størrelsessweep i stedet for en enkelt ping. En fejl, der begynder ved en ensartet nyttelaststørrelse, er stærkt bevis, mens en fejl, der flytter sig rundt, ikke er.

Bekræft løsningen på den forespørgsel, der fejlede

Test den oprindelige handling igen, ikke forsiden, for en cachet skal kan vise sig, mens API-kaldet bag en login stadig fejler. Kommandoerne nedenfor skiller navneopløsning, en lille forespørgsel og en stor mod den samme vært. Erstat værtsnavn og sti med dem fra den forespørgsel, der faktisk brød sammen.

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

Hvis dig-svaret afviger fra det, browseren brugte, er resolveryderen variablen, og browserens egen DNS-indstilling er stedet at kigge. Hvis den lille forespørgsel returnerer en status, mens den store hænger, så arbejd pakkestørrelsesgrenen. Hvis begge timer ud, er udgangsstien og webstedets håndtering af den adresse igen på bordet.

Behold den ændring, der fik den oprindelige forespørgsel til at lykkes, og rul resten tilbage. En bunke samtidige ændringer af browser, resolveryder og klient gør dig ude af stand til at sige, hvilken der gjorde en forskel.