VPN se přestěhovala: proč váš klient OpenVPN stále volá starou IP

Poskytovatel změnil vaši veřejnou adresu, vy jste aktualizovali dynamický záznam DNS a klient se stále nemůže připojit. Zvenčí to vypadá, jako by se záznam nepropsal. Většinou je záznam v pořádku a klient volá adresu, kterou přeložil ještě před přesunem, protože běžící tunel i uložený profil mají každý svou představu o tom, kde server žije. Tři vrstvy se musí shodnout a aktualizují se podle různých plánů.

Sledujte, co volá profil, ne co říká DNS

Otevřete připojení, které skutečně používáte, a přečtěte řádek remote. Číselná adresa tam nikdy nenásleduje aktualizaci názvu hostitele, ať je záznam jakkoli správný.

Potom zkontrolujte, zda profil, který jste upravili, je ten, který klient načetl. Importované profily jsou běžné: správce si před měsíci mohl vzít kopii a ponechat si vlastní verzi, takže soubor ve složce stahování a položka v aplikaci se mohou rozejít. Porovnejte koncový bod ve vlastních podrobnostech připojení klienta, než vůbec začnete ladit DNS.

Dva soubory, jeden koncový bod — to je zde obvyklé zjištění.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Přečtěte si další pokus klienta o připojení

Restartujte připojení s podrobným protokolováním a přečtěte řádek, kde je uvedena adresa, kterou bude kontaktovat. Právě tato hodnota je důležitá, ne to, co přeložil váš prohlížeč.

Mezipaměť resolveru může stále držet předchozí odpověď a některé sítě ji drží déle, než požaduje TTL záznamu. Ptejte se resolveru, který klient skutečně používá, ne veřejného, který jste testovali odjinud.

Pokud protokol ukazuje novou adresu a připojení stále selhává, problém se posunul: paket někam jde a nikdo neodpovídá. To je otázka naslouchajícího procesu, firewallu nebo přesměrování portu a leží na straně serveru, ne v cestě překladu u klienta. Tyto dvě selhání držte odděleně, protože když nedostupný naslouchající proces považujete za problém DNS, projdete stejnou smyčku dvakrát.

Vězte, jaký restart provádíte

Ne všechny restarty zachovávají stejný stav, a proto se změna adresy může chovat různě podle toho, jak se proces recykluje. Měkký restart vyvolaný signálem zachovává více kontextu předchozí relace, zatímco úplné zastavení a spuštění začíná znovu od konfigurace. Pokud testujete, zda klient znovu překládá, chcete cestu, která začíná od konfigurace.

Nastavení trvalosti také záleží, protože mají udržet to, co bylo ověřeno, ne honit nové adresy.

Nejčistší test je čerstvé spuštění z určeného profilu a pak pohled na řádek protokolu, který uvádí koncový bod. Cokoli se dozvíte z částečně zachované relace, je tvrzení o této relaci.

Čtyři volby a jejich oddělené úkoly

remote s názvem hostitele je nastavení, které opětovný překlad vůbec umožňuje; doslovná adresa na tomto řádku to vylučuje. resolv-retry řídí, co se stane při neúspěšném vyhledání, a 2.6 jej již ve výchozím nastavení nastavuje na nekonečno. Jeho přidání tedy nic nemění a nikdy neplánuje periodickou kontrolu jiné odpovědi. Kdo říká, že dotazuje nové adresy, ten si plete obnovu s aktuálností.

persist-remote-ip je o spojitosti, ne o aktuálnosti: znovu používá koncový bod, který se naposledy ověřil, napříč měkkými restarty, které podporuje. Zatímco testujete přesun, je to pravý opak toho, co chcete. Vypněte jej pro test, pokud jej vaše sestavení zapíná, a po prokázání nového koncového bodu jej vraťte. Ponechán zapnutý, úspěšné opětovné připojení vám o DNS nemusí říct nic.

float přijímá ověřeného partnera, jehož adresa se změnila uprostřed relace, a jen v uspořádáních, která to podporují. Neobnovuje DNS a sám nebude sledovat změnu poskytovatele. Berte jej jako funkci odolnosti pro partnery, kteří se pohybují, ne jako mechanismus dynamických adres pro servery.

Potvrďte nový koncový bod, než obviníte klienta

Zvenčí své sítě zkontrolujte, že nová adresa má naslouchající proces na nakonfigurovaném portu a že přesměrování poskytovatele na ni ukazuje. Správný záznam A pro stroj bez otevřeného portu vytváří přesně ten příznak, který lidé připisují mezipaměti.

Potom se znovu připojte a ověřte dvě věci: klient se ověřil proti očekávanému certifikátu serveru a relace dosáhne zdroje, který jste zamýšleli. Změna adresy nesnižuje požadavky na identitu a připojení, které uspěje ke špatnému koncovému bodu, je horší než to, které selže. Příručka OpenVPN 2.6 uvádí všechny čtyři volby s jejich vlastním rozsahem a to je kontrolní seznam, který je třeba mít u profilu.

Než restartujete tunel, který nese váš administrativní přístup, zajistěte si cestu k serveru mimo pásmo. To jediné opatření zabrání většině incidentů, které tento scénář vyvolává.