Potřebujete dynamický DNS pro domácí VPN server?

Dynamický DNS spraví jméno, ne cestu dovnitř. Tři kontroly rozhodnou, zda je jméno hostitele pro domácí VPN server dostačující, nebo je trasa dovnitř rozbitá.

Většina poruch domácího VPN, na které se mě lidé ptají, nejsou poruchy DNS, a přesto si nejdřív kupují předplatné dynamického DNS. Než cokoli nastavíte, rozhodněte, zda je jméno hostitele ta část, která je skutečně rozbitá. Aktualizátor přepíše záznam, když se změní adresa, kterou vám přidělil poskytovatel; neumí otevřít port, projít přes NAT operátora ani přimět běžící relaci WireGuard, aby si všimla, že se její koncový bod změnil. Tři podmínky rozhodují, zda je dynamický DNS celé řešení, nebo jen jeden jeho řádek.

První podmínka: vaše adresa se skutečně mění

Domácí adresy se mění z obyčejných důvodů: modem se po výpadku proudu znovu synchronizuje, poskytovatel přebalancuje pool, po dlouhém výpadku přijde nový pronájem. Na některých linkách se mění i zřídka a viděl jsem stejnou adresu vydržet rok; firemní tarify často zahrnují statickou. Pokud se za dvanáct měsíců nic nezměnilo, jeden záznam A upravovaný ručně je o jednoho démona méně k udržování.

Změřte to místo hádání. Přečtěte WAN adresu na stavové stránce routeru a porovnejte ji s tím, co vidí vnější svět. Spusťte to ze stroje v LAN:

curl -fsS https://api.ipify.org; echo

Pokud se obě hodnoty liší, něco před vaším routerem překládá a žádná aktualizace jména to nespraví. Adresa uvnitř 100.64.0.0/10 je sdílený rozsah pro NAT na úrovni operátora, a to je obvyklý důvod, proč správně aktualizované jméno zvenčí stále vyprší.

Druhá podmínka: klienti se na jméno ptají znovu

Krátké TTL je část, kterou lidé vynechávají. Rekurzivní resolvery TTL záznamu respektují, ale klientské stacky cachují odděleně a tunel, který už běží, nic znovu nepřekládá. Během ladění nastavte záznam na 60-300 sekund; zkrátí to okno, kdy se podává zastaralá odpověď, a nepřesune připojenou relaci.

OpenVPN znovu překládá řádek remote vpn.example.net 1194 při každém opětovném připojení a resolv-retry infinite ho nutí zkoušet dál, místo aby skončil, když vyhledání selže. Na serveru float umožňuje navázané relaci následovat protějšek, jehož zdrojová adresa se změnila. WireGuard je přímočařejší: wg-quick up překládá Endpoint při aplikaci konfigurace a klient ho znovu přeloží, když tunel znovu sestaví, takže handshake, který proti staré adrese stále prochází, prochází dál, dokud nepřestane.

Tento rozdíl určuje plán. Pokud se klienti připojují na vyžádání, změna adresy stojí jedno opětovné připojení. Pokud drží relaci otevřenou dny, čekejte, že tunel při dalším handshake zemře, a přinuťte klienta zkoušet znovu, místo abyste předpokládali, že zůstane nahoře.

Třetí podmínka: vstupní cesta je stále otevřená

Dynamický DNS mění jen to, kam jméno ukazuje, a nic jiného. Přesměrování portu na routeru, pravidlo firewallu na VPN hostiteli a povolení příchozích paketů od poskytovatele musí existovat dřív, než záznam začne mít význam. Sledujte, na co přesměrování míří: je-li přikované k WAN adrese místo k rozhraní, změna adresy přesměrování tiše rozbije a vina padne na záznam.

Testujte zvenčí. Telefon na mobilních datech s vypnutým Wi-Fi je nejlevnější poctivý test; notebook ve stejné LAN není. Když se jméno přeloží na vaši veřejnou adresu a router nemá NAT loopback, vnitřní test selže, i když je záznam úplně správný, což většinu lidí pošle upravovat záznam, který nikdy špatný nebyl.

Co spustit, když platí všechny tři

ddclient je nejméně překvapivý aktualizátor pro malý hostitel. Minimální konfigurace publikuje adresu, kterou poskytovatel vidí, a tím obchází chybu dvojitého NAT:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Spouštějte ho ze systemd časovače každých pár minut místo shell smyčky a logujte odpověď poskytovatele, místo abyste předpokládali úspěch. Chovejte se k přihlašovacím údajům jako ke klíči, protože určují, kam se každý klient posílá: používejte omezený aktualizační token místo hesla k účtu, držte soubor v režimu 0600 a posílejte aktualizace přes HTTPS.

Ověřte, než se zavážete

Jeden dotaz vám řekne, co vidí zbytek světa, a vypíše TTL, který musíte po změně vyčkat:

dig +noall +answer vpn.example.net @1.1.1.1

Porovnejte tuto adresu s WAN adresou routeru. Pokud se shodují, jméno dělá svou práci a co stále selhává, je příchozí dostupnost, klíč nebo klient, který znovu nepřeložil. Pokud se liší, aktualizátor publikuje špatné rozhraní, často proto, že běžel na VPN hostiteli za routerem místo na routeru samotném.

Mějte rollback na minutu: poznamenejte si poslední funkční adresu a předchozí TTL, abyste obojí mohli publikovat ručně, když má poskytovatel špatné odpoledne.

Když je odpověď ne

Pokud selže první nebo třetí podmínka, mění se rozhodnutí, ne konfigurace. Za NAT operátora jsou praktické možnosti požádat poskytovatele o veřejnou adresu, přesunout vstupní bod na malý VPS se stabilní adresou, nebo použít overlay, který si drží vlastní setkání. Pokud je adresa statická, aktualizátor vynechte: jeden záznam A, jeden záznam AAAA, pokud používáte IPv6, stejné přesměrování portu.

Pokud se adresa mění, zatímco klienti zůstávají připojení, poctivá oprava žije na klientovi: logika opětovného připojení a interval opakování, ne rychlejší aktualizátor. Druhý poskytovatel jen skrývá interval.

Než půjdete dál, potvrďte čtyři věci v pořadí:

  • Adresa, kterou aktualizátor publikuje, odpovídá WAN adrese routeru.
  • TTL záznamu je dost krátké na to, aby se změna projevila v řádu minut.
  • Přesměrování portu je vázané na rozhraní, ne na pevnou adresu.
  • Jeden skutečný klient se od poslední změny znovu připojil a prošel provoz.

Pokud platí všechny čtyři, nechte nastavení být; vaše další porucha je klíč nebo pravidlo firewallu, ne problém s pojmenováním. Pokud některá selže, opravte ten řádek, než přidáte další pohyblivou část. RFC 2136 popisuje samotný mechanismus aktualizace, pokud chcete vidět, co démon posílá na drát.

Související články