Como configurar substituições de DNS local para vários proxies reversos

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

How to Configure Local DNS Overrides for Multiple Reverse Proxies - Zima Store Online

Crie um mapeamento local autoritativo para cada nome de aplicação e associe-o a exatamente um endereço de proxy reverso por rede de clientes. Não crie substituições de wildcard concorrentes em vários servidores DNS.

Vários proxies tornam-se confusos quando o mesmo domínio público é reutilizado internamente: um portátil pode consultar o router, um contentor pode consultar um resolvedor local e um telemóvel pode utilizar DNS encriptado. O resultado pode parecer uma falha do proxy ou do certificado, embora o cliente tenha simplesmente recebido o endereço errado. Faça o inventário dos nomes, resolvedores, listeners do proxy e certificados antes de adicionar registos.

Associe nomes aos limites do proxy

Liste cada FQDN de aplicação e o proxy que termina a respetiva ligação TLS. Utilize registos específicos para exceções e reserve um wildcard apenas para um domínio cujo namespace completo pertença a um único proxy.

Evite atribuir ao mesmo nome dois registos A privados, a menos que ambos os proxies estejam intencionalmente ativos e configurados de forma idêntica. O DNS devolve endereços, não o estado do serviço, pelo que os registos round-robin casuais podem enviar metade dos clientes para um proxy sem a rota ou o certificado necessários.

Mantenha os nomes de gestão separados dos nomes destinados aos utilizadores. Se um nome de administrador nunca dever ser resolvido numa rede de convidados, coloque-o numa view ou num resolvedor disponível apenas para a VLAN de confiança, em vez de depender do proxy para o ocultar posteriormente.

Coloque as substituições no resolvedor que os clientes realmente utilizam

Crie a zona local ou as substituições de hosts no serviço DNS anunciado pelo DHCP dessa rede. Aponte cada nome de aplicação para o endereço LAN do proxy responsável, não para o contentor da aplicação e não automaticamente para o endereço WAN público.

Os clientes e as aplicações podem utilizar bibliotecas e caches de resolvedor diferentes, razão pela qual o comportamento do DNS pode permanecer oculto. Confirme o servidor apresentado no resultado da consulta, em vez de presumir que foi utilizada a substituição do router.

Desative ou tenha em conta o DNS encriptado do lado do cliente durante o teste. Se o cliente ignorar deliberadamente o DNS local, as substituições de split-horizon não poderão afetá-lo; opte antes por uma política de DNS gerida, um registo público com encaminhamento hairpin ou um resolvedor fornecido por VPN.

Faça corresponder as rotas do proxy, o TLS e os URLs das aplicações

Em cada proxy, configure apenas os nomes de anfitrião que lhe foram atribuídos e confirme que o certificado abrange esses nomes. Uma resposta DNS correta seguida do certificado errado prova que o tráfego chegou a um listener, mas não ao virtual host pretendido.

Teste a rota para o upstream a partir do próprio proxy e, em seguida, teste o nome de anfitrião público a partir de um cliente. Se o acesso direto ao upstream funcionar, mas o nome de anfitrião devolver um site predefinido, corrija a correspondência do host no proxy antes de alterar novamente o DNS.

Para aplicações alojadas num caminho, mantenha a rota do proxy e o URL base da aplicação alinhados. O guia da ZimaSpace sobre remover a exposição do Jellyfin em segurança também mostra por que motivo o DNS, as rotas do proxy, o encaminhamento e as ACLs devem ser acompanhados em conjunto.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

Verifique cada rede e defina a reversão

Consulte diretamente o FQDN no resolvedor local pretendido e, em seguida, consulte-o através do percurso normal do sistema operativo. Ambas as respostas devem apontar para o mesmo proxy nessa rede, e o TTL deve corresponder à política local.

Abra a aplicação a partir da LAN de confiança, da VLAN de convidados ou multimédia e da VPN, conforme aplicável. Registe o endereço resolvido, o nome do certificado, o estado HTTP e o redirecionamento final; estas observações permitem identificar se a falha está no DNS, no TLS, no encaminhamento do proxy ou na aplicação.

Remova os registos duplicados obsoletos apenas depois de todos os clientes passarem nos testes. Reverta a substituição mais recente se diferentes clientes alternarem entre proxies e pare de expandir o wildcard até os registos do resolvedor comprovarem qual foi o servidor que respondeu a cada pedido com falha.