Azure de punto a sitio conéctase pero ningún recurso privado responde
Conectado só significa que o túnel se levantou. Comprobe que pode transportar a pasarela, compare os espazos de enderezos e despois resolva un nome e probe o servizo en si.
Conectado é un estado do túnel, non unha afirmación sobre a accesibilidade. Un cliente de punto a sitio pode rematar IKE, recibir un enderezo e aínda así non chegar a nada, porque a pasarela só reenvía tráfico das redes que a VNet xa coñece. Percorra estas cinco comprobacións en orde e detéñase no primeiro fallo. Saltar pasos é como un problema de DNS acaba tratado como un problema de cortafuegos durante unha hora.
A orde importa máis ca a lista.
Comprobación 1: decida que debe transportar o túnel
Azure VPN Gateway remata o túnel e reenvía o tráfico que pertence á VNet; non éunha saída xeral a Internet. Se os usuarios esperan que a súa navegación saia por Azure, o deseño é incorrecto antes de que interveña calquera axuste do cliente. Active o split tunneling para que Internet local siga usando a ruta local, e use unha instancia NAT ou un túnel de sitio a sitio cando de verdade se requira un enderezo de saída fixo.
Anote a que debe chegar o cliente antes de probar nada. Sen esa lista, cada resultado parcial parece un avance.
Comprobación 2: compare os espazos de enderezos antes dos certificados
O solapamento xúlgase polos rangos máis amplos, así que dúas redes que parecen distintas a nivel de subrede seguen chocando se os seus bloques pai se solapan. A subrede da pasarela debe ser dedicada e o bastante grande para a SKU, e o conxunto de enderezos do cliente non debe chocar coa VNet nin con nada accesible a través dun peering. Cambie o plan e volva despregar, porque engadir rutas para compensar produce un túnel que funciona con algúns destinos e inexplicablemente non con outros. O aprovisionamento falla ruidosamente aquí, que é o bo caso.
A autenticación é a seguinte porta. Os perfís de certificado, RADIUS e Entra ID non son intercambiables, e o paquete de cliente difire para cada un.
Comprobación 3: resolva un nome privado desde dentro
O cliente conserva o seu propio resolutor a menos que o perfil descargado leve os servidores DNS da VNet, e esa lista incrústase no momento da descarga. Engada un forwarder dentro da VNet, configúreo como servidor DNS da VNet e despois volva descargar e importar o paquete de cliente. Reutilizar o paquete antigo só proba a lista antiga de resolutores.
Probe primeiro un enderezo, porque separa o encamiñamento do nomeado nun só paso: Test-NetConnection 10.20.1.4 -Port 3389.
Se o enderezo responde e o nome non, consulte o resolutor directamente con Resolve-DnsName files.corp.example -Server 10.20.0.4. Se fallan ambos, a avaría non é de DNS e debería deixar de editar axustes de DNS. O DNS da plataforma Azure en 168.63.129.16 só responde desde dentro da VNet, así que un cliente fóra non pode usar ese enderezo como resolutor.
Comprobación 4: probe o servizo detrás do túnel
Un túnel san e un porto pechado vense idénticos desde o cliente. Revise o cortafuegos do convidado, despois o grupo de seguridade de rede da subrede ou da NIC, e despois se o servizo escoita no enderezo privado en lugar de só en loopback. Permita o conxunto de clientes como orixe en vez de abrir unha regra a Internet, e lembre que SMB a Azure Files necesita a ruta do punto de conexión privado encamiñada polo túnel. Cando un recurso responde por IP pero non por nome, volva á comprobación 3 en lugar de tocar a pasarela.
Unha táboa mantén as capas separadas mentres traballa:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
Comprobación 5: rexistre o perfil antes de escalar
Poña o tipo de pasarela, o tipo de túnel, o método de autenticación e o sistema operativo do cliente no ticket. Un perfil IKEv2 con certificado e un perfil RADIUS fallan por motivos distintos, e un cliente creado para outro tipo de túnel só se conecta cando a pasarela ofrece un protocolo compatible.
Para un equipo pequeno, o deseño duradeiro é unha VNet, un forwarder DNS e un cliente split-tunnel documentado. Se o requisito é unha saída pública fixa, remate un túnel de sitio a sitio nun cortafuegos que controle e encamiñe alí o tráfico de Internet, en lugar de pedir á pasarela de punto a sitio algo para o que nunca se construíu.