Un rexistro DDNS obsoleto fronte a un extremo VPN roto: como distinguilos

Desde fóra, un nome de host obsoleto e unha VPN rota parecen idénticos. O cliente resolve un nome, o nome apunta a algún sitio e a conexión expira ou rexéitase. Un é un problema de actualización do DNS e o outro é un problema de autenticación ou de reenvío, e a diferenza só se fai evidente cando compara o enderezo publicado co enderezo que a súa liña ten en realidade.

Dous fallos que se presentan igual

O primeiro fallo é que o rexistro aínda lista o enderezo WAN de onte. O segundo é que o rexistro é correcto e o túnel rexéitao por motivos propios. Ambos producen a mesma mensaxe no cliente, e a tentación é comezar a rexenerar certificados.

A orde importa aquí. Comprobar o DNS leva un minuto e é reversible. Rexenerar unha CA non é nin unha cousa nin a outra.

Compare os enderezos antes que nada

Pregunte ao propietario da rede que enderezo ten a liña agora mesmo e logo pregunte ao DNS que publica. dig +short vpn.example.com dá a resposta que recibirá o seu cliente, e dig @1.1.1.1 vpn.example.com mostra se outro resolutor ve algo distinto. Se eses dous non coinciden, está a ver comportamento de caché e non un actualizador roto.

Unha resposta recursiva pode quedarse atrás respecto a unha actualización polo seu TTL, así que manteña o rexistro autoritativo e o que o seu portátil almacenou en caixas separadas.

Que é realmente a credencial do actualizador

Os dispositivos DDNS antigos adoitan autenticarse co propio contrasinal da conta, e por iso cambialo rompeos en silencio. Seguen reintentando co valor antigo e non informan de nada útil. A guía de contrasinais de dispositivo de No-IP documenta exactamente este problema de compatibilidade en hardware antigo, e a resposta sensata é unha credencial de actualización de alcance limitado en lugar dun contrasinal de conta máis feble.

Os mecanismos máis novos emiten un token ou clave de actualización aparte co seu propio ciclo de vida. Ese é o valor que hai que rotar no router e o que hai que rexistrar no seu inventario de credenciais. Tampouco é o valor que convén pegar nun fío de chat mentres depura.

Revise o estado non secreto do actualizador: hora do último éxito, categoría de resposta e o nome de host que cre posuír. Un rexeitamento de credencial e un fallo de conectividade necesitan correccións distintas.

Que non pode facer unha corrección de DNS

Corrixir o rexistro non crea accesibilidade entrante. Se a liña está detrás de NAT de nivel de operador, ningún nome de host fará que funcione unha conexión entrante. Tampouco abre unha regra de cortalumes nin reenvía un porto. E nunca é unha razón para desactivar a verificación do servidor no cliente, que é o movemento que fai a xente cando decide que o certificado debe ser o problema.

Á inversa, cambiar o contrasinal da VPN non é unha corrección para un DNS obsoleto. Só engade un segundo fallo ao mesmo tícket.

Reconecte e demóstreo de extremo a extremo

Cando o rexistro autoritativo sexa correcto, o cliente pode conservar aínda unha consulta antiga. Use a súa reconexión ou refresco de extremo compatible e déalle un momento en lugar de machucar conectar. Despois demostre a ruta en catro pasos: resolva o nome, confirme o enderezo, comprobe que se alcanza o receptor e autentíquese. Catro resultados separados, catro respostas separadas.

Manteña o actualizador na lista de verificación de rotación xunto á conta da VPN. Un propietario de rexistro previsto, unha credencial válida e un éxito observable é o que evita a seguinte versión deste tícket.