Lista de permitidos de extremos VPN: a actualización de DNS que esqueciches

Escribir vpn.example.com nunha excepción de firewall séntese como subscribirse a DNS. O que adoita ocorrer é unha tradución ao cargar, despois da cal a regra garda enderezos e nada os actualiza. Dous compoñentes comparten agora o traballo: o resolutor que responde e o firewall que almacena. A maioría das caídas de extremos comezan onde esa entrega nunca se deseñou.

Un nome de host nunha regra non é unha subscrición en vivo

Algunhas ferramentas resolven un nome cando se carga a configuración; outras conservan un nome de host e volven resolvelo segundo o seu propio calendario; outras só aceptan enderezos. A configuración visible raramente di cal. Os exemplos da documentación adoitan supor o caso de carga, por iso a diferenza sorprende á xente durante unha migración. Le o comportamento da implementación antes de supor que se notará un cambio de enderezo, porque unha lista de permitidos obsoleta parece exactamente unha que funciona ata que o extremo se move.

Unha regra que nomea o host correcto aínda pode permitir o enderezo equivocado. Ese oco é o mito, non un erro de ortografía.

O TTL da caché non é o temporizador do teu firewall

Os rexistros DNS teñen un tempo de vida, e os resolutores almacenan respostas en caché durante ese período. A especificación DNS define ese comportamento de caché, pero rexe os datos DNS, non o almacén de enderezos separado dun firewall. Un TTL curto non crea unha tarefa de actualización onde non existe. O almacenamento en caché tamén ocorre en máis dunha capa, así que a resposta que ve un terminal pode non ser a que viu o firewall.

Fai tres preguntas ao produto real: cando resolve, onde garda o resultado e que desencadea unha actualización. Se a resposta só é ao arrincar, unha sesión de longa duración pode sobrevivir ao enderezo ao que se admitiu.

dig +short vpn.example.com
resolvectl query vpn.example.com

Deseña a actualización e o fallo como unha soa política

Unha excepción mantida necesita respostas explícitas: que desencadea unha actualización antes de que o cliente escolla un novo enderezo, como cambia o conxunto permitido sen abrir unha ventá temporal ampla e cando se eliminan as entradas obsoletas. Escribe esas respostas xunto á regra.

Escolle o comportamento ante fallos deliberadamente. Conservar o enderezo antigo pode preservar unha sesión e deixar un permiso obsoleto; baleirar o conxunto pode bloquear a recuperación. Ningún debería ser un resultado accidental dunha busca fallida. Escribe o comportamento elixido no runbook para que o seguinte operador non improvise baixo presión.

Mantén tamén estreito o DNS de arranque. Unha excepción incondicional de resolutor público é unha ruta DNS directa para todo o que coincide, non só para o nome do extremo.

Demostra o cambio do extremo, non a primeira conexión

Usa o xestor compatible do cliente se xa coordina a resolución e o bloqueo. Nun host PF xestionado polo sitio, mantén a propiedade e o plan de recuperación do sitio en lugar de copiar a sintaxe da táboa de nomes de host doutra plataforma cun comportamento de ciclo de vida distinto.

Cunha proba aprobada e inocua, compara o enderezo que selecciona o cliente co conxunto permitido activo antes e despois dun cambio controlado. Cobre unha busca fallida, a eliminación dunha entrada que xa non é válida e, cando se admita, unha familia de enderezos distinta. O túnel previsto debería recuperarse mentres o tráfico directo non relacionado permanece baixo a política. Unha primeira conexión correcta só demostra que a tradución inicial resultou correcta por casualidade.