Prueba de conectividad de red network-connectivity-test
La Prueba de conectividad de red es una herramienta de diagnóstico de Cloud Manager que le permite validar la configuración avanzada de redes y VPN antes de habilitar la conexión avanzada en sus entornos y antes de que se ponga en marcha. Utilícelo para comprobar que los hosts y puertos a los que debe llegar AEM, incluidos los extremos internos o privados, son accesibles a través de la misma ruta de conectividad que utilizará Advanced Networking.
La prueba se ejecuta desde la infraestructura de proxy de salida que pertenece a la configuración de redes avanzadas del programa, no desde un pod de autor o publicación. Utiliza la misma ruta de red saliente que utiliza AEM cuando la Red avanzada está activa. Ese diseño es especialmente útil para los escenarios de VPN: puede confirmar la resolución de DNS, el enrutamiento de red, las reglas del firewall y la disponibilidad del servicio para sistemas privados o locales antes de que se ponga en marcha.
Para obtener información general sobre el aprovisionamiento de VPN, IP de salida dedicada o salida de puerto flexible, consulte Configuración de redes avanzadas para AEM as a Cloud Service.
Cuándo utilizar esta herramienta when-to-use
- Después de Advanced Networking se crea en el nivel de programa y antes de o mientras se habilita en entornos.
- Para validar la conectividad de VPN con sistemas privados o locales que usted opera (por ejemplo, nombres de host internos o direcciones IP privadas).
- Para reducir los problemas de DNS en comparación con los problemas de firewall o enrutamiento cuando un servicio no responde según lo esperado.
Requisitos previos prerequisites
- Un programa de Cloud Manager.
- Ya se ha creado la infraestructura de redes avanzadas para el programa (consulte Configuración de redes avanzadas).
Cómo ejecutar una prueba how-to-run-a-test
-
Inicie sesión en Cloud Manager en my.cloudmanager.adobe.com y abra su organización y programa.
-
Abra la ficha Entornos del programa. En la barra lateral izquierda, seleccione Infraestructura de red.
-
En la página Infraestructura de red, busque su infraestructura en la tabla. Seleccione una fila para abrir la experiencia de prueba o abra el menú de acciones de fila (
) y elija Prueba.
-
Se abre el cuadro de diálogo Prueba de red. Escriba Host y Puerto, seleccione Prueba y revise la resolución de DNS, la apertura de puerto, la conectividad HTTP y la accesibilidad en el área de resultados. Las acciones opcionales como Copiar al portapapeles y el historial de pruebas recientes aparecen en el cuadro de diálogo. Consulte Comprender los resultados para saber cómo interpretar cada sección.
Campos de entrada input-fields
internal-api.example.com, 10.0.1.50443Etapas test-steps
- Escriba Host y Puerto.
- Seleccione Prueba. Los resultados suelen aparecer en unos segundos.
- Opcional: use Copiar al portapapeles para capturar el resultado JSON completo (útil para casos de soporte técnico).
- Las pruebas recientes pueden enumerarse para volver a ejecutarlas rápidamente.
Comprender los resultados understanding-results
La herramienta informa de varias dimensiones. Juntos describen si el objetivo es accesible desde la red avanzada y cómo se comportan las comprobaciones según HTTP.
Resolución de las DNS dns-resolution
ips: ["10.0.1.50"]error: "DNS resolution error: ..."Puerto abierto port-open
Yes / trueNo / falsoConexión HTTP http-connectivity
Se intenta una solicitud HTTP/HTTPS en cada puerto. La herramienta siempre intenta HTTPS primero y vuelve a HTTP. Si ninguno de los dos funciona, el resultado se asigna a un mensaje de error corto y legible (consulte la tabla siguiente).
Resultados de éxito
protocol: "https", status_code: 200, reason: "200 OK"protocol: "http", status_code: 301, reason: "301 Moved Permanently"Salidas de error clasificadas
"Not an HTTP/HTTPS service""The service appears to be a non-HTTP service (e.g., database, message queue, or custom TCP). Use the port_open and reachability fields to verify connectivity.""Connection refused""The port is not accepting connections. Verify the service is running and listening on this port.""Connection timed out""The connection timed out. Check firewall rules and network routing.""No IPs resolved for host"200, 301, 302, 403, 404 o 500) es una señal de éxito para la conectividad, lo que significa que la ruta de acceso de red funciona. El código de estado refleja la propia respuesta del servicio, no el estado general de la red. Para los servicios que no son HTTP, la herramienta indica No es un servicio HTTP/HTTPS; use Puerto abierto y Accesibilidad como indicadores confiables para esos servicios.Accesibilidad reachability
Varios solucionadores de DNS multiple-dns-resolvers
Si su infraestructura de red avanzada define más de una resolución DNS:
- Cuando todas las resoluciones devuelven resultados idénticos, verá un solo resultado consolidado etiquetado como
default. - Cuando las resoluciones devuelven resultados diferentes, el resultado de cada resolución se muestra por separado (con la etiqueta
resolver_1,resolver_2, etc.), con la IP de resolución, para que pueda ver qué servidor DNS está causando la incoherencia.
Solución de problemas troubleshooting
Los siguientes escenarios combinan lo que es probable que vea en la herramienta con pasos para reducir la causa. Para obtener una copia completa de Copy al portapapeles JSON que ilustra las mismas situaciones, consulte Ejemplo de resultados.
Error de resolución de DNS dns-failed
Salida
El nombre de host no se resolvió usando la configuración de DNS de red avanzada, por lo que la herramienta no puede probar el puerto. En la vista de resultados, Resolución de DNS muestra una cadena de error y Accesibilidad informa de un error de DNS:
DNS Resolution: error: "DNS resolution error: ..."
Reachability: "Unreachable: DNS resolution failed"
Recomendaciones
- Compruebe que el nombre de host es correcto; compruebe si hay errores tipográficos y que está utilizando la zona DNS deseada (la zona incorrecta es un error común).
- Asegúrese de que sus resoluciones DNS (las configuradas en la infraestructura de red) estén accesibles desde el intervalo CIDR de redes avanzadas (el mismo espacio de direcciones que la herramienta y AEM usan para las comprobaciones salientes). Si confía en DNS privados, debe poder acceder a esos servidores a través del túnel VPN o dentro del espacio de direcciones de red que expone el enrutamiento a la red avanzada.
- Compruebe que los servidores DNS configurados pueden resolver el nombre de host. La red avanzada usa solo los solucionadores definidos en la configuración de la infraestructura de red, no DNS públicos (por ejemplo,
8.8.8.8). Si el DNS interno no tiene ningún registro para ese nombre de host, la resolución falla. - Para configuraciones de VPN: Confirme que las direcciones IP del servidor DNS se encuentran en el espacio de direcciones VPN (el CIDR de red remota para el que se creó el túnel). No se puede acceder a los solucionadores de una subred que no se enrute a través del túnel VPN desde la red avanzada.
DNS funciona pero el puerto no es accesible dns-ok-port-blocked
Salida
La herramienta puede resolver el host, pero TCP al puerto no funciona. Un resumen suele tener este aspecto:
DNS Resolution: ips: ["10.0.1.50"]
Port Open: No
Reachability: "Unreachable: Port not accessible"
Recomendaciones
- Revise las reglas de cortafuegos y de lista de permitidos en el servicio de destino; se debe permitir el tráfico entrante desde el intervalo CIDR de la infraestructura de red avanzada (y las direcciones IP de salida que utiliza AEM). Si utiliza una VPN, incluya los CIDR de red remota como su diseño requiere.
- Compruebe que el servicio se está ejecutando y escuchando en el host y el puerto que ingresó en la prueba.
- Para configuraciones de VPN: Confirme que el túnel está activo, el enrutamiento llega a la subred de destino y la dirección de destino se encuentra en el espacio de direcciones de red remota que se transfiere a través de la VPN.
- En su infraestructura, revise grupos de seguridad de red (NSG), reglas de seguridad o equivalentes que podrían bloquear el puerto entre Advanced Networking y el destino.
- Confirme el número de puerto; asegúrese de que el proceso esté escuchando en el puerto que está probando.
La prueba muestra que es accesible, pero AEM no se conecta reachable-but-aem-fails
Salida
La comprobación de conectividad se realiza correctamente. Un resumen conciso suele tener este aspecto:
Port Open: Yes
Reachability: "Reachable"
Ese resultado significa que la ruta desde la red avanzada hasta el host y el puerto que ha probado está abierta. No garantiza que el tráfico de la aplicación AEM esté utilizando esa ruta: cuando se ejecuta el código, es posible que los registros del servicio aún no muestren solicitudes de la IP de salida que espera.
Recomendaciones
- El código de la aplicación debe estar configurado para usar el proxy. La prueba de conectividad demuestra que la ruta de red funciona, pero AEM debe enrutar explícitamente las solicitudes a través del proxy de redes avanzadas (por ejemplo, a través de la variable de entorno
AEM_PROXY_HOST). Si el código realiza conexiones directas sin el proxy, el tráfico no pasa a través de la infraestructura de red avanzada. - Revise la configuración de proxy en sus clientes HTTP. Los clientes HTTP deben usar la misma configuración de proxy (
AEM_PROXY_HOSTy el reenvío de puertos cuando corresponda). - Compruebe la configuración del reenvío de puertos para la red avanzada en el nivel entorno: en
portForwards, cada entrada debe asignarportOrigaportDesten el host de destino correcto.portOriges el puerto al que se conecta el código de su aplicación AEM cuando abre la conexión saliente a través del proxy.portDestes el puerto real en el servicio de destino donde el proceso remoto está escuchando. El host de destino es el nombre de host o dirección de ese servicio tal como se usa en el reenvío. Los tres deben coincidir con la forma en que se escribe la aplicación para conectarse. - Comprobar
nonProxyHosts. Si el host de destino aparece en la lista, solicita omitir el proxy para ese host y no seguirá la ruta de red avanzada que validó.
HTTP muestra un error pero el puerto está abierto http-error-port-open
Salida
TCP se ejecuta correctamente, pero el sondeo HTTP/HTTPS sigue informando de un error. Un resumen suele tener este aspecto:
Port Open: Yes
HTTP Connectivity: error: "Connection error: ..." or "Both HTTPS and HTTP failed. ..."
Reachability: "Reachable"
Recomendaciones
- Es posible que el servicio no hable HTTP o HTTPS; por ejemplo, TCP sin procesar, gRPC u otro protocolo. El sondeo HTTP puede dar error mientras
Port open: YesyReachability: Reachablesigan confirmando que la ruta de acceso de red funciona. Utilice esos campos como fuente fiable para servicios que no sean HTTP. - Investigue TLS y la configuración del certificado. Si HTTPS falla pero HTTP tiene éxito (a veces indicado por una nota como
HTTPS failed, HTTP succeeded), el servicio puede tener problemas de certificado o solo puede ofrecer HTTP en ese puerto.
Tiempo de espera de solicitud timeout
Salida
{ "error": "Request timeout" }
Recomendaciones
- Permitir tiempo de respuesta del servicio: la comprobación utiliza un tiempo de espera de 5 segundos. Los objetivos que respondan más lentamente se agotarán incluso cuando, por lo demás, estén sanos.
- Cuenta para latencia de red. En conexiones VPN, una latencia alta o un túnel en mal estado puede superar el límite de ida y vuelta; revise el estado y el enrutamiento del túnel.
- Vuelva a ejecutar la prueba. Los problemas de red únicos pueden producir un tiempo de espera que no se repite.
Salidas de ejemplo example-outputs
Prueba HTTPS correcta (por ejemplo, API interna en el puerto 443) example-output-successful-https
{
"resolvers": [
{
"name": "default",
"dns_resolution": {
"ips": ["10.0.1.50"]
},
"port_open": true,
"http_connectivity": {
"protocol": "https",
"status_code": 200,
"reason": "200 OK"
},
"reachability": "Reachable"
}
]
}
Prueba de servicio no HTTP correcta (por ejemplo, base de datos en el puerto 5432) example-output-successful-non-http
{
"resolvers": [
{
"name": "default",
"dns_resolution": {
"ips": ["10.0.1.50"]
},
"port_open": true,
"http_connectivity": {
"error": "Not an HTTP/HTTPS service",
"note": "The service appears to be a non-HTTP service (e.g., database, message queue, or custom TCP). Use the port_open and reachability fields to verify connectivity."
},
"reachability": "Reachable"
}
]
}
Error de resolución DNS example-output-dns-resolution-failure
{
"resolvers": [
{
"name": "default",
"dns_resolution": {
"error": "DNS resolution error: dial udp 10.0.0.2:53: i/o timeout"
},
"port_open": false,
"http_connectivity": {
"error": "DNS resolution failed"
},
"reachability": "Unreachable: DNS resolution failed"
}
]
}
Puerto no accesible (cortafuegos/servicio inactivo) example-output-port-not-accessible
{
"resolvers": [
{
"name": "default",
"dns_resolution": {
"ips": ["10.0.1.50"]
},
"port_open": false,
"http_connectivity": {
"error": "Connection error: dial tcp 10.0.1.50:443: i/o timeout"
},
"reachability": "Unreachable: Port not accessible"
}
]
}
Notas importantes important-notes
Qué no hace esta prueba what-this-test-does-not-do
- La prueba no se ejecuta desde un pod de autor o publicación de AEM. Se ejecuta desde infraestructura de proxy de salida. Esto valida la capa de red, no la configuración proxy de nivel de aplicación, en el código.
- No valida la configuración del proxy de la aplicación de AEM. Aunque el resultado sea
Reachable, el código AEM debe configurarse para usar el proxy. - No valida por sí sola la configuración del reenvío de puertos a nivel de entorno. Prueba la conectividad sin procesar desde la ruta de infraestructura.
- No envía cargas útiles personalizadas. Las pruebas HTTP emiten una solicitud
GETbásica a/.
Tiempo de respuesta response-time
- Típico: de 2 a 3 segundos.
- Máximo: tiempo de espera de unos cinco segundos.
- Todas las resoluciones DNS y las comprobaciones de conectividad se ejecutan en paralelo.
Servicios HTTP o no HTTP http-vs-non-http-services
La herramienta intenta establecer una conexión HTTP/HTTPS en cada puerto. Para los servicios no HTTP (por ejemplo, PostgreSQL en el puerto 5432, MySQL en 3306, SFTP en 22, Redis en 6379), la comprobación HTTP puede fallar con un error de conexión; esto es lo que se espera. Confíe en Port open y Reachability para confirmar la conectividad de esos servicios.