Como configurar o DNS de horizonte dividido para acesso interno e remoto à aplicação

Utilize o mesmo nome de anfitrião da aplicação em todo o lado, mas devolva um endereço de proxy privado a clientes internos de confiança e clientes VPN, e o endpoint público ou de túnel a clientes externos. Mantenha o nome TLS idêntico em ambos os caminhos.

O DNS de horizonte dividido é útil quando o NAT hairpin não está disponível ou quando o tráfego local deve permanecer na LAN. Falha quando os clientes ignoram o resolvedor pretendido, persistem respostas obsoletas ou o endpoint interno fornece um certificado diferente. Defina as duas vistas, reduza os TTL antes da migração e teste a resolução separadamente do HTTPS.

Defina as vistas interna e externa

Escolha um FQDN para cada aplicação. No DNS público, aponte-o para o proxy, túnel ou gateway acessível externamente; no DNS interno, substitua-o pelo endereço privado do proxy local.

Não crie um nome de anfitrião exclusivamente interno diferente apenas para evitar o trabalho com certificados, a menos que a aplicação suporte dois URLs canónicos. Um único nome mantém os marcadores, os callbacks e os clientes móveis consistentes durante as mudanças de localização.

Documente quais as sub-redes que recebem a vista interna. As redes de convidados podem precisar da resposta pública, enquanto a LAN de confiança e os clientes VPN de acesso remoto recebem a resposta privada através do resolvedor que lhes foi atribuído.

Torne determinística a seleção do resolvedor

Anuncie o resolvedor interno através do DHCP e do perfil VPN. Consulte-o explicitamente primeiro e, em seguida, consulte através do sistema operativo para detetar uma cache local ou um desvio do DNS encriptado.

As caches dos resolvedores e as diferentes bibliotecas DNS podem produzir resultados inesperados; este catálogo de modos comuns de falha do DNS explica por que motivo uma alteração autoritativa pode não aparecer imediatamente no cliente.

Limpe apenas as caches relevantes depois de confirmar que o registo está correto na origem. Se um navegador gerido utilizar o seu próprio resolvedor encriptado, aplique uma política aprovada ou aceite o caminho público, em vez de editar repetidamente a zona local.

Alinhe o comportamento do proxy, do certificado e da aplicação

Ambos os endpoints devem apresentar um certificado válido para o FQDN partilhado e encaminhar esse anfitrião para a mesma identidade de aplicação. Um aviso de certificado significa que o DNS chegou a um endpoint, mas o endpoint não está configurado para o nome solicitado.

Verifique os redirecionamentos, os WebSockets, os URLs de callback e o URL externo da aplicação. Um proxy local que redirecione para um endereço IP ou para um nome de anfitrião diferente compromete o design de nome único.

Se a aplicação utilizar um subcaminho, mantenha o seu URL base e a rota do proxy sincronizados. A lista de verificação da ZimaSpace para atualizações de contentores Jellyfin ajuda a preservar as definições do proxy, dos pontos de montagem e dos URLs antes de uma alteração.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Teste as transições entre o acesso interno e remoto

Na rede Wi-Fi, registe o servidor DNS, o endereço devolvido, o certificado e o resultado da aplicação. Repita através da rede móvel com o Wi-Fi desativado; o endereço deve mudar, enquanto o nome de anfitrião e a identidade do certificado permanecem iguais.

Ligue a VPN a partir de uma rede externa e repita o teste. Se a VPN dever utilizar o caminho privado, mas receber a resposta pública, corrija a atribuição de DNS ou o encaminhamento antes de alterar as definições da aplicação.

Por fim, mova um cliente entre redes e aguarde durante o TTL. Pare quando os três caminhos forem determinísticos; reverta a substituição interna se os clientes alcançarem o proxy errado ou se não conseguir controlar qual o resolvedor que utilizam.