Dúas preguntas mestúranse cando un servizo privado se abre a usuarios remotos. A primeira é que nome deben usar os clientes; a segunda, que fontes debe admitir o servizo. Respóndallas nesa orde, porque un nome correcto detrás dunha regra de acceso equivocada segue fallando, e unha regra correcta detrás dun nome que non se resolve nunca chega a probarse.

Condición unha: que ruta de resolutor teñen os clientes?

Un nome privado só funciona se o resolutor do cliente pode responder nel. Iso significa que un cliente remoto autorizado debe chegar a un servidor DNS que teña a zona, xa sexa polo túnel ou por un resolutor que a organización xa executa para usuarios remotos. O túnel é un transporte, non un directorio. Dálle ao cliente unha ruta cara a un resolutor, e non lle di que zona preguntar.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Un resolutor público non aprenderá unha zona privada porque o portátil se conectase a unha VPN.

O sufixo merece a mesma atención. Use un subdominio dun dominio que a organización controle, para que a propiedade e a planificación de certificados sigan explícitas. Evite .local: a especificación de DNS multicast ata ese sufixo á resolución link-local, e un túnel encamiñado non reproduce ese comportamento por vostede.

Condición dous: que fonte recibe o servizo?

As regras de admisión escríbense contra enderezos, así que a pregunta útil é que enderezo ve o servizo despois do encamiñamento e da tradución. Para un servizo de exemplo en 10.20.30.40, os clientes de oficina chegan desde 10.20.30.0/24 e os clientes remotos desde un grupo separado como 10.99.0.0/24.

Se unha pasarela traduce o grupo remoto, o servizo ve o tradutor, e unha regra escrita para 10.99.0.0/24 non coincidirá.

Lea isto desde o lado do servizo e non desde o lado do cliente. Un rexistro de escoita ou unha captura de paquetes no host do servizo mostra a fonte que chegou realmente; o enderezo do propio cliente só é unha conxectura sobre o que sobreviviu á ruta.

Condición tres: o nome está ligado a un servizo ou a un host?

Un nome que apunta ao enderezo dunha máquina liga cada cliente a esa máquina. Un nome que apunta a un balanceador de carga ou a un enderezo de servizo estable sobrevive á substitución do host que hai detrás. Escolla a conciencia, porque cambialo despois significa cambiar os marcadores de cada cliente e o suxeito de cada certificado.

Para un único servizo interno, un rexistro directo adoita estar ben e é máis sinxelo de razoar.

Para calquera cousa que vaia ser substituída, reconstruída ou escalada, un frontal estable merece a configuración adicional. A proba é simple: se pode substituír o backend sen avisar os usuarios, o nome está ligado ao servizo; se non pode, está ligado a un host.

Probe as dúas decisións por separado

Resolva primeiro, despois conecte. Unha proba de resolución que devolve o enderezo esperado demostra a ruta do nome e non di nada sobre a admisión. Unha proba de conexión demostra a ruta e a regra xuntas, así que execútea só despois de que a resolución teña éxito.

curl -sv --max-time 5 https://files.corp.example/health

Despois probe unha fonte prohibida unha vez e rexistre o resultado.

Manteña os dous rexistros separados na súa documentación: o nome e a súa zona, as fontes admitidas e o propietario da regra. Cando un cambia, o outro non ten por que.

Onde adoita saír mal a decisión

O fallo habitual é un servizo publicado baixo un nome que só se resolve na rede de oficina, cunha regra de admisión que só admite o rango de oficina. Os usuarios remotos informan entón dun servizo roto que en realidade son dúas omisións separadas. O segundo fallo habitual é o inverso: unha regra de admisión ampla engadida para eliminar un problema de nome deixa o servizo accesible desde fontes que ninguén pretendía. Ambas son omisións de configuración, e desde a cadeira do usuario vense igual.

Ningún dos dous erros é visible desde unha soa proba correcta. Por iso as dúas decisións merecen rexistros separados e probas separadas, mesmo cando as toma a mesma persoa.

Escriba ambas antes de que o servizo entre en produción, porque o seguinte cambio será máis fácil de razoar. O rexistro é curto: unha liña para o nome e a súa zona, unha liña para as fontes admitidas e o propietario da regra.

Artigos relacionados