Solución 1:
Eliminé mi respuesta original porque no estaba completamente seguro de que fuera correcta. Desde entonces, tuve algo de tiempo para configurar una pequeña red virtual de máquinas virtuales para simular la red en cuestión. Aquí está el conjunto de reglas de firewall que funcionó para mí (en iptables-save formato, para el nat solo tabla):
-A PREROUTING -d 89.179.245.232/32 -p tcp -m multiport --dports 22,25,80,443 -j DNAT --to-destination 192.168.2.10
-A POSTROUTING -s 192.168.2.0/24 -o ppp0 -j MASQUERADE
-A POSTROUTING -s 192.168.2.0/24 -d 192.168.2.10/32 -p tcp -m multiport --dports 22,25,80,443 -j MASQUERADE
El primer POSTROUTING La regla es una forma sencilla de compartir la conexión a Internet con la LAN. Lo dejé ahí para completarlo.
El PREROUTING regla y el segundo POSTROUTING juntos establecen las NAT apropiadas, de modo que las conexiones al servidor a través de la dirección IP externa puedan ocurrir, independientemente de si las conexiones se originan desde fuera o desde dentro de la LAN. Cuando los clientes de la LAN se conectan al servidor a través de la dirección IP externa, el servidor ve las conexiones como provenientes de la dirección IP interna del enrutador (192.168.2.1).
Curiosamente, resulta que hay un par de variaciones de la segunda regla POSTROUTING que también funcionan. Si el objetivo se cambia a -j SNAT --to-source 192.168.2.1 , el efecto es (como era de esperar) el mismo que el MASQUERADE :el servidor considera que las conexiones de los clientes LAN locales se originan en el interno del enrutador. Dirección IP. Por otro lado, si el objetivo se cambia a -j SNAT --to-source 89.179.245.232 , entonces los NAT aún funcionan, pero esta vez el servidor ve las conexiones de los clientes LAN locales como originadas en el externo del enrutador. Dirección IP (89.179.245.232).
Finalmente, tenga en cuenta que su PREROUTING original /DNAT regla con -i ppp0 no funciona, porque la regla nunca coincide con los paquetes provenientes de los clientes LAN (ya que estos no ingresan al enrutador a través del ppp0 interfaz). Sería posible hacerlo funcionar agregando un segundo PREROUTING regla solo para los clientes LAN internos, pero sería poco elegante (OMI) y aún necesitaría referirse explícitamente a la dirección IP externa.
Ahora, incluso después de haber presentado una solución de "NAT de horquilla" (o "bucle invertido de NAT", o "reflejo de NAT", o como se prefiera llamarlo) con todos los detalles, sigo creyendo que una solución de DNS de horizonte dividido... -con clientes externos resolviendo a la IP externa y clientes internos resolviendo a la IP interna---sería la ruta más recomendable a seguir. ¿Por qué? Porque más personas entienden cómo funciona DNS que entender cómo funciona NAT, y una gran parte de construir buenos sistemas es elegir usar partes que se puedan mantener. Es más probable que se entienda una configuración de DNS y, por lo tanto, se mantenga correctamente, que una configuración de NAT arcana (en mi opinión, por supuesto).
Solución 2:
Me sorprende que después de casi 8 años, nadie haya explicado cómo hacer esto de forma correcta usando el sistema de configuración UCI que se usa por defecto en OpenWRT.
La respuesta de Steven Monday es correcta, pero está usando iptables comandos directamente, que es una capa más baja que el sistema de configuración de UCI, y es mejor que la mayoría de los usuarios de OpenWRT no la toquen si es posible.
La forma correcta de acceder a los servidores internos a través de sus combos de IP/puerto público desde otro host interno en UCI es habilitando la opción de configuración reflection debajo de cada objetivo DNAT específico en el archivo /etc/config/firewall . Este comportamiento está documentado aquí.
Por ejemplo:
config redirect
option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'tcp'
option src_dport '44322'
option dest_ip '192.168.5.22'
option dest_port '443'
option name 'apache HTTPS server'
option reflection '1'
Nota:Según la documentación de OpenWRT indicada, reflection está habilitado de forma predeterminada. En mis pruebas, este no fue el caso.
Solución 3:
Una solución común es apuntar sus hosts internos a un servidor DNS local que devuelve la dirección "interna" correcta para estos nombres de host.
Otra solución, y estamos usando esto donde trabajo en nuestros cortafuegos de Cisco, es reescribir las respuestas de DNS en el cortafuegos que corresponden a estas direcciones. No creo que haya herramientas para Linux que hagan esto en este momento.
Debería poder configurar el enrutamiento en su puerta de enlace para hacer lo correcto. Es posible que deba configurar los servidores para que estén al tanto de su dirección IP asignada externamente (por ejemplo, asignándola a una interfaz ficticia). Con esta configuración, la comunicación de un sistema interno a otro sistema interno, utilizando su dirección "externa", pasaría por el enrutador.
Solución 4:
Lo que pide hacer se llama NAT Loopback y requiere que agregue una regla SNAT para que los paquetes que se originan desde su LAN a su servidor regresen a través del enrutador:
-A POSTROUTING -p tcp -s 192.168.2.0/24 -d 192.168.2.10 -m multiport --dports 22,25,80,443 -j SNAT --to-source 89.179.245.232