Behar al duzu DNS dinamikoa etxeko VPN zerbitzari baterako?

Jendeak galdetzen dizkidan etxeko VPN hutsegite gehienak ez dira DNS hutsegiteak, eta hala ere DNS dinamikoko harpidetza erosten dute lehenengo. Edozer konfiguratu aurretik, erabaki ostalari-izena ote den benetan hondatuta dagoen zatia. Eguneratzaile batek erregistroa berridazten du ISP-ak eman zizun helbidea aldatzen denean; ezin ditu portuak ireki, ez garraiolariaren NAT zeharkatu, ez eta WireGuard saio bizirik nabari dezan bere mutur-puntua aldatu dela. Hiru baldintzek erabakitzen dute DNS dinamikoa konponbide osoa den edo haren lerro bat baino ez.

Lehen baldintza: zure helbidea benetan aldatzen da

Etxebizitza-helbideak arrazoi arruntekin aldatzen dira: modemak berriz sinkronizatzen du argindar-etena ondoren, ISP-ak igerilekua orekatzen du, errentamendu berria iristen da eten luze baten ondoren. Lerro batzuetan oso gutxitan ere aldatzen dira, eta helbide berak urte osoa iraun zuela ikusi dut; enpresa-planek estatiko bat izaten dute sarri. Hamabi hilabetean ezer aldatu ez bada, eskuz editatzen duzun A erregistro bakarra daemon bat gutxiago da bizirik mantentzeko.

Neurtu, ez asmatu. Irakurri WAN helbidea routerraren egoera-orrian, eta alderatu kanpoko munduak ikusten duenarekin. Exekutatu hau LANeko makinatik:

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

Bi balioak desberdinak badira, zerbait itzultzen ari da zure routerraren aurrean eta ostalari-izenaren edozein eguneraketak ez du hori konponduko. 100.64.0.0/10 barrutiko helbidea garraiolari-mailako NAT-rako partekatutako tartea da, eta hori da behar bezala eguneratutako izen batek kanpotik oraindik denbora-muga jotzen duen arrazoi ohikoa.

Bigarren baldintza: bezeroek berriro ebazten dute izena

TTL laburra da jendeak saltatzen duen zatia. Resolver errekurtsiboek erregistroaren TTL errespetatzen dute, baina bezero-pilek bereiz gordetzen dute cachean, eta jada altxatuta dagoen tunel batek ez du ezer berriro ebazten. Ezarri erregistroa 60-300 segundotan araztean; horrek erantzun zaharra ematen den leihoa laburtzen du eta ez du konektatutako saioa migratzen.

OpenVPN tresnak lerroa berriro ebazten du remote vpn.example.net 1194 konektatzen den bakoitzean, eta resolv-retry infinite berriro saiatzera behartzen du, bilaketak huts egiten duenean irten beharrean. Zerbitzarian, float ahalbidetzen dio ezarritako saioari jatorrizko helbidea aldatu duen parekideari jarraitzea. WireGuard zuzenagoa da: wg-quick up tresnak Endpoint ebazten du konfigurazioa aplikatzean, eta bezeroak berriro ebazten du tunela berreraikitzen duenean, beraz helbide zaharrarekin oraindik arrakasta duen esku-emateak arrakasta izaten jarraitzen du gelditu arte.

Alde horrek plana eratzen du. Bezeroak eskaeran konektatzen badira, helbide-aldaketak berriz konektatze bat kostatzen du. Saioa egunak zabalik mantentzen badute, espero tunela hurrengo esku-ematean hiltzea, eta egin bezeroak berriro saia dadin, altxatuta jarraitzen duela suposatu beharrean.

Hirugarren baldintza: sarbide-bidea oraindik zabalik dago

DNS dinamikoak izena norantz seinalatzen duen baino ez du aldatzen, eta besterik ez. Routerraren portu-birbidalketa, VPN ostalariaren suebaki-araua eta ISP-ak sarrerako paketeak onartzea guztiek existitu behar dute erregistroak garrantzia izan aurretik. Begiratu birbidalketak zeri egiten dion: WAN helbide bati lotuta badago, interfazeari eta ez, helbide-aldaketak isilean hausten du birbidalketa eta erregistroak hartzen du errua.

