Azure de punto a sitio se conecta pero ningún recurso privado responde
Conectado solo significa que el túnel se levantó. Compruebe qué puede transportar la puerta de enlace, compare los espacios de direcciones y luego resuelva un nombre y pruebe el servicio en sí.
Conectado es un estado del túnel, no una afirmación sobre la accesibilidad. Un cliente de punto a sitio puede terminar IKE, recibir una dirección y aun así no llegar a nada, porque la puerta de enlace solo reenvía tráfico de las redes que la VNet ya conoce. Recorra estas cinco comprobaciones en orden y deténgase en el primer fallo. Saltarse pasos es como un problema de DNS acaba tratado como un problema de cortafuegos durante una hora.
El orden importa más que la lista.
Comprobación 1: decida qué debe transportar el túnel
Azure VPN Gateway termina el túnel y reenvía el tráfico que pertenece a la VNet; no esuna salida general a Internet. Si los usuarios esperan que su navegación salga por Azure, el diseño es incorrecto antes de que intervenga ningún ajuste del cliente. Active el split tunneling para que Internet local siga usando la ruta local, y use una instancia NAT o un túnel de sitio a sitio cuando de verdad se requiera una dirección de salida fija.
Anote a qué debe llegar el cliente antes de probar nada. Sin esa lista, cada resultado parcial parece un avance.
Comprobación 2: compare los espacios de direcciones antes de los certificados
El solapamiento se juzga por los rangos más amplios, así que dos redes que parecen distintas a nivel de subred siguen chocando si sus bloques padre se solapan. La subred de la puerta de enlace debe ser dedicada y lo bastante grande para la SKU, y el grupo de direcciones del cliente no debe chocar con la VNet ni con nada accesible a través de un peering. Cambie el plan y vuelva a implementar, porque añadir rutas para compensar produce un túnel que funciona con algunos destinos y inexplicablemente no con otros. El aprovisionamiento falla ruidosamente aquí, que es el buen caso.
La autenticación es la siguiente puerta. Los perfiles de certificado, RADIUS y Entra ID no son intercambiables, y el paquete de cliente difiere para cada uno.
Comprobación 3: resuelva un nombre privado desde dentro
El cliente conserva su propio resolutor a menos que el perfil descargado lleve los servidores DNS de la VNet, y esa lista se incrusta en el momento de la descarga. Añada un forwarder dentro de la VNet, configúrelo como servidor DNS de la VNet y después vuelva a descargar e importar el paquete de cliente. Reutilizar el paquete antiguo solo prueba la lista antigua de resolutores.
Pruebe primero una dirección, porque separa el enrutamiento del nombrado en un solo paso: Test-NetConnection 10.20.1.4 -Port 3389.
Si la dirección responde y el nombre no, consulte al resolutor directamente con Resolve-DnsName files.corp.example -Server 10.20.0.4. Si fallan ambos, el fallo no es de DNS y debería dejar de editar ajustes de DNS. El DNS de la plataforma Azure en 168.63.129.16 solo responde desde dentro de la VNet, así que un cliente fuera no puede usar esa dirección como resolutor.
Comprobación 4: pruebe el servicio detrás del túnel
Un túnel sano y un puerto cerrado se ven idénticos desde el cliente. Revise el cortafuegos del invitado, luego el grupo de seguridad de red de la subred o la NIC, y luego si el servicio escucha en la dirección privada en lugar de solo en loopback. Permita el grupo de clientes como origen en vez de abrir una regla a Internet, y recuerde que SMB a Azure Files necesita la ruta del punto de conexión privado encaminada por el túnel. Cuando un recurso responde por IP pero no por nombre, vuelva a la comprobación 3 en lugar de tocar la puerta de enlace.
Una tabla mantiene las capas separadas mientras trabaja:
| 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: registre el perfil antes de escalar
Ponga el tipo de puerta de enlace, el tipo de túnel, el método de autenticación y el sistema operativo del cliente en el tique. Un perfil IKEv2 con certificado y un perfil RADIUS fallan por motivos distintos, y un cliente creado para otro tipo de túnel solo se conecta cuando la puerta de enlace ofrece un protocolo compatible.
Para un equipo pequeño, el diseño duradero es una VNet, un forwarder DNS y un cliente split-tunnel documentado. Si el requisito es una salida pública fija, termine un túnel de sitio a sitio en un cortafuegos que controle y enrute allí el tráfico de Internet, en lugar de pedir a la puerta de enlace de punto a sitio algo para lo que nunca se construyó.