No se puede acceder al servicio externo desde la LAN interna

Tengo un extraño problema de reenvío de puertos. Traté de abrir mi puerto 22 a la red externa. Pude acceder a él siempre que no esté dentro de la LAN. Puedo acceder desde mi oficina, por ejemplo. Pero desde la LAN, puedo acceder al puerto usando la IP local, pero no puedo acceder al puerto usando la IP externa. Es como si el enrutador estuviera bloqueando el loopback. Verifiqué todas las configuraciones de mi enrutador, apagué todo lo relacionado con el firewall / filtrado. ¿Algunas ideas?

Suponiendo que Spiff es correcto, y su enrutador no puede manejar el reenvío de puertos a la IP externa desde dentro de la red, hay una pequeña solución (y parece que este es el caso);

Puede editar el archivo hosts, que se puede encontrar en / etc / hosts en la mayoría de los sistemas unix y en C: \ Windows \ system32 \ drivers \ etc \ en Windows.

si agregas

192.168.0.15  example.com

en ese archivo, su computadora irá a la IP especificada cada vez que intente acceder a example.com. Por supuesto, tendrá que hacer esto en cada computadora que desee usar dentro de la red.

Puede consultar el artículo de Wikipedia para obtener más detalles sobre dónde encontrarlo: https://en.wikipedia.org/wiki/Hosts_file

Dado que mencionó el reenvío de puertos, supongo que su puerta de enlace doméstica está actuando como una puerta de enlace NAT, o más específicamente NAPT. Lo que está tratando de hacer se llama "horquilla NAT" o "horquilla NAT", en referencia a la forma en que una horquilla literal se dobla sobre sí misma (el término "giro de horquilla" usa la misma alusión para una curva cerrada donde un camino se dobla sobre sí mismo).

Algunas puertas de enlace NAT son basura y no son compatibles. Puede ser hora de explorar sus opciones de actualización.

Hay una respuesta muy simple a esta. El NAT se interpone en el camino.

1. Su computadora abre una conexión a [ExternalIP]
2. Su enrutador reenvía esa conexión a [SSHInternalIP]. Su servidor SSH ve una conexión desde [YourInternalIP].
3. Su servidor SSH envía sus paquetes a [YourInternalIP].
4. Su computadora ve un paquete extraño proveniente de una IP con la que nunca habló y lo descarta.
5. Su conexión a TCP / 22 falla porque el protocolo de enlace de 3 vías TCP nunca se completa.

Estás intentando hablar con una IP pública, pero las respuestas provienen de una IP interna. Su computadora no puede hacer que los dos trabajen juntos. La solución es utilizar la IP interna siempre que esté detrás del enrutador. Evito este problema en mis computadoras portátiles usando diferentes cadenas de conexión ssh dependiendo de dónde me encuentre.

Por lo que entiendo al ejecutar un enrutador OpenBSD con NAT, Spiff es correcto en su respuesta: el problema que está experimentando es porque la puerta de enlace NAT no admite lo que está tratando de hacer.

Su estación de trabajo está enviando paquetes con una IP de origen de una dirección interna (por ejemplo, 10.0.0.2), pero la dirección de destino es su IP de prueba. Cuando los paquetes llegan a su servidor (SSH?) En el puerto 22, el servidor responde a su estación de trabajo directamente y no hay NAT; ahora, cuando su estación de trabajo recibe una respuesta de 10.0.0.3 cuando esperaba una respuesta de su dirección externa, descarta los paquetes.

Parece un problema trivial, pero se puede resolver actualizando el archivo HOSTS de su estación de trabajo, agregando un servidor DNS interno (o editando las entradas del servidor DNS), o creando una regla NAT para manejar el interno-> externo-> interno tráfico.