Ali potrebujete dinamični DNS za domači VPN strežnik?

Večina okvar domačega VPN, o katerih me sprašujejo, ni okvar DNS, pa vendar ljudje najprej kupijo naročnino na dinamični DNS. Preden karkoli nastavite, se odločite, ali je ime gostitelja tisti del, ki je res zlomljen. Posodabljalnik prepiše zapis, ko se naslov, ki vam ga je dal ponudnik, premakne; ne more odpreti vrat, priti skozi NAT operaterja ali doseči, da bi aktivna seja WireGuard opazila, da se je končna točka spremenila. Trije pogoji odločijo, ali je dinamični DNS celotna rešitev ali le ena njena vrstica.

Prvi pogoj: vaš naslov se res premika

Domači naslovi se premikajo iz vsakdanjih razlogov: modem se po izpadu elektrike znova sinhronizira, ponudnik prerazporedi bazen, po dolgem izpadu pride nova najem. Na nekaterih vodih se premikajo tudi redko, in videl sem isti naslov zdržati leto; poslovni paketi pogosto vključujejo statičnega. Če se v dvanajstih mesecih ni nič spremenilo, je en ročno urejen zapis A en demon manj, ki ga je treba ohranjati pri življenju.

Izmerite, namesto da ugibate. Preberite naslov WAN na statusni strani usmerjevalnika in ga primerjajte s tem, kar vidi zunanji svet. Zaženite to s stroja v LAN:

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

Če se vrednosti razlikujeta, nekaj prevaja pred vašim usmerjevalnikom in nobena posodobitev imena gostitelja tega ne popravi. Naslov znotraj 100.64.0.0/10 je skupni razpon za NAT na ravni operaterja, in to je običajen razlog, da pravilno posodobljeno ime od zunaj vseeno poteče.

Drugi pogoj: odjemalci ime znova razrešijo

Kratek TTL je del, ki ga ljudje preskočijo. Rekurzivni razreševalniki spoštujejo TTL zapisa, a odjemalski skladi predpomnijo ločeno in že postavljen tunel ničesar znova ne razreši. Med odpravljanjem napak nastavite zapis na 60-300 sekund; to skrajša okno, v katerem se streže zastarel odgovor, in ne preseli povezane seje.

OpenVPN ob vsaki ponovni povezavi znova razreši vrstico remote vpn.example.net 1194 , in resolv-retry infinite ga sili k ponovnemu poskušanju, namesto da bi končal, ko iskanje spodleti. Na strežniku float omogoči vzpostavljeni seji, da sledi partnerju, katerega izvorni naslov se je spremenil. WireGuard je bolj neposreden: wg-quick up ob uporabi konfiguracije razreši Endpoint končno točko, odjemalec pa jo znova razreši, ko znova zgradi tunel, zato rokovanje, ki še uspeva proti staremu naslovu, uspeva, dokler se ne ustavi.

Ta razlika oblikuje načrt. Če se odjemalci povezujejo na zahtevo, sprememba naslova stane eno ponovno povezavo. Če držijo sejo odprto dneve, pričakujte, da bo tunel umrl ob naslednjem rokovanju, in naj odjemalec poskusi znova, namesto da predpostavljate, da ostane.

Tretji pogoj: vhodna pot je še odprta

Dinamični DNS spremeni le, kam kaže ime, in nič drugega. Posredovanje vrat na usmerjevalniku, pravilo požarnega zidu na gostitelju VPN in dovoljenje ponudnika za dohodne pakete morajo obstajati, preden zapis kaj pomeni. Poglejte, kam cilja posredovanje: če je pripeto na naslov WAN namesto na vmesnik, sprememba naslova tiho zlomi posredovanje in zapis nosi krivdo.

Preizkusite od zunaj. Telefon na mobilnih podatkih z izklopljenim Wi-Fi je najcenejši pošten preizkus; prenosnik v istem LAN ni. Ko se ime razreši na vaš javni naslov in usmerjevalnik nima zanke NAT, notranji preizkus spodleti, medtem ko je zapis povsem pravilen, in to pošlje večino ljudi urejat zapis, ki nikoli ni bil napačen.

Kaj zagnati, ko vse tri veljajo

ddclient je najmanj presenetljiv posodabljalnik za majhnega gostitelja. Minimalna konfiguracija objavi naslov, ki ga vidi ponudnik, in s tem zaobide napako dvojnega 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

Zaženite ga iz časovnika systemd vsakih nekaj minut namesto iz lupine shell, in beležite odgovor ponudnika, namesto da predpostavljate uspeh. S poverilnico ravnajte kot s ključem, ker odloča, kam je poslan vsak odjemalec: uporabite omejen žeton za posodabljanje namesto gesla računa, hranite datoteko v načinu 0600 in pošiljajte posodobitve po HTTPS.

Preverite, preden se zavežete

Eno poizvedovanje vam pove, kaj vidi preostali svet, in izpiše TTL, ki ga morate po spremembi počakati:

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

Primerjajte ta naslov z naslovom WAN usmerjevalnika. Če se ujemata, ime opravlja svoje delo in kar še spodleti, je dohodna dosegljivost, ključ ali odjemalec, ki ni znova razrešil. Če se razlikujeta, posodabljalnik objavlja napačen vmesnik, pogosto zato, ker je tekel na gostitelju VPN za usmerjevalnikom namesto na samem usmerjevalniku.

Imejte razveljavitev, ki traja minuto: zapišite zadnji delujoči naslov in prejšnji TTL, da lahko oba objavite ročno, medtem ko ima ponudnik slab popoldan.

Ko je odgovor ne

Če prvi ali tretji pogoj spodleti, se spremeni odločitev, ne konfiguracija. Za NAT operaterja so praktične možnosti prositi ponudnika za javni naslov, premakniti vstopno točko na majhen VPS s stabilnim naslovom, ali uporabiti prekrivno plast, ki drži svoje srečanje. Če je naslov statičen, posodabljalnik izpustite: en zapis A, en zapis AAAA, če uporabljate IPv6, isto posredovanje vrat.

Če se naslov spremeni, medtem ko odjemalci ostanejo povezani, poštena poprava živi v odjemalcu: logika ponovnega povezovanja in interval poskušanja, ne hitrejši posodabljalnik. Drugi ponudnik samo skrije interval.

Preden nadaljujete, potrdite štiri stvari po vrsti:

• Naslov, ki ga objavlja posodabljalnik, se ujema z naslovom WAN usmerjevalnika.
• TTL zapisa je dovolj kratek, da se sprememba pokaže v nekaj minutah.
• Posredovanje vrat je vezano na vmesnik, ne na fiksni naslov.
• En resnični odjemalec se je od zadnje spremembe znova povezal in prepustil promet.

Če vse štiri veljajo, pustite nastavitev pri miru; vaša naslednja okvara je ključ ali pravilo požarnega zidu in ne težava z imenovanjem. Če katera spodleti, popravite tisto vrstico, preden dodate še en gibajoči del. RFC 2136 opisuje sam mehanizem posodabljanja, če želite videti, kaj demon položi na žico.