Proč některé weby selhávají jen se zapnutou VPN?

To, že selže jediný web, zatímco vše ostatní se načítá, dokazuje, že tunel přenáší provoz, což problém zúží víc, než většina čeká. Tři pozorování roztřídí zbytek: jestli jste vůbec dostali odpověď HTTP, jestli se název hostitele přeložil na adresu a jestli malé požadavky procházejí, zatímco velké se zasekávají. Hádání o VPN dřív, než máte tyto odpovědi, obvykle závadu přesune, místo aby ji odstranilo.

Projděte pozorování popořadě, protože web, který odpověděl, nemohl zároveň selhat při překladu. Pokud se nenačítá vůbec nic, jste ve špatné větvi a platí kontroly pro připojeno, ale bez internetu.

Nechte chybovou zprávu vybrat větev

Odmítnutí, antibotová výzva nebo chybová stránka znamenají, že služba odpověděla, takže pakety dorazily do aplikace a vrátily se. Tím se otázka přesouvá k přístupové politice webu, která může vážit výstupní adresu, účet nebo vzorce požadavků, které nezveřejňuje. Selhání překladu jmen se k webu vůbec nedostalo, a adresa je první věc k prozkoumání. Časový limit leží mezi nimi: něco bylo odesláno a nic to nepotvrdilo.

Upozornění na certifikáty patří do čtvrté větve. Znamenají, že spojení obsloužilo něco, jehož identitu prohlížeč nemohl ověřit, tedy buď proxy na vaší straně, nebo skutečná neshoda, kterou byste neměli proklikávat. Berte to jako otázku důvěry, ne směrování.

Web, který odpovídá, nedokázal rozbitý tunel

Když je odpovědí blokační stránka, porovnejte stejnou stránku přes druhý výstup a přitom nechte prohlížeč i stroj beze změny. Pokud výsledek sleduje výstupní adresu, web tu adresu ošetřuje jinak a žádná konfigurace klienta to nezmění. Pokud blokace sleduje místo toho váš prohlížeč, příčina je v rozšíření, uložené proxy nebo nastavení resolveru. Dva běhy tyto výklady levně oddělí.

Závady jen v prohlížeči jsou dost časté na to, aby se testovaly brzy. Stránka, která se načte v jednom podporovaném prohlížeči a v jiném selže, ukazuje na stav profilu, blokátor obsahu nebo šifrované DNS nastavené uvnitř samotného prohlížeče. Pokyny Chrome k bezpečnému DNS ukazují, kde to nastavení je, a změna přes podporovanou kontrolu je lepší než reset zařízení.

Když se zasekávají jen velké přenosy, podívejte se na velikost paketů

Stránka, která vykreslí hlavičku a pak se zasekne, má jiný podpis než stránka, která vůbec nezačne. Malé odpovědi mohou procházet, zatímco plná zátěž je někde zahozena, což nedokáže odesílateli nic signalizovat, a tak vypadá závada MTU cesty z prohlížeče. Porovnejte malinký požadavek a velký na stejný hostitel, než začnete teoretizovat o filtrování. Zjišťování MTU cesty má poznat nejmenší velikost spoje na cestě a závisí na odpovědích ICMP, které filtrované sítě rutinně zahazují.

Otestujte tuto hypotézu procházením velikostí místo jediného pingu. Závada, která začíná při stálé velikosti zátěže, je silný důkaz, zatímco závada, která se posouvá, není.

Potvrďte opravu na požadavku, který selhal

Otestujte znovu původní operaci, ne domovskou stránku, protože uložená skořápka se může vykreslit, zatímco volání API za přihlášením stále selhává. Příkazy níže oddělují překlad jmen, malý požadavek a velký na stejný hostitel. Nahraďte název hostitele a cestu těmi z požadavku, který se skutečně zlomil.

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

Pokud se odpověď dig liší od té, kterou použil prohlížeč, proměnnou je resolver a místem k pohledu je vlastní nastavení DNS prohlížeče. Pokud malý požadavek vrací stav, zatímco velký se zasekává, propracujte větev velikosti paketů. Pokud oba vyprší, výstupní cesta a přístup webu k této adrese jsou zpět na stole.

Ponechte změnu, díky které původní požadavek uspěl, a zbytek vraťte. Hromada současných změn v prohlížeči, resolveru a klientovi vám znemožní říct, která z nich byla důležitá.