Azure ponto a site conecta, mas nenhum recurso privado responde

Conectado é um estado do túnel, não uma afirmação sobre alcançabilidade. Um cliente ponto a site pode concluir o IKE, receber um endereço e ainda assim não alcançar nada, porque o gateway só encaminha tráfego das redes que a VNet já conhece. Percorra estas cinco verificações por ordem e pare na primeira falha. Saltar etapas é como um problema de DNS acaba tratado como problema de firewall durante uma hora.

A ordem importa mais do que a lista.

Verificação 1: decida o que o túnel deve transportar

O Azure VPN Gateway termina o túnel e encaminha o tráfego que pertence à VNet; não éuma saída geral para a Internet. Se os utilizadores esperam que a navegação saia pelo Azure, o desenho está errado antes de qualquer definição do cliente entrar em cena. Ative o split tunneling para que a Internet local continue a usar o caminho local, e use uma instância NAT ou um túnel site a site quando for realmente necessária uma morada de saída fixa.

Anote a que o cliente deve chegar antes de testar seja o que for. Sem essa lista, cada resultado parcial parece um progresso.

Verificação 2: compare os espaços de endereços antes dos certificados

A sobreposição é avaliada nos intervalos mais amplos, por isso duas redes que parecem diferentes ao nível da sub-rede continuam a colidir se os blocos principais se sobrepuserem. A sub-rede do gateway tem de ser dedicada e suficientemente grande para o SKU, e o conjunto de endereços do cliente não pode colidir com a VNet nem com nada alcançável através de um peering. Altere o plano e volte a implementar, porque acrescentar rotas para compensar produz um túnel que funciona para alguns destinos e inexplicavelmente não para outros. O aprovisionamento falha ruidosamente aqui, o que é o bom caso.

A autenticação é a porta seguinte. Os perfis de certificado, RADIUS e Entra ID não são intermutáveis, e o pacote de cliente difere para cada um.

Verificação 3: resolva um nome privado a partir de dentro

O cliente mantém o seu próprio resolvedor, a menos que o perfil descarregado traga os servidores DNS da VNet, e essa lista é incorporada no momento da transferência. Adicione um forwarder dentro da VNet, defina-o como servidor DNS da VNet e depois transfira e importe novamente o pacote de cliente. Reutilizar o pacote antigo só testa a lista antiga de resolvedores.

Teste primeiro um endereço, porque isso separa o encaminhamento da nomenclatura num único passo: Test-NetConnection 10.20.1.4 -Port 3389.

Se o endereço responder e o nome não, consulte o resolvedor diretamente com Resolve-DnsName files.corp.example -Server 10.20.0.4. Se ambos falharem, a falha não é de DNS e deve parar de editar definições de DNS. O DNS da plataforma Azure em 168.63.129.16 só responde a partir de dentro da VNet, por isso um cliente fora dela não pode usar esse endereço como resolvedor.

Verificação 4: teste o serviço por trás do túnel

Um túnel saudável e uma porta fechada parecem idênticos do lado do cliente. Verifique a firewall do convidado, depois o grupo de segurança de rede na sub-rede ou na NIC, e depois se o serviço escuta no endereço privado em vez de apenas em loopback. Permita o conjunto de clientes como origem em vez de abrir uma regra para a Internet, e lembre-se de que o SMB para o Azure Files precisa do caminho do ponto final privado encaminhado pelo túnel. Quando um recurso responde por IP mas não por nome, volte à verificação 3 em vez de mexer no gateway.

Uma tabela mantém as camadas separadas enquanto trabalha:

Verificação 5: registe o perfil antes de escalar

Coloque o tipo de gateway, o tipo de túnel, o método de autenticação e o sistema operativo do cliente no ticket. Um perfil IKEv2 com certificado e um perfil RADIUS falham por razões diferentes, e um cliente criado para outro tipo de túnel só se liga quando o gateway oferece um protocolo compatível.

Para uma equipa pequena, o desenho duradouro é uma VNet, um forwarder DNS e um cliente split-tunnel documentado. Se o requisito for uma saída pública fixa, termine um túnel site a site numa firewall que controle e encaminhe para lá o tráfego de Internet, em vez de pedir ao gateway ponto a site algo para o qual nunca foi construído.