Nome de punto final de VPN fronte a nome de servizo privado: dous responsables

Dous nomes poden describir a mesma sucursal e responder preguntas completamente distintas. vpn.branch.example indica a un par remoto onde atopar o punto final de VPN, e debe resolverse antes de que exista ningún túnel. inventory.branch.example indica a un usuario autorizado onde vive unha aplicación privada, e só importa unha vez que o túnel está levantado. Manter un deles non fai nada polo outro.

Nomee os dous rexistros antes de depurar calquera deles

Anote ambos cos seus responsables. Para o punto final, rexistre quen actualiza o enderezo público e como o cliente VPN refresca a súa resposta. Para o servizo, rexistre quen posúe o enderezo privado, que zona contén o rexistro e que resolutores deben responder por el.

Esa lista curta evita o diagnóstico erróneo máis común neste ámbito: reiniciar un túnel de sucursal que funciona para reparar un rexistro que vive por completo dentro del. O túnel é o transporte do nome do servizo; non é a súa autoridade.

Cando se propón un cambio, pregunte cal dos dous rexistros toca. Se ninguén pode responder, o cambio non está listo para programarse.

O punto final debe resolverse antes de que exista ningún túnel

Supoña que a conexión a internet da sucursal recibe un enderezo público novo. O actualizador do punto final publica o enderezo novo, e a implementación remota de VPN debe poder ler a resposta cambiada. Calquera resolutor que proporcione esa resposta debe ser alcanzable sen o túnel, ou o cliente persegue un nome que só pode resolver despois de conectarse ao que non pode atopar.

Esa dependencia de arranque merece dicirse con claridade, porque é fácil creala por accidente cando todos os resolutores internos están detrás da VPN. Manteña unha ruta previa ao túnel para a consulta do punto final e confirme o comportamento de reconexión do cliente en lugar de supoñer que unha resposta nova se recolle de inmediato.

O DNS dinámico tamén ten límites que a actualización do rexistro non pode cruzar. Actualizar un rexistro non abre ningún porto de devasado, non crea ningunha asignación NAT e non demostra ningunha identidade de par. Un enderezo publicado cun porto pechado dá un cliente que resolve correctamente e aínda así non pode conectarse a nada.

Por último, un cliente en execución pode seguir usando un punto final en caché ata que se reconecte. Separe a publicación, a caché e a política de reconexión nas súas notas, para que un par obsoleto non se confunda cun actualizador avariado.

O nome do servizo describe onde vive a aplicación

Agora supoña que o túnel se mantén san pero o servidor de inventario trasládase de 172.26.14.20 a 172.26.14.35. O rexistro público do punto final non se ve afectado, mentres que o rexistro privado do servizo debe cambiar. Usar un enderezo reservado para ese servizo, ou unha asignación estática, fai que isto sexa máis raro; unha ruta de actualización autorizada cobre as veces en que é intencionado.

Aquí confúndense dous mecanismos de actualización. RFC 2136 define un protocolo para engadir e eliminar rexistros DNS nunha zona, mentres que un provedor comercial de DNS dinámico pode expor unha API HTTP completamente distinta para outro propósito. Usar un non implica que o outro exista no seu entorno. Comprobe que mecanismo acepta realmente a súa zona antes de escribir un actualizador contra el.

Unha resposta privada correcta é só a primeira condición. Para que un chamador remoto a use, o cliente necesita un resolutor que porte a zona privada, unha política que permita consultas a ese resolutor e reenvío para o enderezo que volve. Un nome que resolve a un enderezo que o cliente non pode alcanzar produce un tempo de espera que parece un fallo do servidor.

Probe as dúas rutas por separado

Comprobe o punto final desde fóra do túnel e o servizo desde dentro, e garde os resultados como dous feitos independentes:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Se falla a primeira consulta, o problema é a publicación pública ou a ruta de resolución previa ao túnel, e ningún cambio interno axudará. Se a segunda devolve un enderezo pero a terceira non mostra ningunha ruta polo túnel, a capa DNS está ben e a política de reenvío non.

Execute o par despois de cada cambio de enderezo e anote que rexistro se moveu. Unha entrega que só di «actualizouse o DNS» deixa o seguinte enxeñeiro adiviñando cal dos dous ciclos de vida se executou realmente.