Probatu kanpotik. Wi-Fi itzalita duen datu mugikorreko telefonoa da probarik merkeena eta zintzoena; LAN bereko eramangarri bat ez da. Izena zure helbide publikora ebazten denean eta routerrak NAT begiztarik ez duenean, barruko proba batek huts egiten du erregistroa erabat zuzena den arren, eta horrek jende gehiena inoiz oker egon ez den erregistro bat editatzera bidaltzen du.

Zer exekutatu hirurak betetzen direnean

ddclient da ostalari txiki baterako eguneratzaile gutxien harritzen duena. Konfigurazio minimal batek hornitzaileak ikusten duen helbidea argitaratzen du, eta horrek NAT bikoitzaren akatsa saihesten du:

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

Exekutatu systemd tenporizadore batetik minutu batzuro, shell begizta baten ordez, eta erregistratu hornitzailearen erantzuna, arrakasta suposatu beharrean. Tratatu kredentziala giltza bat bezala, zeren hark erabakitzen baitu bezero bakoitza nora bidaltzen den: erabili eguneratzeko token mugatua kontuko pasahitzaren ordez, mantendu fitxategia 0600 moduan eta bidali eguneraketak HTTPS bidez.

Egiaztatu konprometitu aurretik

Bilaketa batek esaten dizu gainerako munduak zer ikusten duen, eta aldaketa baten ondoren itxaron behar duzun TTL inprimatzen du:

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

Alderatu helbide hori routerraren WAN helbidearekin. Bat egiten badute, izenak bere lana egiten du eta oraindik huts egiten duena sarrerako irisgarritasuna, giltza bat edo berriro ebatzi ez duen bezero bat da. Desberdinak badira, eguneratzaileak interfaze okerra argitaratzen du, sarri routerraren atzean dagoen VPN ostalarian exekutatu zelako, routerrean bertan eta ez.

Mantendu minutu bateko atzera-egitea: idatzi azken helbide erabilgarria eta aurreko TTL, biak eskuz argitaratu ahal izateko hornitzaileak arratsalde txarra duen bitartean.

Erantzuna ezezkoa denean

Lehen edo hirugarren baldintzak huts egiten badu, erabakia aldatzen da, ez konfigurazioa. Garraiolariaren NAT atzean, zure aukera praktikoak ISP-ari helbide publiko bat eskatzea, sarbide-puntua helbide egonkorra duen VPS txiki batera mugitzea, edo bere topaketa propioa mantentzen duen estaldura bat erabiltzea dira. Helbidea estatiko bada, saltatu eguneratzailea: A erregistro bat, AAAA erregistro bat IPv6 erabiltzen baduzu, portu-birbidalketa bera.

Helbidea aldatzen bada bezeroak konektatuta jarraitzen duten bitartean, konponbide zintzoa bezeroan bizi da: berriz konektatzeko logika eta errepikatzeko tartea, ez eguneratzaile azkarragoa. Bigarren hornitzaile bat gehitzeak tartea baino ez du ezkutatzen.

Aurrera egin aurretik, berretsi lau gauza ordenan:

• Eguneratzaileak argitaratzen duen helbidea routerraren WAN helbidearekin bat dator.
• Erregistroaren TTL nahikoa laburra da aldaketak minutu batzutan ager dadin.
• Portu-birbidalketa interfazeari lotuta dago, ez helbide finko bati.
• Benetako bezero batek berriro konektatu du eta trafikoa igaro du azken aldaketaz geroztik.

Lauak betetzen badira, utzi konfigurazioa bakean; zure hurrengo hutsegitea giltza bat edo suebaki-arau bat da, ez izendatze-arazo bat. Norbaitek huts egiten badu, konpondu errenkada hori beste pieza mugikor bat gehitu aurretik. RFC 2136 berak deskribatzen du eguneratze-mekanismoa, daemonak kablean zer jartzen duen ikusi nahi baduzu.