Prečo niektoré weby zlyhávajú len so zapnutou VPN?

To, že zlyhá jediný web, zatiaľ čo všetko ostatné sa načítava, dokazuje, že tunel prenáša prevádzku, čo problém zúži viac, než väčšina očakáva. Tri pozorovania roztriedia zvyšok: či ste vôbec dostali odpoveď HTTP, či sa názov hostiteľa preložil na adresu a či malé požiadavky prechádzajú, zatiaľ čo veľké sa zasekávajú. Hádanie o VPN skôr, než máte tieto odpovede, zvyčajne poruchu presunie, namiesto toho aby ju odstránilo.

Prejdite pozorovania po poradí, pretože web, ktorý odpovedal, nemohol zároveň zlyhať pri preklade. Ak sa nenačítava vôbec nič, ste v nesprávnej vetve a platia kontroly pre pripojené, ale bez internetu.

Nechajte chybovú správu vybrať vetvu

Odmietnutie, antibotová výzva alebo chybová stránka znamenajú, že služba odpovedala, takže pakety dorazili do aplikácie a vrátili sa. Tým sa otázka presúva k prístupovej politike webu, ktorá môže vážiť výstupnú adresu, účet alebo vzory požiadaviek, ktoré nezverejňuje. Zlyhanie prekladu mien sa k webu vôbec nedostalo, a adresa je prvá vec na preskúmanie. Časový limit leží medzi nimi: niečo bolo odoslané a nič to nepotvrdilo.

Upozornenia na certifikáty patria do štvrtej vetvy. Znamenajú, že spojenie obslúžilo niečo, ktorého identitu prehliadač nemohol overiť, teda buď proxy na vašej strane, alebo skutočná nezhoda, ktorou by ste nemali preklikávať. Berte to ako otázku dôvery, nie smerovania.

Web, ktorý odpovedá, nedokázal pokazený tunel

Keď je odpoveďou blokačná stránka, porovnajte tú istú stránku cez druhý výstup a pritom nechajte prehliadač aj stroj nezmenené. Ak výsledok sleduje výstupnú adresu, web tú adresu ošetruje inak a žiadna konfigurácia klienta to nezmení. Ak blokácia sleduje namiesto toho váš prehliadač, príčina je v rozšírení, uloženej proxy alebo nastavení resolvera. Dva behy tieto výklady lacno oddelia.

Poruchy len v prehliadači sú dosť časté na to, aby sa testovali skoro. Stránka, ktorá sa načíta v jednom podporovanom prehliadači a v inom zlyhá, ukazuje na stav profilu, blokátor obsahu alebo šifrované DNS nastavené vnútri samotného prehliadača. Pokyny Chrome k bezpečnému DNS ukazujú, kde to nastavenie je, a zmena cez podporovanú kontrolu je lepšia než reset zariadenia.

Keď sa zasekávajú len veľké prenosy, pozrite sa na veľkosť paketov

Stránka, ktorá vykreslí hlavičku a potom sa zasekne, má iný podpis než stránka, ktorá vôbec nezačne. Malé odpovede môžu prechádzať, zatiaľ čo plná záťaž je niekde zahodená, čo nedokáže odosielateľovi nič signalizovať, a tak vyzerá porucha MTU cesty z prehliadača. Porovnajte malinkú požiadavku a veľkú na toho istého hostiteľa, než začnete teoretizovať o filtrovaní. Zisťovanie MTU cesty má poznať najmenšiu veľkosť spoja na ceste a závisí od odpovedí ICMP, ktoré filtrované siete rutinne zahadzujú.

Otestujte túto hypotézu prechádzaním veľkostí namiesto jediného pingu. Porucha, ktorá začína pri stálej veľkosti záťaže, je silný dôkaz, zatiaľ čo porucha, ktorá sa posúva, nie je.

Potvrďte opravu na požiadavke, ktorá zlyhala

Otestujte znova pôvodnú operáciu, nie domovskú stránku, pretože uložená škrupina sa môže vykresliť, zatiaľ čo volanie API za prihlásením stále zlyháva. Príkazy nižšie oddeľujú preklad mien, malú požiadavku a veľkú na toho istého hostiteľa. Nahraďte názov hostiteľa a cestu tými z požiadavky, ktorá sa skutočne zlomila.

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

Ak sa odpoveď dig líši od tej, ktorú použil prehliadač, premennou je resolver a miestom na pohľad je vlastné nastavenie DNS prehliadača. Ak malá požiadavka vracia stav, zatiaľ čo veľká sa zasekáva, prepracujte vetvu veľkosti paketov. Ak obe vypršia, výstupná cesta a prístup webu k tejto adrese sú späť na stole.

Ponechajte zmenu, vďaka ktorej pôvodná požiadavka uspela, a zvyšok vráťte. Hromada súčasných zmien v prehliadači, resolveri a klientovi vám znemožní povedať, ktorá z nich bola dôležitá.