Väčšina porúch domáceho VPN, na ktoré sa ma ľudia pýtajú, nie sú poruchy DNS, a napriek tomu si najprv kúpia predplatné dynamického DNS. Skôr než čokoľvek nastavíte, rozhodnite, či je meno hostiteľa tou časťou, ktorá je naozaj pokazená. Aktualizátor prepíše záznam, keď sa adresa od poskytovateľa pohne; nevie otvoriť port, prejsť cez NAT operátora ani prinútiť bežiacu reláciu WireGuard, aby si všimla, že sa jej koncový bod zmenil. Tri podmienky rozhodujú, či je dynamický DNS celé riešenie alebo len jeden jeho riadok.

Prvá podmienka: vaša adresa sa naozaj mení

Domáce adresy sa menia z obyčajných dôvodov: modem sa po výpadku prúdu znovu synchronizuje, poskytovateľ prebalansuje pool, po dlhom výpadku príde nový nájom. Na niektorých linkách sa menia aj zriedka, a videl som tú istú adresu vydržať rok; firemné tarify často zahŕňajú statickú. Ak sa za dvanásť mesiacov nič nezmenilo, jeden ručne upravovaný záznam A je o jedného démona menej na udržiavanie.

Zmerajte to namiesto hádania. Prečítajte WAN adresu na stavovej stránke routera a porovnajte ju s tým, čo vidí vonkajší svet. Spustite to zo stroja v LAN:

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

Ak sa obe hodnoty líšia, niečo prekladá pred vaším routerom a žiadna aktualizácia mena hostiteľa to nespraví. Adresa v rozsahu 100.64.0.0/10 je zdieľaný rozsah pre NAT na úrovni operátora, a to je zvyčajný dôvod, prečo správne aktualizované meno zvonku stále vyprší.

Druhá podmienka: klienti si meno vyhľadajú znova

Krátke TTL je časť, ktorú ľudia vynechávajú. Rekurzívne resolvery rešpektujú TTL záznamu, ale klientské zásobníky cachujú oddelene a už postavený tunel nič znova nerozkladá. Počas ladenia nastavte záznam na 60-300 sekúnd; skráti to okno, v ktorom sa podáva zastaraná odpoveď, a nepresúva pripojenú reláciu.

OpenVPN pri každom opätovnom pripojení znova prekladá riadok remote vpn.example.net 1194 , a resolv-retry infinite ho núti skúšať ďalej namiesto ukončenia, keď vyhľadanie zlyhá. Na serveri float umožňuje nadviazanej relácii nasledovať partnera, ktorého zdrojová adresa sa zmenila. WireGuard je priamočiarejší: wg-quick up pri aplikácii konfigurácie prekladá Endpoint koncový bod a klient ho znova preloží, keď tunel znovu zostaví, takže handshake, ktorý proti starej adrese stále prechádza, prechádza, kým sa nezastaví.

Tento rozdiel formuje plán. Ak sa klienti pripájajú na požiadanie, zmena adresy stojí jedno opätovné pripojenie. Ak držia reláciu otvorenú dni, čakajte, že tunel pri ďalšom handshake zomrie, a prinúťte klienta skúsiť znova, namiesto predpokladu, že zostane.

Tretia podmienka: vstupná cesta je stále otvorená

Dynamický DNS mení len to, kam meno ukazuje, a nič iné. Presmerovanie portu na routeri, pravidlo firewallu na hoste VPN a povolenie prichádzajúcich paketov od poskytovateľa musia existovať skôr, než záznam začne mať význam. Sledujte, na čo presmerovanie mieri: ak je pripnuté k WAN adrese namiesto rozhrania, zmena adresy potichu pokazí presmerovanie a vina padne na záznam.

Testujte zvonku. Telefón na mobilných dátach s vypnutým Wi-Fi je najlacnejší čestný test; notebook v rovnakej LAN nie je. Keď sa meno preloží na vašu verejnú adresu a router nemá NAT slučku, vnútorný test zlyhá, hoci záznam je úplne správny, a to pošle väčšinu ľudí upravovať záznam, ktorý nikdy nebol nesprávny.

Čo spustiť, keď platia všetky tri

ddclient je najmenej prekvapivý aktualizátor pre malý hostiteľ. Minimálna konfigurácia zverejní adresu, ktorú vidí poskytovateľ, a tým obchádza 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

Spúšťajte ho z časovača systemd každých pár minút namiesto shell slučky a logujte odpoveď poskytovateľa namiesto predpokladu úspechu. Správajte sa k prihlasovacím údajom ako ku kľúču, pretože určujú, kam sa každý klient posiela: používajte obmedzený aktualizačný token namiesto hesla účtu, držte súbor v režime 0600 a posielajte aktualizácie cez HTTPS.

Overte, kým sa zaviažete

Jeden dotaz vám povie, čo vidí zvyšok sveta, a vypíše TTL, ktorý musíte po zmene vyčkať:

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

Porovnajte tú adresu s WAN adresou routera. Ak sa zhodujú, meno robí svoju prácu a to, čo stále zlyháva, je prichádzajúca dostupnosť, kľúč alebo klient, ktorý znova nepreložil. Ak sa líšia, aktualizátor zverejňuje nesprávne rozhranie, často preto, že bežal na hoste VPN za routerom namiesto na samotnom routeri.

Majte rollback, ktorý trvá minútu: poznačte si poslednú funkčnú adresu a predchádzajúce TTL, aby ste obe mohli zverejniť ručne, kým má poskytovateľ zlé popoludnie.

Keď je odpoveď nie

Ak zlyhá prvá alebo tretia podmienka, mení sa rozhodnutie, nie konfigurácia. Za NAT operátora sú praktické možnosti požiadať poskytovateľa o verejnú adresu, presunúť vstupný bod na malý VPS so stabilnou adresou, alebo použiť prekrytie, ktoré si drží vlastné stretnutie. Ak je adresa statická, aktualizátor vynechajte: jeden záznam A, jeden záznam AAAA, ak používate IPv6, rovnaké presmerovanie portu.

Ak sa adresa mení, kým klienti zostávajú pripojení, čestná oprava žije v klientovi: logika opätovného pripojenia a interval opakovania, nie rýchlejší aktualizátor. Druhý poskytovateľ len skryje interval.

Skôr než budete pokračovať, potvrďte štyri veci v poradí:

  • Adresa, ktorú aktualizátor zverejňuje, zodpovedá WAN adrese routera.
  • TTL záznamu je dosť krátke na to, aby sa zmena prejavila v priebehu minút.
  • Presmerovanie portu je viazané na rozhranie, nie na pevnú adresu.
  • Jeden skutočný klient sa od poslednej zmeny znova pripojil a prepustil prevádzku.

Ak platia všetky štyri, nechajte nastavenie na pokoji; vaša ďalšia porucha je kľúč alebo pravidlo firewallu, nie problém s pomenovaním. Ak niektorá zlyhá, opravte ten riadok, kým pridáte ďalšiu pohyblivú časť. RFC 2136 opisuje samotný mechanizmus aktualizácie, ak chcete vidieť, čo démon posiela na drôt.

Súvisiace články