Treba li vam dinamički DNS za kućni VPN server?

Dinamički DNS popravlja ime, ne put unutra. Tri provjere odlučuju je li ime hosta dovoljno za kućni VPN server ili je ruta unutra pokvarena.

Većina kvarova kućnog VPN-a o kojima me pitaju nisu kvarovi DNS-a, a ipak prvo kupe pretplatu na dinamički DNS. Prije nego što bilo što podesite, odlučite je li ime hosta dio koji je stvarno pokvaren. Ažurator prepisuje zapis kad se adresa koju vam je dao ISP promijeni; ne može otvoriti port, probiti NAT operatera ni natjerati živu WireGuard sesiju da primijeti da joj se krajnja točka promijenila. Tri uvjeta odlučuju je li dinamički DNS cijelo rješenje ili samo jedan njegov red.

Uvjet prvi: vaša adresa se stvarno mijenja

Kućne adrese mijenjaju se iz običnih razloga: modem se resinkronizira nakon nestanka struje, ISP prebalansira bazen, novi najam dođe nakon dugog prekida. Na nekim se linijama mijenjaju i rijetko, a gledao sam kako ista adresa preživi godinu dana; poslovni paketi često uključuju statičku. Ako se ništa nije promijenilo dvanaest mjeseci, jedan A zapis koji uređujete ručno je jedan daemon manje za održavanje.

Izmjerite umjesto da nagađate. Pročitajte WAN adresu na statusnoj stranici usmjerivača, pa je usporedite s onim što vidi vanjski svijet. Pokrenite ovo sa stroja u LAN-u:

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

Ako se dvije vrijednosti razlikuju, nešto prevodi ispred vašeg usmjerivača i nikakvo ažuriranje imena hosta to neće popraviti. Adresa unutar 100.64.0.0/10 je zajednički raspon za NAT na razini operatera, i to je uobičajen razlog zašto ispravno ažurirano ime ipak ističe izvana.

Uvjet drugi: klijenti ponovno traže ime

Kratak TTL je dio koji ljudi preskaču. Rekurzivni resolveri poštuju TTL zapisa, ali klijentski stogovi keširaju odvojeno, a tunel koji je već podignut ne razrješava ništa ponovno. Postavite zapis na 60-300 sekundi dok otklanjate probleme; to skraćuje prozor u kojem se poslužuje zastario odgovor i ne migrira spojenu sesiju.

OpenVPN ponovno razrješava redak remote vpn.example.net 1194 pri svakom ponovnom spajanju, a resolv-retry infinite ga tjera da ponavlja pokušaje umjesto da izađe kad traženje ne uspije. Na serveru float dopušta uspostavljenoj sesiji da slijedi partnera čija se izvorna adresa promijenila. WireGuard je izravniji: wg-quick up razrješava Endpoint kad se primijeni konfiguracija, a klijent ga razrješava ponovno kad ponovno izgradi tunel, pa rukovanje koje još prolazi prema staroj adresi prolazi sve dok ne stane.

Ta razlika oblikuje plan. Ako se klijenti spajaju na zahtjev, promjena adrese stoji jedno ponovno spajanje. Ako drže sesiju otvorenu danima, očekujte da će tunel umrijeti pri sljedećem rukovanju, i natjerajte klijenta da pokuša ponovno umjesto da pretpostavljate da ostaje podignut.

Uvjet treći: ulazni put je još otvoren

Dinamički DNS mijenja samo kamo ime pokazuje i ništa drugo. Prosljeđivanje porta na usmjerivaču, pravilo vatrozida na VPN hostu i dopuštanje ulaznih paketa od ISP-a moraju postojati prije nego zapis postane važan. Pazite na što prosljeđivanje cilja: ako je prikvačeno za WAN adresu umjesto za sučelje, promjena adrese tiho pokvari prosljeđivanje i zapis preuzme krivnju.

Testirajte izvana. Telefon na mobilnim podacima s isključenim Wi-Fi najjeftiniji je iskren test; laptop u istom LAN-u nije. Kad se ime razriješi na vašu javnu adresu, a usmjerivač nema NAT povratnu petlju, test iznutra pada dok je zapis posve ispravan, što većinu ljudi pošalje uređivati zapis koji nikad nije bio pogrešan.

Što pokrenuti kad sve tri drže

ddclient je najmanje iznenađujući ažurator za mali host. Minimalna konfiguracija objavljuje adresu koju vidi davatelj, što zaobilazi pogrešku dvostrukog NAT-a:

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

Pokrećite ga iz systemd timera svakih nekoliko minuta umjesto iz shell petlje, i bilježite odgovor davatelja umjesto da pretpostavljate uspjeh. Tretirajte vjerodajnicu kao ključ, jer ona odlučuje kamo se šalje svaki klijent: rabite ograničeni token za ažuriranje umjesto lozinke računa, držite datoteku u modu 0600 i šaljite ažuriranja preko HTTPS-a.

Provjerite prije nego se obvežete

Jedno traženje kaže vam što vidi ostatak svijeta i ispiše TTL koji morate odčekati nakon promjene:

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

Usporedite tu adresu s WAN adresom usmjerivača. Ako se podudaraju, ime radi svoj posao, a ono što još pada je ulazna dostupnost, ključ ili klijent koji nije ponovno razriješio. Ako se razlikuju, ažurator objavljuje pogrešno sučelje, često zato što je radio na VPN hostu iza usmjerivača umjesto na samom usmjerivaču.

Držite vraćanje koje traje minutu: zabilježite zadnju radnu adresu i prethodni TTL, da oboje možete objaviti ručno dok davatelj ima loše poslijepodne.

Kad je odgovor ne

Ako prvi ili treći uvjet padne, mijenja se odluka, a ne konfiguracija. Iza NAT-a operatera praktične su vam opcije tražiti od ISP-a javnu adresu, premjestiti ulaznu točku na mali VPS sa stabilnom adresom, ili upotrijebiti overlay koji drži vlastiti susret. Ako je adresa statična, preskočite ažurator: jedan A zapis, jedan AAAA zapis ako rabite IPv6, isto prosljeđivanje porta.

Ako se adresa mijenja dok klijenti ostaju spojeni, iskreni popravak živi na klijentu: logika ponovnog spajanja i interval ponovnog pokušaja, a ne brži ažurator. Drugi davatelj samo skriva interval.

Prije nego krenete dalje, potvrdite četiri stvari po redu:

  • Adresa koju ažurator objavljuje podudara se s WAN adresom usmjerivača.
  • TTL zapisa dovoljno je kratak da se promjena pojavi u minutama.
  • Prosljeđivanje porta vezano je za sučelje, ne za fiksnu adresu.
  • Jedan stvarni klijent ponovno se spojio i propustio promet nakon zadnje promjene.

Ako sve četiri drži, ostavite postavku na miru; vaš sljedeći kvar je ključ ili pravilo vatrozida, a ne problem s imenovanjem. Ako bilo što padne, popravite taj red prije nego dodate još jedan pokretni dio. RFC 2136 opisuje sam mehanizam ažuriranja, ako želite vidjeti što daemon stavlja na žicu.

Povezani članci