Ĉu vi bezonas dinamikan DNS por hejma VPN-servilo?

Dinamika DNS riparas la nomon, ne la eniron. Tri kontroloj decidas ĉu gastnomo sufiĉas por hejma VPN-servilo aŭ ĉu la enira vojo estas rompita.

Plej multaj hejmaj VPN-malsukcesoj pri kiuj oni demandas min ne estas DNS-malsukcesoj, kaj tamen ili unue aĉetas abonon al dinamika DNS. Antaŭ ol agordi ion ajn, decidu ĉu la gastnomo estas la parto kiu efektive rompiĝis. Ĝisdatigilo reskribas rikordon kiam la adreso kiun via provizanto donis al vi moviĝas; ĝi ne povas malfermi pordon, trapasi la NAT de la operatoro, nek igi vivan WireGuard-seancon rimarki ke ĝia finpunkto ŝanĝiĝis. Tri kondiĉoj decidas ĉu dinamika DNS estas la tuta solvo aŭ nur unu linio de ĝi.

Kondiĉo unu: via adreso efektive moviĝas

Loĝejaj adresoj moviĝas pro ordinaraj kaŭzoj: la modemo resinkronigas post malŝalto de elektro, la provizanto reekvilibrigas naĝejon, nova luo alvenas post longa interrompo. Ili ankaŭ malofte moviĝas sur iuj linioj, kaj mi vidis la saman adreson pluvivi jaron; komercaj planoj ofte inkluzivas statikan. Se nenio ŝanĝiĝis dum dek du monatoj, unu rikordo A kiun vi redaktas mane estas unu demono malpli por teni viva.

Mezuru anstataŭ diveni. Legu la WAN-adreson sur la statusa paĝo de la enkursigilo, poste komparu ĝin kun tio kion vidas la ekstera mondo. Rulu ĉi tion de maŝino en la LAN:

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

Se la du valoroj diferencas, io tradukas antaŭ via enkursigilo kaj neniu gastnoma ĝisdatigo riparos tion. Adreso ene de 100.64.0.0/10 estas la kunhava gamo por NAT de la operatora nivelo, kaj tio estas la kutima kaŭzo kial ĝuste ĝisdatigita nomo ankoraŭ tempolimas de ekstere.

Kondiĉo du: klientoj reesploras la nomon

Mallonga TTL estas la parto kiun homoj preterlasas. Rikuraj solvantoj respektas la TTL de la rikordo, sed klientaj stakoj kaŝmemoras aparte, kaj tunelo kiu jam staras reesploras nenion. Agordu la rikordon al 60-300 sekundoj dum vi sencimigas; tio mallongigas la fenestron en kiu malnova respondo estas servata, kaj ĝi ne migras konektitan seancon.

OpenVPN reesploras la linion remote vpn.example.net 1194 ĉiufoje kiam ĝi rekonektiĝas, kaj resolv-retry infinite igas ĝin reprovi anstataŭ eliri kiam la esploro malsukcesas. Sur la servilo, float permesas al establita seanco sekvi samtavolanon kies fontadreso ŝanĝiĝis. WireGuard estas pli senpera: wg-quick up esploras la Endpoint kiam la agordo aplikiĝas, kaj la kliento esploras ĝin denove kiam ĝi rekonstruas la tunelon, do manpremo kiu ankoraŭ sukcesas kontraŭ la malnova adreso daŭre sukcesas ĝis ĝi haltas.

Tiu diferenco formas la planon. Se klientoj konektiĝas laŭbezona, adresa ŝanĝo kostas unu rekonekton. Se ili tenas seancon malfermita dum tagoj, atendu ke la tunelo mortos ĉe la sekva manpremo, kaj igas la klienton reprovi anstataŭ supozi ke ĝi restas supre.

Kondiĉo tri: la enira vojo ankoraŭ estas malfermita

Dinamika DNS ŝanĝas nur kien la nomo montras kaj nenion alian. La pordadreso sur la enkursigilo, la fajroŝirma regulo sur la VPN-gastiganto kaj la permeso de la provizanto al eniraj pakaĵoj ĉiuj devas ekzisti antaŭ ol la rikordo gravas. Rigardu kion celas la pordadreso: se ĝi estas fiksita al WAN-adreso anstataŭ al la interfaco, adresa ŝanĝo rompas la pordadreson silente kaj la rikordo ricevas la kulpon.

