VPN hlásí připojeno, ale nic se nesměruje: dvě místa, kam se podívat

Tunel může hlásit připojení, zatímco se k němu nic nedostane, a tato dvě fakta bydlí na různých místech. Jedno je směrovací tabulka, která stále může posílat pakety zařízení, které nikdo nevlastní. Druhé je resolver, který stále může uvádět server na rozhraní, které už zmizelo. Změna sítě profil nepoškodila, osiřela stav patřící předchozímu připojení, a oprava závisí na tom, na které z těch dvou se skutečně díváte.

Nejprve se zeptejte jádra, které zařízení by použilo

Výpis tras ukazuje, co existuje; vyhledání trasy ukazuje, co by se stalo. Zeptejte se na veřejnou adresu a přečtěte v odpovědi název zařízení, protože to jedno pole rozhoduje, zda paket dorazí někam užitečně. Když odpověď jmenuje tunelové zařízení, jádro mu pakety předá, i když za tímto rozhraním už neběží žádný klientský proces. Když odpověď jmenuje fyzický adaptér, zatímco klient tvrdí, že je připojen, tunel je nahoře a jen není zvolenou cestou.

Druhý případ je obvyklý poté, co kabel nahradí bezdrát, a projevuje se jako rozbitá VPN.

ip route show default
ip route get 203.0.113.9

Dále čtěte výchozí záznamy, protože trasa přidaná předchozím základním připojením může přežít změnu rozhraní a stát před tou novou. Výchozí trasa přes zařízení, které je mimo provoz, je horší než žádná výchozí trasa, protože ji jádro stále upřednostňuje. Všimněte si metriky u každého záznamu, protože toto pořadí vysvětlí preferenci rychleji než názvy rozhraní.

Potom čtěte resolver pro každé rozhraní, ne pro soubor

Překlad názvů nese vlastní stav a vlastní zastaralost. Resolver, který vypisuje servery DNS po rozhraních, drží servery tunelového rozhraní, které je mimo provoz, ale stále registrované, a každý dotaz pak čeká na server, který neodpoví. Projevem je síť, která působí mrtvě, zatímco směrovací tabulka vypadá dokonale.

Zkoumejte stav po rozhraních, ne soubor, protože v mnoha distribucích je ten soubor symbolický odkaz do resolveru a jeho úprava buď nic nedělá, nebo je rychle přepsána. Podívejte se, které rozhraní vlastní které servery a kterou vyhledávací doménu, a pak se zeptejte, zda by tunelové rozhraní vůbec ještě mělo být registrované. Pokud ne, deaktivujte připojení, které ho vlastní, místo ruční úpravy generovaného stavu. Název, který se přeloží, zatímco vyhledání trasy posílá pakety jinam, je třetí a samostatná závada.

resolvectl status
resolvectl query app.internal.example

Pokud se adresy překládají a připojení selhávají, resolver je v pořádku a trasa ne. Pokud se adresy vůbec nepřekládají, je to správné místo, kde začít.

Jak zastaralá trasa přežije změnu

Klient nevlastní síť sám. Na hostiteli s NetworkManagerem se profil VPN aktivuje nad základním připojením a nastavení připojení dovolují této základně pojmenovat VPN, která ji má následovat. Když se základna změní, protože se upřednostní jiný profil, tunel se přesune na novou základnu nebo zůstane bez žádné.

Profil VPN se sám nenahodí, takže spárování znamená mnohem více než vlastní předvolba automatického připojení profilu.

Přečtěte seznam aktivních a poznamenejte si, která základna je nahoře, než se tunelu dotknete. Pokud je základna v seznamu a tunel ne, trasa chybí, nikoli je zastaralá, a opravou je aktivace. Pokud aktivace tunelu hlásí, že neexistuje zdrojové připojení, základna, se kterou byl spárován, zmizela, takže ji nejprve nahodit nebo spravit spárování, místo abyste tunel zkoušeli znovu. Opakování profilu, jehož rodič chybí, dává pokaždé stejnou chybu, což je užitečný signál a ne obtíž.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

Odlište zastaralý stav od chybějícího rodiče

Tři stavy vysvětlují téměř každé hlášení a každý potřebuje jinou opravu. Výchozí trasa přes zařízení, které ještě existuje, ale už nenese tunel, je zastaralý stav, odstraněný buď smazáním záznamu, nebo restartem odpovědného profilu. Tunelové zařízení, jehož klientský proces zmizel, je selhání úklidu, takže pozornost si zaslouží cesta odpojení, ne směrovací tabulka. Žádné tunelové zařízení znamená, že chybí rodič nebo spárování a směrovací tabulka nebyla nikdy ve hře.

Restart skryje, který ze tří jste měli, a právě proto působí jako oprava.

Po opravě se zeptejte jádra na jednu veřejnou a jednu interní adresu a potom se dotažte na interní název. Když adresa funguje a název ne, našli jste problém rozsahu domény v resolveru, a ne problém směrování. Zapište, který stav jste našli, protože příští změna sítě zopakuje ten, který jste nechali být.