Hast dynamyske DNS nedich foar in thús-VPN-tsjinner?

Dynamyske DNS reparearret de namme, net it paad nei binnen. Trije kontrôles beslisse oft in hostnamme genôch is foar in thús-VPN-tsjinner of oft de rûte nei binnen stikken is.

De measte thús-VPN-fouten dêr't minsken my oer freegje binne gjin DNS-fouten, en dochs keapje se earst in dynamyske DNS-abonnemint. Foardat jo wat konfigurearje, beslút oft de hostnamme it part is dat echt stikken is. In fernijer skriuwt in record oer as it adres dat jo ISP jo joech ferskoot; hy kin gjin poarte iepenje, net troch carrier-NAT komme en gjin libbene WireGuard-sesje merke litte dat syn einpunt feroare is. Trije betingsten beslisse oft dynamyske DNS de hiele oplossing is of mar ien rigel derfan.

Betingst ien: jo adres ferskoot echt

Wenthúsadressen ferskoot om gewoane redenen: de modem synchronisearret wer nei in stroomûnderbrekking, de ISP balansearret in pool opnij, in nij lease komt nei in lange steuring. Op guon linen ferskoot se ek mar komselden, en ik haw itselde adres in jier oerlibje sjoen; saaklike pakketten befetsje faak in statyske. As der yn tolve moannen neat feroare is, is ien A-record dat jo mei de hân bewurkje ien daemon minder om libben te hâlden.

Mjit it ynstee fan te rieden. Lês it WAN-adres op 'e statusside fan de router en fergelykje it mei wat de bûtenwrâld sjocht. Rin dit fan in masine op 'e LAN:

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

As de twa wearden ferskille, fertaalt der wat foar jo router en gjin hostnamme-update sil dat reparearje. In adres binnen 100.64.0.0/10 is it dielde berik foar NAT op carrier-nivo, en dat is de gewoane reden wêrom't in korrekt bywurke namme fan bûten dochs tiid útrint.

Betingst twa: klanten sykje de namme wer op

In koarte TTL is it part dat minsken oerslaan. Rekursive resolvers respektearje de TTL fan it record, mar klantstapels cacheje apart, en in tunnel dy't al oerein stiet liset neat wer op. Set it record op 60-300 sekonden wylst jo debugearje; dat ferkoartet it finster wêryn in ferâldere antwurd tsjinne wurdt, en it migrearret gjin ferbûne sesje.

OpenVPN liset de rigel remote vpn.example.net 1194 by elke werferbining opnij op, en resolv-retry infinite hâldt it opnij besykjen ynstee fan te stopjen as it oplysjen mislearret. Op 'e tsjinner lit float in festige sesje in peer folgje waans boarneadres feroare is. WireGuard is rjochter: wg-quick up liset de Endpoint op as de konfiguraasje tapast wurdt, en de klant liset him wer op as er de tunnel wer opbouwt, dus in hânskud dat noch slagget tsjin it âlde adres bliuwt slagje oant it stopet.

Dat ferskil foarmet it plan. As klanten op oanfraach ferbine, kostet in adresferoaring ien werferbining. As se in sesje dagen iepen hâlde, ferwachtsje dan dat de tunnel by it folgjende hânskud stjert, en lit de klant opnij besykje ynstee fan oan te nimmen dat er oerein bliuwt.

Betingst trije: it paad nei binnen is noch iepen

Dynamyske DNS feroaret allinne wêr't de namme nei wiist en neat oars. De portforwarding op 'e router, de firewallregel op 'e VPN-host en it tastean fan ynkommende pakketten troch de ISP moatte allegear bestean foardat it record fan belang is. Sjoch wêr't de forwarding op rjochtet: as it oan in WAN-adres fêst sit ynstee fan oan de interface, brekt in adresferoaring de forwarding stil en krijt it record de skuld.

Test fan bûten. In telefoan op mobyl data mei Wi-Fi út is de goedkeapste earlike test; in laptop op deselde LAN is dat net. As de namme nei jo iepenbiere adres oplost en de router hat gjin NAT-loopback, mislearret in test fan binnen wylst it record folslein korrekt is, en dat stjoert de measte minsken om in record te bewurkjen dat nea ferkeard wie.

Wat te draaien as alle trije jilde

ddclient is de minst ferrassende fernijer foar in lytse host. In minimale konfiguraasje publisearret it adres dat de provider sjocht, wat de dûbele-NAT-flater foarkomt:

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

Draai it fan in systemd-timer elke pear minuten ynstee fan in shell-lus, en logje it antwurd fan de provider ynstee fan súkses oan te nimmen. Behannelje de credential as in kaai, want dy beslút wêr't elke klant hinne stjoerd wurdt: brûk in beheind update-token ynstee fan in accountwachtwurd, hâld it bestân op modus 0600 en stjoer updates oer HTTPS.

Kontrolearje foardat jo fêstlizze

Ien opsykjen fertelt jo wat de rest fan 'e wrâld sjocht, en it printsjelet de TTL dy't jo nei in feroaring útwachtsje moatte:

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

Fergelykje dat adres mei it WAN-adres fan 'e router. As se oerienkomme, docht de namme syn wurk en wat noch mislearret is ynkommende berikberens, in kaai of in klant dy't net wer oplost hat. As se ferskille, publisearret de fernijer de ferkearde interface, faak om't er op 'e VPN-host efter de router rûn ynstee op 'e router sels.

Hâld in weromset dy't in minút duorret: skriuw it lêste wurkjende adres en de foarige TTL op, sadat jo beide mei de hân publisearje kinne wylst de provider in min middei hat.

As it antwurd nee is

As betingst ien of trije mislearret, feroaret de beslissing ynstee fan de konfiguraasje. Efter carrier-NAT binne jo praktyske opsjes de ISP om in iepenbier adres freegje, it yngongspunt nei in lytse VPS mei in stabyl adres ferpleatse, of in overlay brûke dy't syn eigen moetingsplak hâldt. As it adres statysk is, slaan de fernijer oer: ien A-record, ien AAAA-record as jo IPv6 draaie, deselde portforwarding.

As it adres feroaret wylst klanten ferbûn bliuwe, wennet de earlike oplossing by de klant: werferbyningslogika en in werbesykynterval, net in fluggere fernijer. In twadde provider taheakje ferberget allinne it ynterval.

Foardat jo fierder gean, befestigje fjouwer dingen yn folchoarder:

  • It adres dat de fernijer publisearret komt oerien mei it WAN-adres fan 'e router.
  • De TTL fan it record is koart genôch dat in feroaring binnen minuten te sjen is.
  • De portforwarding is bûn oan 'e interface, net oan in fêst adres.
  • Ien echte klant hat him sûnt de lêste feroaring wer ferbûn en ferkear trochlitten.

As alle fjouwer jilde, lit de opset dan gewurde; jo folgjende flater is in kaai of in firewallregel en gjin nammeprobleem. As ien mislearret, reparearje dy rige foardat jo noch in bewegend part tafoegje. RFC 2136 beskriuwt it fernijingsmeganisme sels, as jo sjen wolle wat de daemon op 'e tried set.

Relatearre artikelen