ddclient publica la sortida VPN: corregeix la font de descoberta

El vostre nom DNS ara es resol a una adreça del proveïdor VPN, i el registre d'actualitzacions sembla del tot sa. Aquesta combinació és normal. Una sonda de descoberta basada en web pregunta a un servei extern quina font veu, i quan la petició surt per un túnel VPN complet, la resposta és la sortida VPN, no la vostra adreça WAN de casa. L'actualitzador va fer la seva feina; la feina apuntava a una observació equivocada.

Confirmeu a què ha d'arribar el nom

Un nom públic per a un servei domèstic d'entrada necessita una adreça per la qual les connexions entrants aprovades puguin arribar a aquest servei. Publicar una sortida compartida del proveïdor no hi organitza cap reenviament entrant, i cap quantitat de configuració DNS crea aquest reenviament. Decidiu-ho abans de tocar l'actualitzador, perquè determina quina adreça és la correcta.

Un nom privat per a l'adreça del túnel d'un client VPN és un altre problema amb una altra resposta: pertany al DNS privat i no necessita cap servei públic de descoberta. Barrejar els dos requisits és com una configuració que funciona comença a publicar una adreça que ningú no ha demanat.

Les adreces d'interfície també necessiten interpretació. L'adreça d'un portàtil darrere d'un router domèstic no és l'adreça WAN pública, i fins i tot l'adreça WAN del router pot estar darrere de NAT de nivell operador, on publicar-la no pot produir accessibilitat entrant.

Reproduïu el valor abans de canviar res

Observeu els dos camins per separat. Amb el túnel aixecat, una sonda informa de la sortida; amb el túnel baixat, o amb la sonda lligada a la interfície física, informa de l'adreça de casa: curl --interface eth0 https://ifconfig.me. Si aquestes dues respostes difereixen, heu reproduït la falla sense tocar l'actualitzador.

Després executeu el client en un mode que comprovi la configuració sense fer cap actualització, com ara ddclient -verbose -noexec, i llegiu quin mètode de descoberta ha triat. La sortida detallada indica el mètode i el valor obtingut, i aquest és el fet que necessiteu abans d'editar res.

Dirigiu la descoberta al camí triat

Si el nom ha de publicar l'adreça WAN de casa, la descoberta ha d'observar aquesta adreça. Funcionen tres opcions, en ordre aproximat de preferència: deixeu que el router publiqui amb el seu propi actualitzador compatible; feu servir la descoberta d'estat del router de ddclient contra una pàgina que el router serveixi de debò; o manteniu una sonda web però lligueu-la a la interfície física perquè surti fora del túnel.

Per a la via de l'estat del router, les versions noves de ddclient fan servir la família d'opcions usev4 i fwv4, amb un patró d'omissió opcional per al text del voltant de la pàgina. Consulteu el README de la versió instal·lada, perquè les versions antigues escriuen la mateixa idea amb use i fw, i un nom d'opció copiat de la versió equivocada falla en arrencar.

Si manteniu la descoberta web, recordeu que encaminar la sonda i encaminar la crida a l'API d'actualització són decisions separades. La crida d'actualització lliura el registre; la sonda decideix el valor que es lliurarà.

Mantingueu els secrets i les versions en ordre

Les credencials del router i els testimonis del proveïdor van en un fitxer de configuració protegit, no en una línia d'ordres que acabi a l'historial del shell. Els traços detallats poden contenir tots dos, així que redacteu-los abans d'enganxar-los en un tiquet. Un mètode de descoberta que exigeix extreure una pàgina autenticada del router també exigeix que aquesta credencial segueixi funcionant després d'actualitzacions de firmware. Guardeu-la amb la mateixa cura que el testimoni del proveïdor.

El ddclient README documenta els enfocaments de descoberta i els seus noms d'opció. No barregeu resultats d'IPv4 i d'IPv6 en un sol registre, i no assumiu que una opció present en una versió existeixi en una altra.

Verifiqueu el valor i després l'accessibilitat

Compareu l'adreça proposada amb el punt final previst abans de permetre una actualització en viu, després comproveu el DNS autoritatiu després d'una actualització autoritzada i compteu amb les memòries cau dels resolutors. Un TTL baix escurça l'espera; no fa bona una adreça equivocada.

Només quan el registre sigui correcte hauríeu de provar el servei d'entrada des d'una xarxa independent, amb el tallafoc i el reenviament necessaris ja aprovats. Un registre A correcte no demostra un servei accessible, i un arrendament VPN estàtic pot simplificar l'assignació de noms privada sense reparar un nom d'amfitrió públic que apunta a la WAN equivocada.