VPN je připojená, ale internet nefunguje? Projděte čtyři vrstvy

Klient hlásí připojeno, prohlížeč se točí a každý web skončí vypršením času. Tahle kombinace je běžná a není to rozpor: připojeno znamená, že tunel se dohodl, a nic víc. Překlad jmen, směrování i vlastní výstup serveru selhávají každý po svém a každý má jiného vlastníka. Procházejte vrstvy popořadě a zastavte se u první, která selže.

Začněte sítí, ze které jste přišli

Shoďte tunel vlastním ovládacím prvkem klienta pro odpojení a pak zkuste dva nesouvisející weby HTTPS, pokud to politika dovoluje. Citlivou práci nechte po dobu testu zavřenou. Pokud selže i běžný přístup, VPN není první podezřelý.

Podívejte se na Wi-Fi spojení, router a jakoukoli portálovou stránku vyžadující přihlášení, než se dotknete tunelu. Kill switch může provoz při odpojení blokovat záměrně, proto postupujte podle jeho zdokumentovaného testovacího postupu, místo abyste usoudili, že síť je mrtvá. Jiná důvěryhodná síť je užitečné srovnání a nový výstup VPN nedokončí propadlé přihlášení v hotelu. Pokud otevřená síť funguje a tunel ne, síť je očištěna a další vrstva je vaše.

Určete, zda selhání spočívá v překladu jmen

Zapište text chyby, protože selhání překladu, vypršení času a varování o certifikátu ukazují každé jinam. Vzor, který je třeba zachytit brzy, je název hostitele, který jste nikdy nenavštívili, selhávající, zatímco aplikace s otevřenou relací pokračuje. Tento vzor se týká nových dotazů, ne toho, zda tunel nese pakety. Jediný dotaz ukáže, co resolver vrací, a zabere sekundu. Zkuste i druhé jméno, aby diagnózu nerozhodla jedna uložená odpověď nebo jeden poškozený záznam.

nslookup example.com

Libovolná IP v adresním řádku HTTPS není test DNS, protože certifikát a virtuální hostitel obvykle závisí na jménu. Interní jména mohou potřebovat resolver organizace místo veřejné náhrady a prohlížeč s vlastním zabezpečeným resolverem může odpovědět jinak než dotaz operačního systému. Když se oba rozcházejí, resolver prohlížeče je ten, který uživatel zažívá, a tento rozdíl patří do tiketu.

Plný tunel, nebo jen firemní podsítě

Některé profily existují jen pro dosažení hrstky firemních podsítí; jiné jsou stavěné tak, aby nesly všechno, a potřebují za sebou funkční výstup. Přečtěte si zdokumentovaný účel, než předpokládáte, že indikátor pokrývá každou aplikaci a každou rodinu adres. Profil privátní sítě může fungovat přesně tak, jak byl navržen, zatímco prohlížeč, který ho nikdy neměl používat, stále selhává. Přečtěte tabulku směrování bez její změny a zahrňte IPv6, protože funkční cesta IPv4 nic neříká o druhé rodině.

Konkrétnější trasa může vyhrát, i když výchozí trasa stále existuje, a proto se tabulka musí číst, ne předpokládat. Konkurenční virtuální adaptéry mohou také vlastnit provoz, který jste čekali jinde, zejména poté, co byl nainstalován a zapomenut druhý klient VPN. Nemažte výchozí trasu jako experiment; promění to diagnózu ve druhý výpadek.

Jeden selhávající web mezi funkčními je problém toho webu a také dokazuje, že tunel nese provoz. Zaseknutí, která se objevují jen u velkých přenosů, ukazují na velikost paketu, ne na dostupnost.

Když server nikdy nic nepředává dál

Pokud každé cílové místo selže na dvou zařízeních a dvou přístupových sítích, tunel je nahoře a výstup nepředává. Právě tato kombinace odděluje selhání na straně serveru od jednoho zařízení špatně nastaveného na jednom místě. Pošlete operátorovi otázky na předávání, NAT a zpětnou cestu, ne snímek indikátoru.

Tyto tři pokrývají většinu příčin na straně serveru a odpovědět na ně má operátor. Stránka pro řešení potíží s připojením OpenVPN prochází stejné otázky ze strany serveru, takže ji předejte spolu s tiketem. Snímek zeleného indikátoru neodpovídá na žádnou z nich.

Projděte klientský log po přihlášení kvůli selháním při aplikaci tras, nastavení DNS nebo virtuálního adaptéru. Chyby v této fázi ukazují na zařízení, ne na server. Chyba, která se v logu nikdy neobjeví, je stejně výmluvná, protože přesouvá podezření na druhou stranu.

Kontrolujte jednu vrstvu po druhé

Když něco změníte, znovu se připojte a zopakujte přesně tu aplikaci, která selhala. Jedna načtená stránka dokazuje méně než opakovatelná cesta ke zdrojům, pro které byl profil postaven. Dva příkazy oddělují překlad od dostupnosti a druhý je specifický pro hostitele. Spusťte řádek curl kdekoli a pak příkaz pro trasy, který odpovídá hostiteli před vámi.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

Pokud číselný požadavek funguje a jméno ne, zůstaňte u DNS. Pokud nefunguje ani jedno, porovnejte tabulku směrování s očekávanou výchozí trasou tunelu a zkontrolujte rodinu, kterou skutečně testujete. Pokud je trasa správná a požadavek stále umírá na výstupu, zbývající otázka patří operátorovi a důkazy, které jste si nechali, jsou tiket.