Nome DNS privado ou apenas um IP? Decida antes de compartilhar

Duas perguntas se misturam quando um serviço privado é aberto a usuários remotos. A primeira é qual nome os clientes devem usar; a segunda é quais origens o serviço deve admitir. Responda-as nessa ordem, porque um nome correto atrás da regra de acesso errada continua falhando, e uma regra correta atrás de um nome que não resolve nunca chega a ser testada.

Primeira condição: qual caminho de resolvedor os clientes têm?

Um nome privado só funciona se o resolvedor do cliente conseguir respondê-lo. Isso significa que um cliente remoto autorizado deve alcançar um servidor DNS que detenha a zona, seja pelo túnel, seja por um resolvedor que a organização já executa para usuários remotos. O túnel é um transporte, não um diretório. Ele dá ao cliente um caminho até um resolvedor, e não lhe diz qual zona perguntar.

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

Um resolvedor público não aprenderá uma zona privada porque o portátil se conectou a uma VPN.

O sufixo merece a mesma atenção. Use um subdomínio de um domínio que a organização controle, para que a propriedade e o planejamento de certificados permaneçam explícitos. Evite .local: a especificação de DNS multicast liga esse sufixo à resolução link-local, e um túnel roteado não reproduz esse comportamento por você.

Segunda condição: qual origem o serviço recebe?

As regras de admissão são escritas contra endereços, então a pergunta útil é qual endereço o serviço vê após o roteamento e a tradução. Para um serviço de exemplo em 10.20.30.40, os clientes do escritório chegam de 10.20.30.0/24 e os clientes remotos de um conjunto separado como 10.99.0.0/24.

Se um gateway traduz o conjunto remoto, o serviço vê o tradutor, e uma regra escrita para 10.99.0.0/24 não vai corresponder.

Leia isto do lado do serviço e não do lado do cliente. Um log de escuta ou uma captura de pacotes no host do serviço mostra a origem que realmente chegou; o endereço do próprio cliente é apenas um palpite sobre o que sobreviveu ao caminho.

Terceira condição: o nome está ligado a um serviço ou a um host?

Um nome que aponta para o endereço de uma máquina liga cada cliente a essa máquina. Um nome que aponta para um balanceador de carga ou para um endereço de serviço estável sobrevive à substituição do host por trás dele. Escolha deliberadamente, porque mudar isso depois significa mudar os favoritos de cada cliente e o assunto de cada certificado.

Para um único serviço interno, um registo direto costuma ser adequado e mais simples de raciocinar.

Para tudo o que for substituído, reconstruído ou escalado, um front end estável vale a configuração extra. O teste é simples: se consegue substituir o backend sem avisar os usuários, o nome está ligado ao serviço; se não consegue, está ligado a um host.

Teste as duas decisões separadamente

Resolva primeiro, depois conecte. Um teste de resolução que devolve o endereço esperado prova o caminho do nome e não diz nada sobre a admissão. Um teste de conexão prova o caminho e a regra em conjunto, por isso execute-o apenas depois de a resolução ter sucesso.

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

Depois teste uma origem proibida uma vez, e registe o resultado.

Mantenha os dois registos separados na sua documentação: o nome e a sua zona, as origens admitidas e o dono da regra. Quando um muda, o outro não tem de mudar.

Onde a decisão costuma correr mal

A falha comum é um serviço publicado sob um nome que só resolve na rede do escritório, com uma regra de admissão que só admite o intervalo do escritório. Os usuários remotos relatam então um serviço quebrado que na verdade são duas omissões separadas. A segunda falha comum é o inverso: uma regra de admissão ampla acrescentada para eliminar um problema de nome deixa o serviço acessível a partir de origens que ninguém pretendia. Ambas são omissões de configuração, e da cadeira do usuário parecem iguais.

Nenhum dos dois erros é visível a partir de um único teste bem-sucedido. É por isso que as duas decisões merecem registos separados e testes separados, mesmo quando a mesma pessoa toma ambas.

Escreva ambas antes de o serviço entrar em produção, porque a próxima mudança será mais fácil de raciocinar. O registo é curto: uma linha para o nome e a sua zona, uma linha para as origens admitidas e o dono da regra.