Testu de ekstere. Telefono sur poŝtelefona datumo kun Wi-Fi malŝaltita estas la plej malmultekosta honesta testo; tekkomputilo en la sama LAN ne estas. Kiam la nomo solviĝas al via publika adreso kaj la enkursigilo ne havas NAT-buklon, interna testo malsukcesas dum la rikordo estas tute ĝusta, kio sendas plej multajn homojn redakti rikordon kiu neniam estis malĝusta.

Kion ruli kiam ĉiuj tri validas

ddclient estas la malplej surpriza ĝisdatigilo por malgranda gastiganto. Minimuma agordo publikigas la adreson kiun vidas la provizanto, kio evitas la eraron de duobla 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

Rulu ĝin de systemd-tempigilo ĉiujn kelkajn minutojn anstataŭ per ŝela buklo, kaj protokolu la respondon de la provizanto anstataŭ supozi sukceson. Traktu la akreditaĵon kiel ŝlosilon, ĉar ĝi decidas kien ĉiu kliento estas sendata: uzu limigitan ĝisdatigan ĵetonon anstataŭ konta pasvorto, tenu la dosieron en reĝimo 0600, kaj sendu ĝisdatigojn per HTTPS.

Kontrolu antaŭ ol vi devontigi vin

Unu esploro diras al vi kion vidas la resto de la mondo, kaj ĝi presas la TTL kiun vi devas atendi post ŝanĝo:

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

Komparu tiun adreson kun la WAN-adreso de la enkursigilo. Se ili kongruas, la nomo faras sian taskon kaj tio kio ankoraŭ malsukcesas estas enira atingeblo, ŝlosilo aŭ kliento kiu ne reesploris. Se ili diferencas, la ĝisdatigilo publikigas la malĝustan interfacon, ofte ĉar ĝi kuris sur la VPN-gastiganto malantaŭ la enkursigilo anstataŭ sur la enkursigilo mem.

Tenu restarigon kiu daŭras minuton: notu la lastan funkciantan adreson kaj la antaŭan TTL, por ke vi povu publikigi ambaŭ mane dum la provizanto havas malbonan posttagmezon.

Kiam la respondo estas ne

Se kondiĉo unu aŭ tri malsukcesas, ŝanĝiĝas la decido, ne la agordo. Malantaŭ la NAT de la operatoro viaj praktikaj ebloj estas peti la provizanton pri publika adreso, movi la enirpunkton al malgranda VPS kun stabila adreso, aŭ uzi supertavolon kiu tenas sian propran renkontiĝon. Se la adreso estas statika, preterlasu la ĝisdatigilon: unu rikordo A, unu rikordo AAAA se vi uzas IPv6, la sama pordadreso.

Se la adreso ŝanĝiĝas dum klientoj restas konektitaj, la honesta ripeto loĝas ĉe la kliento: rekonekta logiko kaj intervalo de reprovo, ne pli rapida ĝisdatigilo. Dua provizanto nur kaŝas la intervalon.

Antaŭ ol daŭrigi, konfirmu kvar aferojn laŭ ordo:

  • La adreso kiun la ĝisdatigilo publikigas kongruas kun la WAN-adreso de la enkursigilo.
  • La TTL de la rikordo estas sufiĉe mallonga por ke ŝanĝo aperu ene de minutoj.
  • La pordadreso estas ligita al la interfaco, ne al fiksita adreso.
  • Unu reala kliento rekonektiĝis kaj pasigis trafikon de post la lasta ŝanĝo.

Se ĉiuj kvar validas, lasu la agordon trankvila; via sekva malsukceso estas ŝlosilo aŭ fajroŝirma regulo, ne nomada problemo. Se iu malsukcesas, ripetu tiun vicon antaŭ ol aldoni plian moviĝantan parton. RFC 2136 priskribas la ĝisdatigan mekanismon mem, se vi volas vidi kion la demono metas sur la draton.

Rilataj artikoloj