¿Qué capa de IP muestra la página de consulta?
Al abrir la página de Consulta de IP, ves la dirección de salida de esta solicitud tal como la observa el servicio. Si el servicio utiliza un proxy inverso de confianza, normalmente también resolverá la dirección del cliente reenviada según su propia configuración. No tiene por qué coincidir con la dirección de la tarjeta de red de tu equipo: en una red IPv4 doméstica suele haber traducción de direcciones de red (NAT), y aguas arriba puede haber otra capa de NAT, un proxy o una VPN. Debes anotar por separado la “dirección del terminal”, la “dirección WAN del router” y el “valor observado en la web”, en lugar de llamar a todas ellas tu IP pública.
Que un proxy o una VPN cambien la salida web depende de las reglas concretas de enrutamiento y desvío. El proxy del navegador puede reenviar solo el tráfico web, y una VPN del sistema puede transportar únicamente segmentos de red internos de la empresa; solo una configuración de túnel completo enviará el tráfico de Internet correspondiente a la puerta de enlace de la VPN. Por eso, distintas aplicaciones del mismo dispositivo, y las conexiones IPv4 e IPv6, pueden salir por rutas diferentes. Una consulta web por sí sola no permite determinar quién asigna la dirección, si es exclusiva o si el dispositivo usa una VPN; hay que analizarla junto con la configuración de red efectivamente activa en ese momento.
Las direcciones privadas o compartidas normalmente deben buscarse en la tarjeta de red local, en el ONT o en el estado WAN del router. Una consulta normal en la Internet pública no debería tratar direcciones RFC 1918 o RFC 6598 como salida de cliente enrutable globalmente; si la página muestra esos valores, comprueba primero si se trata de información local o de un problema de configuración de reenvío. Que una dirección sea pública no es lo mismo que su reputación: una dirección enrutable puede tener historial de abuso, y una dirección privada no puede participar directamente en la comparación de reputación pública. Para más detalles, consulta Reputación IP: cómo interpretar riesgos y listas negras.
Dispositivo, router y operador: la relación de direcciones en cuatro capas
Primero hay que entender las direcciones en cuatro ubicaciones. La primera capa es la dirección que usa el terminal en la red local, por ejemplo 192.168.50.8; la segunda es la interfaz WAN del router doméstico, que puede recibir una dirección pública o una privada asignada por el ONT superior; la tercera es la red del operador: cuando se implementa CGNAT, la dirección del lado del usuario pasa por la traducción del operador y se comunica con el exterior mediante una dirección pública, y el lado del usuario puede usar 100.64.0.0/10; la cuarta es el origen de la solicitud que observa el servicio de destino. Si además hay un proxy, el destino verá la salida del proxy.
A continuación se muestra un caso doméstico de doble NAT, claramente marcado como ilustrativo. Supón que el ONT de un usuario está configurado por el operador en modo enrutador; la dirección LAN del ONT es 192.168.1.1 y el operador asigna a su interfaz WAN la IP pública 203.0.113.10 (dirección ilustrativa, no una dirección real de usuario). El usuario conecta además un router inalámbrico; la interfaz WAN de ese router recibe 192.168.1.100 del ONT y su dirección LAN es 192.168.50.1. El teléfono del usuario obtiene la dirección 192.168.50.8. Cuando el teléfono visita un sitio de consulta de IP, el router inalámbrico cambia primero la dirección de origen a 192.168.1.100; después el ONT la cambia a 203.0.113.10, y finalmente el servidor ve 203.0.113.10. En el teléfono, la IP de red local que ves es 192.168.50.8, y en el panel del router, la IP WAN que ves es 192.168.1.100; ninguna de las dos es una dirección pública, pero la salida final sí es una dirección pública. Este caso sirve únicamente para explicar el orden de la traducción de direcciones y no representa ningún entorno real de usuario.
Si la WAN del router es 100.64.0.2 y la salida web es otra IPv4 enrutable globalmente, eso es coherente con una traducción de direcciones aguas arriba, pero aun así conviene confirmar la arquitectura concreta con la documentación del operador. Si la WAN es 192.168.1.2, puede tratarse del modo enrutador del ONT, de un segundo router o de una puerta de enlace corporativa superior; ese valor por sí solo no te dice qué equipo hizo NAT. Registrar la topología y el papel de cada interfaz ayuda más a diagnosticar que capturar una única dirección.
Identificación precisa de direcciones privadas y espacios de direcciones compartidos
RFC 1918 define tres rangos IPv4 privados: 10.0.0.0/8, es decir, de 10.0.0.0 a 10.255.255.255; 172.16.0.0/12, de 172.16.0.0 a 172.31.255.255; y 192.168.0.0/16, de 192.168.0.0 a 192.168.255.255. Todas las IPv4 que empiezan por 10 están dentro del primer rango, pero no todas las direcciones que empiezan por 172 o 192 son privadas. Que una dirección no esté en estos tres rangos tampoco significa automáticamente que pueda usarse en la Internet pública; hay que comprobar también otros rangos de uso especial.
RFC 6598 define el espacio de direcciones compartidas 100.64.0.0/10, de 100.64.0.0 a 100.127.255.255, para escenarios concretos dentro de la red de un proveedor de servicios; no es una dirección enrutable globalmente. Que la WAN del router esté en este rango es una pista importante de una red compartida aguas arriba, pero por sí sola no prueba qué tipo de CGNAT ha implementado el operador. A la inversa, no ver este rango tampoco descarta NAT aguas arriba; el plan de direccionamiento interno del operador puede ser distinto.
Para determinarlo, hay que comparar según el rango completo; no se puede etiquetar como CGNAT todas las direcciones que empiezan por 100. Las direcciones compartidas suelen estar en el lado anterior a la traducción, mientras que la consulta pública muestra la salida enrutable global posterior a la traducción; no son resultados contradictorios entre sí. Comprueba además si la consulta pasa por un proxy, si usa la misma WAN y la misma familia de direcciones. Solo fijando estas condiciones, las diferencias de dirección se convierten en pistas explicativas; si el plan contratado incluye una IPv4 pública asignada directamente, eso se confirmará siempre con el operador y con la configuración real de la red.
Cómo comparar la dirección WAN con la salida web
En la medida de lo posible, registra el IPv4 de salida de la página web a la misma hora, en el mismo terminal y bajo la misma red, y luego verifica el IPv4 WAN del router que realmente transporta la solicitud. Volver a marcar, cambiar de Wi-Fi, usar doble WAN o dividir el tráfico mediante proxy afectará la comparación. El método de verificación de IPv6 es diferente: el terminal normalmente tiene su propia dirección IPv6 global, por lo que no puede exigirse que sea igual al IPv6 WAN del router. Debe verificarse la dirección de origen utilizada por el terminal en esta ocasión, el prefijo delegado por el operador y la ruta esperada; las direcciones IPv6 temporales también pueden cambiar con el tiempo.
En una red doméstica, prioriza revisar la página de estado y la topología existente; no es necesario restablecer el dispositivo a los valores de fábrica para ver las direcciones. Los usuarios de redes empresariales o de campus pueden entregar los resultados de la consulta del terminal al administrador de red, quien verificará la salida y la conversión en el nivel superior. Si el dispositivo tiene múltiples interfaces, indica el nombre y la función de cada interfaz, y distingue la dirección de gestión del ONT, la dirección LAN del router, la dirección WAN y la dirección de la interfaz virtual VPN; de lo contrario, varios valores correctos juntos podrían llevar a conclusiones erróneas.
Bajo la misma solicitud IPv4, sin proxy y con la WAN seleccionada correctamente, la WAN es igual a la salida de la página web, y normalmente no se admite la inferencia de que "esta ruta pasa por un CGNAT adicional que cambia el IPv4 de origen". Sin embargo, que las direcciones sean iguales no garantiza asignación estática, uso exclusivo ni permitir conexiones entrantes; las políticas del operador y los cortafuegos del host y del router aún pueden restringir el acceso. La capacidad de entrada debe probarse desde una red externa independiente contra un servicio que tú administras, registrando por separado el protocolo, el puerto y la fase de fallo.
¿Cuáles son otras razones por las que la WAN y la salida son diferentes?
Si la dirección WAN y la salida de la página web son diferentes, considera primero la topología real. Cuando el ONT está en modo router, el router de nivel inferior puede obtener una dirección privada de él, formando doble NAT; una VPN del sistema también puede hacer que la página web acceda a Internet a través de una puerta de enlace remota. Primero confirma el modo de trabajo del ONT, la división del tráfico de la VPN y la interfaz que realmente transporta la solicitud, y luego determina en qué capa se origina la diferencia. Los cambios en la configuración de puente, marcado o túnel deben ser confirmados por el operador o el administrador según las necesidades de la red; no se debe ajustar el método de conexión solo para que los dos números sean iguales.
El proxy del navegador también cambia la salida de la página web, mientras que otras aplicaciones del mismo dispositivo pueden conectarse directamente. La ventana de incógnito normalmente no omite el proxy del sistema y no garantiza deshabilitar todas las extensiones; la configuración del navegador utilizada para comparar debe confirmar el estado del proxy y de las extensiones. Las puertas de enlace de seguridad empresarial, los servicios de navegación remota y la programación de múltiples salidas también pueden causar diferencias. Para dispositivos gestionados, es más eficaz pedir directamente al administrador que verifique las políticas que intentar cerrar el túnel empresarial por tu cuenta.
La exclusión por capas debe realizarse en orden. Primero confirma que no haya VPN o proxy activado en el dispositivo, luego verifica si la dirección WAN del router está dentro del rango RFC 1918 o RFC 6598. Si la WAN es una dirección privada, es posible que el ONT siga en modo router; si la WAN es 100.64.x.x, es posible que el operador use CGNAT; si la WAN es una dirección pública pero la salida de la página web es diferente, puede haber un proxy o una puerta de enlace empresarial. No saques conclusiones basándote en una sola captura de pantalla, porque las direcciones pueden cambiar dinámicamente y el software de proxy puede iniciarse con el sistema. Mantén registros de observaciones en múltiples momentos y compáralos con los cambios de topología de red para mejorar la precisión del diagnóstico.
IPv4 e IPv6 deben verificarse por separado
IPv4 e IPv6 suelen desplegarse en paralelo, pero tienen asignación de direcciones, enrutamiento y políticas de cortafuegos propias. El terminal puede usar IPv4 mediante NAT y, al mismo tiempo, obtener directamente una dirección IPv6 global. El éxito del acceso IPv6 solo indica que esta ruta IPv6 y el servicio están disponibles; el fallo del acceso IPv4 también puede implicar DNS, enrutamiento, proxy o escucha del servidor. El CGNAT es especialmente relevante para conexiones entrantes IPv4 sin mapeo establecido, pero no se puede usar para explicar todos los fallos de salida IPv4.
Comprobación del entorno del navegador puede ayudar a observar la salida de las solicitudes y el comportamiento de red del navegador, pero no demuestra que un host externo pueda conectarse activamente a tu servicio IPv6. La verificación de entrada requiere un servicio que realmente escuche, reglas de cortafuegos adecuadas y pruebas desde una red externa independiente. Las reglas permitidas para los dos protocolos pueden ser diferentes, por lo que "la página web puede conectarse" y "otros pueden entrar" deben verificarse por separado; no se puede afirmar que la entrada está abierta solo porque la página muestre una dirección IPv6 global.
Al diagnosticar, registra por separado el destino IPv4 e IPv6, la dirección de origen y la fase de fallo. Si sospechas que la ruta no cumple con lo esperado del proxy o la VPN, puedes leer Fugas de WebRTC, DNS e IPv6: cómo comprobarlas. Los candidatos WebRTC reflejan pistas sobre interfaces o salidas que el navegador puede recopilar; las pruebas DNS normalmente observan el origen del resolvedor recursivo cuando la consulta llega al servidor autoritativo, no deben tomar la IP de destino obtenida de la resolución del dominio como tu salida. Desactivar IPv6 puede ocultar el fenómeno; primero debes aclarar exactamente qué ruta no cumple con lo esperado.
¿Cómo analizar el fallo en el mapeo de puertos?
Cuando falla el mapeo de puertos, primero confirma que el servicio local está en ejecución y escuchando en la interfaz y el puerto esperados. Si solo está vinculado a 127.0.0.1 o ::1, los dispositivos externos no pueden conectarse directamente; puedes vincularlo a una interfaz interna específica según las necesidades del servicio y restringir el acceso con el cortafuegos del host. Cambiar el servicio para que escuche en todas las interfaces no es la única solución y puede aumentar la superficie de exposición. Primero verifica la respuesta de la aplicación desde otro dispositivo en la LAN y luego diagnostica por capas el router y la red ascendente.
Si la escucha local y el cortafuegos del host están bien, el siguiente paso es revisar las reglas de reenvío de puertos en el router. Los errores comunes incluyen: reenviar a una IP interna incorrecta, que los puertos internos y externos no coincidan, o seleccionar TCP cuando el servicio realmente usa UDP. Algunos routers también requieren permitir explícitamente ese puerto en el cortafuegos y reiniciar para que las reglas surtan efecto. En este punto, puedes probar el servicio desde otra máquina en la LAN para aislar los problemas de configuración del router.
Si la configuración del router es correcta pero aún no se puede entrar, compara el IPv4 WAN con la salida de la página web y verifica el NAT ascendente y las políticas del operador. Prueba de conexión TCP puede proporcionar observación externa dentro del rango de destinos y puertos públicos permitidos por la herramienta; si la entrada es rechazada por la política de la herramienta, eso no es evidencia de que la conexión al destino haya fallado. La prueba TCP tampoco sustituye la verificación de servicios UDP. Si la prueba externa falla, conserva la razón original; no se debe atribuir todo a CGNAT.
Si la prueba externa muestra que el puerto es inaccesible, también considera si el operador ha bloqueado puertos de entrada comunes, como 80, 25, 445, etc. Algunos operadores bloquean todas las conexiones entrantes por defecto, a menos que el usuario solicite una IP pública o la apertura de puertos específicos. En ese caso, contacta al operador para confirmar la política en lugar de modificar repetidamente la configuración local. El orden de diagnóstico puede organizarse así: escucha local, cortafuegos del host, reenvío del router, NAT ascendente, restricciones del operador; cambia solo una variable en cada paso para identificar con precisión el problema.
¿Cómo afecta la salida compartida a los captchas y la reputación de la IP?
Cuando usas una IP de salida compartida, el comportamiento de otros usuarios puede afectar la reputación de esa dirección y, por lo tanto, provocar más captchas o restricciones de acceso. Es necesario distinguir entre la observación a nivel de dirección y el usuario específico. La observación a nivel de dirección solo indica que una IP ha tenido solicitudes automáticas o tráfico anómalo en algún momento; no puede determinar quién las originó ni demostrar que el usuario actual es malicioso. Bajo CGNAT del operador, cientos o incluso más usuarios pueden compartir la misma dirección IPv4, y la anomalía de cualquiera de ellos puede quedar registrada en esa dirección por los sitios web.
La ayuda sobre tráfico inusual de Google explica que las consultas automáticas de otros usuarios en una red compartida o VPN pueden provocar avisos de tráfico inusual. Esta es una causa posible, pero no significa que se pueda determinar a partir del aviso qué usuario o programa envió la solicitud, ni afirmar que esa salida haya entrado en alguna lista negra pública. Debes conservar el error específico y la hora en que ocurrió, y revisar la red, el navegador y las reglas del sitio web por separado según la IP en una lista negra o CAPTCHA constante: qué hacer.
Una IP compartida no implica inseguridad ni malicia del usuario. Muchas organizaciones usan CGNAT para ahorrar direcciones IPv4, y es una práctica normal de ingeniería de redes. La evaluación de seguridad debe basarse en el tráfico y las sesiones concretas, no en una dirección compartida. Si contactas con un sitio web u operador por problemas de captchas, puedes indicar que estás en un entorno de salida compartida y aportar evidencias observables de horarios de acceso y comportamiento, en lugar de pedir que "limpien" toda la IP, porque limpiarla podría ocultar anomalías reales.
Para los administradores de sitios web, depender de la reputación de una sola IP para tomar decisiones puede causar falsos positivos. Es más razonable combinar múltiples señales, como el agente de usuario, la huella TLS y los patrones de comportamiento, y ofrecer métodos de verificación adicionales a los usuarios de salidas compartidas, como códigos por correo electrónico o SMS. Si un usuario normal nota un aumento de captchas, puede intentar cambiar de red o informar al sitio web del rango de IP de salida y los horarios de acceso, pero no debe usar herramientas de evasión para eludir los controles de acceso.
Qué escribir en el ticket al operador
Al enviar un ticket al operador, cuanto más completa sea la información, más rápido se procesará. Debes indicar la zona horaria y la hora exactas, por ejemplo, la fecha y el intervalo de tiempo específicos en UTC+8, para que el operador pueda cotejar los registros. Además, adjunta la dirección IP que muestra la interfaz WAN del enrutador; si la WAN del enrutador no es una dirección pública, indícalo también. La IP de salida observada externamente se puede obtener mediante sitios de consulta; presentar ambas permite determinar rápidamente si hay un NAT intermedio.
Si usas IPv4 e IPv6 simultáneamente, debes explicarlo por separado. Muchas redes móviles o banda ancha doméstica ya tienen IPv6 habilitado, pero IPv4 aún puede pasar por CGNAT. Al describir el problema, no digas solo "no puedo acceder"; indica el protocolo de entrada necesario, por ejemplo, el puerto TCP 443 para HTTPS o el puerto UDP 51820 para WireGuard. Describe también la topología actual, como si el ONT está en modo puente o enrutador, la marca y modelo del enrutador, y si hay un enrutador secundario.
En el ticket no debes pedir al operador que "limpie" la IP de una lista negra, a menos que tengas evidencia concreta de que la dirección fue marcada erróneamente. Una pregunta más adecuada es: ¿el plan actual ofrece una dirección IPv4 pública? ¿Permite conexiones entrantes? Si IPv4 no está disponible, ¿ofrece entrada IPv6? Estas preguntas se refieren directamente a las capacidades de la red, no a la reputación. No es necesario proporcionar de forma proactiva registros sensibles, como registros completos de tráfico o credenciales de acceso, pero si el operador necesita investigar más, puedes aportar registros anonimizados según el principio de mínima necesidad.
Si el operador pide evidencias, puedes preparar una línea de tiempo: cuándo configuraste el reenvío de puertos, desde qué red externa probaste, qué herramienta de prueba usaste y qué resultado obtuviste. Estas evidencias deben mantenerse sin modificar; no edites capturas de pantalla ni salidas. Al hacer seguimiento del ticket, registra la hora de cada comunicación, el número de agente y las conclusiones, para tener un registro auditable. Escribir claramente la solución esperada y el siguiente plazo también mejora la eficiencia del procesamiento.
Qué eligen los usuarios domésticos y los desarrolladores
Si un usuario doméstico necesita acceder de forma remota a dispositivos que administra, primero debe confirmar si su plan admite entrada pública IPv4 o IPv6 y luego elegir una solución adecuada. Si no hay capacidad de entrada directa, puede evaluar túneles inversos o servicios de retransmisión autenticados, verificando el control de acceso, el mantenimiento, el costo y la disponibilidad, y cumpliendo las normas de administración de su red. La necesidad de esta solución depende de los objetivos del negocio; no es necesario considerar "debe tener IPv4 pública" como requisito previo para todo acceso remoto.
Sobre la IP pública y la accesibilidad de puertos, los usuarios domésticos suelen tener un malentendido: piensan que si la dirección WAN del enrutador es pública, todos los puertos son accesibles desde Internet. En realidad, muchas bandas anchas domésticas, incluso con IPv4 pública asignada, bloquean puertos de servicios comunes en los equipos de borde del operador. Además, una IP pública dinámica puede cambiar, por lo que el acceso remoto requiere DNS dinámico. Si solo es para acceso temporal, es más seguro usar la administración remota del fabricante o un servicio de retransmisión autorizado.
Al integrar servicios de Internet, un desarrollador no debe considerar que el acceso saliente exitoso desde su máquina equivale a la aceptación de entrada desde Internet. El acceso saliente exitoso a través de NAT o firewall solo indica que la ruta de salida está despejada, no que un externo pueda conectarse activamente a su máquina. Por ejemplo, si un servicio web se ejecuta en localhost y una solicitud curl a una API externa tiene éxito, eso no demuestra que usuarios externos puedan acceder a ese servicio web. Se necesita una prueba activa desde otra máquina en una red diferente o usando una herramienta de detección TCP externa.
El desarrollador también debe verificar la publicación de puertos entre contenedores, máquinas virtuales y el host. Que un servicio funcione dentro de un contenedor no significa que el host haya abierto ese puerto en la interfaz esperada; que la dirección loopback del host sea accesible no implica que lo sea desde la LAN o Internet. La aceptación final debe especificar el punto de observación y el resultado de la aplicación: los servicios TCP deben completar la conexión y la interacción esperada; los servicios UDP deben enviar solicitudes conformes al protocolo y comprobar la respuesta. No se puede concluir que "TCP se estableció" usando UDP sin handshake de conexión.
Tres preguntas frecuentes
¿La IP pública es fija? Depende del operador y del plan. La banda ancha doméstica suele usar direcciones dinámicas; incluso si se asigna una IPv4 pública, puede cambiar al expirar la concesión, al volver a marcar o al reiniciar el equipo. Las líneas empresariales o los planes de IP fija pueden ofrecer direcciones estáticas, pero con costo adicional. Las direcciones IPv6 normalmente se asignan por delegación de prefijo; si el prefijo del operador no cambia, la dirección del dispositivo puede permanecer estable durante un tiempo, pero no se garantiza que sea permanente. No asumas que la dirección es fija; los servicios remotos aún necesitan DNS dinámico o actualizaciones periódicas de configuración.
¿Reiniciar el enrutador siempre cambia la dirección? No necesariamente. El cambio depende de la duración del arrendamiento DHCP, la política del grupo de direcciones del operador y el método de autenticación. A veces la dirección no cambia tras reiniciar, a veces sí; no hay una regla general. En un entorno CGNAT, reiniciar puede cambiar la relación de mapeo interna del operador, no la dirección de salida pública. Si necesitas determinar si la salida actual cambió, puedes registrar la IP de salida antes y después del reinicio usando varios servicios de consulta independientes, manteniendo la zona horaria y el entorno de red sin cambios.
Múltiples usuarios que comparten una IP pública no implica automáticamente que puedan acceder entre sí, ni constituye una prueba de aislamiento de seguridad. El aislamiento real depende de la configuración de la red de acceso, los controles de acceso y los firewalls de los dispositivos; no se puede considerar NAT como un límite de seguridad completo. Una salida compartida puede generar asociación de reputación y hacer que usuarios normales encuentren captchas o restricciones juntos, pero el impacto específico depende de las políticas del sitio web de destino. Se deben evaluar por separado la conectividad, la reputación de la dirección y la seguridad del dispositivo, evitando resumir todos los problemas con una etiqueta de "compartido".
Formar un registro revisable
Al investigar problemas de accesibilidad de IP pública y puertos, los registros deben permitir una revisión posterior. Al crear una línea de tiempo, utiliza un enfoque ilustrativo: por ejemplo, un día a las 10:00 configuras el reenvío de puertos en el enrutador, a las 10:05 pruebas el puerto 8443 desde una red externa con una herramienta de detección TCP y falla; a las 10:10 modificas el firewall del host, a las 10:15 vuelves a probar y aún falla. Este registro muestra claramente cada acción y resultado. No omitas las operaciones fallidas, porque los fallos también ayudan a descartar variables.
Cambia solo una variable a la vez y registra los resultados antes y después; ajustar el firewall y las reglas del enrutador simultáneamente dificulta determinar la causa. Puedes guardar páginas de estado, textos de error, tiempos de prueba y resultados de salida; al proporcionar materiales externos, elimina información irrelevante como cuentas y tokens. Para comprender los tipos de direcciones, las fuentes y los límites de observación, puedes leer la Fuentes de datos y metodología de este sitio. El objetivo del registro es permitir que el siguiente investigador reproduzca las condiciones, no acumular capturas de pantalla inexplicables.
La detección de IP compartida o proxy puede producir falsos positivos, por ejemplo, una red doméstica normal marcada como VPN o proxy por una salida compartida. En este caso, debes recopilar la IP de salida, el tiempo de consulta y la plataforma de detección, y registrar las diferencias de juicio entre múltiples plataformas. No dependas solo de una lista negra o servicio de detección; algunas plataformas no son amigables con los segmentos CGNAT. Para casos de falsos positivos relacionados y direcciones de investigación, consulta Tu IP aparece como VPN o proxy: cómo revisar un falso positivo, donde se explica cómo distinguir las marcas a nivel de dirección del comportamiento real de proxy.
Cuando los registros de investigación son lo suficientemente completos pero aún no se puede resolver el problema, debes establecer condiciones claras de detención. Por ejemplo: ya has modificado la escucha local y el firewall, confirmado que las reglas del enrutador son correctas, probado desde dos redes externas diferentes y ambas fallaron, y el operador respondió que no hay capacidad de entrada. En este punto, el siguiente paso debe ser solicitar una dirección pública al operador o adoptar un esquema de retransmisión autorizado, en lugar de seguir adivinando o modificando. Al finalizar, archiva todos los registros, marca la conclusión como "no se pudo establecer la conexión entrante, la causa apunta a la política del operador" y adjunta la cadena de evidencia.
