O Azure P2S VPN não consegue resolver o nome de um ponto final privado

Liga o túnel ponto a site, faz ping ao endereço privado, abre a aplicação e recebe um 403 ou um erro de certificado. Ambos os sintomas apontam para DNS, mas são falhas diferentes: uma significa que o cliente resolveu o endereço público, a outra que resolveu o endereço privado e depois ofereceu um nome que o certificado não cobre. Siga as verificações abaixo por ordem e pare na primeira falha, porque uma entrada em hosts ou uma resposta em cache podem fazer com que cada verificação seguinte passe pelo motivo errado. Guardo esta ordem num ficheiro de texto ao lado dos meus perfis de VPN, porque a correção não muda nada no túnel e muda tudo no que o cliente sabe.

Comece pelo endereço que o cliente recebe de facto

Pergunte ao resolvedor diretamente em vez de confiar na aplicação. No Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net mostra que vista o cliente recebeu. Uma resposta pública significa que nada a jusante chegará ao ponto final; o endereço privado do ponto final significa que o DNS está terminado e que a verificação seguinte é a própria ligação.

Um ponto final privado não muda o nome do serviço. A conta ou a aplicação mantém o seu nome completo habitual, e o ponto final apenas muda o endereço para o qual esse nome é resolvido para clientes dentro da rede virtual. É por isso que o mesmo nome de anfitrião é resolvido de forma privada a partir de uma VM na rede e de forma pública a partir de um portátil que nunca recebeu a vista privada.

Verifique a zona, a ligação e o registo antes do túnel

Três condições têm de se verificar em conjunto: a zona privada existe, está ligada à rede virtual por onde entram no Azure o gateway de VPN e os clientes, e contém um registo A do ponto final que aponta para o endereço privado. Ligue a zona a uma rede não relacionada e o gateway continuará a resolver o registo público enquanto tudo no túnel parece saudável.

Os nomes de zona pertencem aos serviços, não às ligações privadas em geral. O App Service usa normalmente privatelink.azurewebsites.net, o armazenamento e o SQL têm os seus próprios espaços de nomes, e pedir emprestada a zona de outro serviço produz uma zona que existe e não responde nada de útil.

Dê ao cliente um resolvedor que consiga mesmo alcançar

168.63.129.16 responde a partir de máquinas virtuais do Azure e não é um servidor DNS para um portátil do outro lado de um túnel ponto a site. O cliente precisa de um resolvedor alcançável através do túnel: um ponto final de entrada do Azure DNS Private Resolver, um reencaminhador dentro da rede virtual, ou entradas de servidor DNS transportadas no perfil do cliente VPN para que o cliente pergunte diretamente à rede virtual.

Um resolvedor configurado mas inalcançável comporta-se exatamente como nenhum resolvedor, e o sintoma é um tempo limite em vez de uma resposta errada, razão pela qual é mal interpretado como um problema de firewall. Teste-o com uma consulta que o túnel deve transportar, não com um nome público que teria funcionado pela ligação local de qualquer forma.

Se reencaminha em vez de empurrar definições, reencaminhe o espaço de nomes que a zona privada possui, privatelink.azurewebsites.net em vez de todo o azurewebsites.net. Um reencaminhador condicional que engole todo o sufixo pai envia para o Azure cada pesquisa do serviço, incluindo as que deviam ficar locais.

Use o nome para o qual o certificado foi emitido

Quando o endereço está correto, surge a segunda falha. O armazenamento e o App Service publicam um alias privatelink, e esse alias não é necessariamente o nome no certificado. Um carregamento AzCopy dirigido a privatelink.blob.core.windows.net falhou a validação; o mesmo carregamento para <account>.blob.core.windows.net/<container> foi resolvido para o endereço privado e passou, pelo que ficou no caminho privado sem qualquer exceção.

A regra vale no navegador e também para o App Service: ligue-se com o nome de anfitrião que o certificado cobre e deixe o DNS fornecer o endereço privado. Não recorra a contornar a validação, porque transforma um erro de nomenclatura numa regressão de segurança. Um ping bem-sucedido prova a rota e não diz nada sobre o nome dentro do aperto de mão, por isso continuam a ser verificações separadas.

Uma ordem de quatro passos que isola cada camada

1. Confirme que o cliente VPN tem um endereço do conjunto ponto a site e uma rota para o endereço privado do ponto final.
2. Resolva o nome exato que a aplicação usa e compare a resposta com o endereço do ponto final.
3. Abra uma ligação TCP ao ponto final na porta do serviço e, em seguida, leia o nome do certificado apresentado nessa ligação.
4. Só agora teste a autorização, porque um caminho que funciona e um certificado válido ainda não dão acesso ao recurso.

Uma ligação recusada com o endereço correto aponta para o grupo de segurança de rede ou para o estado da ligação do ponto final privado, não para o DNS, por isso verifique-os antes de voltar a editar as definições do resolvedor. Uma divergência de nome TLS devolve-o ao nome de anfitrião no URL e ao subject do certificado. Guarde juntos a saída da resolução, o nome do certificado e o URL exato; esses três valores explicam a maioria destes casos sem tocar no gateway.

Use uma VM dentro da rede virtual como controlo. Se o nome for resolvido de forma privada aí e de forma pública a partir do túnel, a zona e o registo estão corretos e a única diferença é o caminho do resolvedor do cliente, que se confirma mais depressa do que outra passagem pela configuração do ponto final.

Os clientes também fazem cache. Um registo que respondeu publicamente há dez minutos continua a responder depois de corrigir a zona, por isso limpe a cache antes de testar novamente. No Windows, ipconfig /flushdns limpa a cache do cliente; as regras de política de resolução de nomes persistem, decidem que sufixo vai para que servidor e podem continuar a enviar o espaço de nomes para o resolvedor que acabou de substituir.

Onde pertence uma entrada hosts

Adicionar o endereço do ponto final a um ficheiro hosts é um bom diagnóstico e um mau desenho. Prova que a correspondência entre nome e endereço é a peça em falta e permite testar tudo o que vem depois, mas é invisível para os seus utilizadores, quebra quando o endereço do ponto final muda e esconde a zona que devia responder.

Uma entrada de teste que fica é pior do que uma cache desatualizada, porque pode fazer parecer quebrado o caminho reparado ou reparado o caminho quebrado, conforme a direção do erro. Remova-a antes da passagem final e resolva apenas com o resolvedor de produção.

Os nomes curtos precisam de um sufixo de pesquisa e os nomes completos não, por isso teste primeiro o nome completo e só depois decida se o fluxo de trabalho precisa de um sufixo empurrado pelo perfil do cliente. A Microsoft documenta os nomes de zona e as formas de registo por serviço nas suas orientações de DNS para pontos finais privados; leia a entrada do seu serviço em vez de copiar uma zona de outro.