Acceso al servidor web de DNAT desde el interior de la LAN

Tengo una red pequeña con un enrutador, que mantiene una conexión a Internet, un servidor y algunas estaciones de trabajo en una red local.

Se debe acceder al servidor desde Internet, y hay varias entradas DNAT establecidas en el iptables del enrutador, como esta:

-A PREROUTING -i ppp0 -p tcp -m multiport --dports 22,25,80,443 -j DNAT --to-destination 192.168.2.10

Los paquetes externos llegan al enrutador a través de la ppp0interfaz, y los internos salen br-lan, que en realidad incluyen el conmutador y el adaptador WLAN. El problema es que, si bien el acceso externo funciona bien, ppp0falla el intento de acceder al servidor desde el interior de la LAN mediante una IP externa resuelta por DNS (asignada a ).

La única solución que pude inventar es agregar entradas estáticas a los enrutadores que /etc/hostsapuntan a la IP interna, pero como no hay comodines (y tengo al menos tres dominios de nivel superior asignados a ese sistema, sin contar decenas de subdominios), eso es bastante crujiente y propenso a fallas. ¿Puedes sugerir algo mejor?

Solo he encontrado esta pregunta , que no fue muy útil.

Si eso es relevante, el enrutador ejecuta OpenWRT 10.03 Kamikaze con dnsmasq.

Me sorprende que después de casi 8 años, nadie haya explicado cómo hacer esto de la manera correcta utilizando el sistema de configuración UCI utilizado por defecto en OpenWRT.

La respuesta de Steven Monday es correcta, pero está usando iptablescomandos directamente, que es una capa más baja que el sistema de configuración 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 combinaciones públicas de IP / puerto desde otro host interno en UCI es habilitando la opción de configuración reflectionbajo 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: De acuerdo con la documentación de OpenWRT indicada, reflectionestá habilitada de forma predeterminada. En mis pruebas, este no fue el caso.

Eliminé mi respuesta original, porque no estaba completamente seguro de que fuera correcta. Desde entonces, he tenido 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 funcionaron para mí (en iptables-saveformato, solo para la nattabla):

-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

La primera POSTROUTINGregla es una forma directa de compartir la conexión a Internet con la LAN. Lo dejé allí para completar.

La PREROUTINGregla y la segunda POSTROUTINGregla juntas establecen los NAT apropiados, de modo que las conexiones al servidor a través de la dirección IP externa pueden ocurrir, independientemente de si las conexiones se originan desde el exterior o desde el interior de la LAN. Cuando los clientes en la LAN se conectan al servidor a través de la dirección IP externa, el servidor ve que las conexiones provienen 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 se cambia el objetivo a -j SNAT --to-source 192.168.2.1, el efecto es (no sorprendentemente) el mismo que el MASQUERADE: el servidor ve las conexiones de los clientes de LAN locales como procedentes de la dirección IP interna del enrutador . Por otro lado, si se cambia el destino 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 de LAN locales como procedentes de la dirección IP externa del enrutador (89.179.245.232).

Finalmente, tenga en cuenta que su regla PREROUTING/ original no funciona, porque la regla nunca coincide con los paquetes que provienen de los clientes LAN (ya que estos no ingresan al enrutador a través de la interfaz). Sería posible hacerlo funcionar agregando una segunda regla solo para los clientes de LAN internos, pero sería poco elegante (IMO) y aún necesitaría referirse explícitamente a la dirección IP externa.DNAT-i ppp0ppp0PREROUTING

Ahora, incluso después de haber presentado una solución "horquilla NAT" (o "NAT loopback", o "reflexión NAT", o como prefiera llamarla) con todo detalle, sigo creyendo que una solución 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. ¿Por qué? Debido a que más personas entienden cómo funciona DNS que entienden cómo funciona NAT, y una gran parte de la construcción de buenos sistemas es elegir partes que se puedan mantener. Es más probable que se entienda una configuración DNS y, por lo tanto, se mantenga correctamente, que una configuración NAT arcana (IMO, por supuesto).

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 firewalls de Cisco, es reescribir las respuestas DNS en el firewall que corresponden a estas direcciones. No creo que haya herramientas para Linux que hagan esto ahora.

Debería poder configurar el enrutamiento en su puerta de enlace para hacer lo correcto. Es posible que deba configurar los servidores para que conozcan 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, usando su dirección "externa", pasaría por el enrutador.

Lo que está pidiendo hacer se llama NAT Loopbacky requiere que agregue una regla SNAT para que los paquetes que se originan desde su LAN a su servidor vuelvan 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

Los comentarios sobre el alojamiento de una versión interna del espacio de nombres \ dominio generalmente es la forma en que he manejado este problema en el pasado. Por supuesto, necesita un servidor DNS internamente para hacer esto.

Se me ocurrió la siguiente solución para permitir que mi red de invitados se conecte a los puertos que fueron enviados desde mi red wan a lan. Este script se coloca en mi sección "Red -> Firewall -> Reglas personalizadas":

# lookup the public IP (DDNS resolves to this)
wanip=$(ip route get 8.8.8.8 | awk -F"src " 'NR==1{split($2,a," ");print a[1]}')

# Guest network to LAN
# srcname is the guest network name, this needs to match for iptables
srcname=guest
# CIDR notation of guest and lan networks
srcnet=192.168.15.0/24
tgtnet=192.168.10.0/24
# router (openwrt) IP on lan network
tgtrouter=192.168.10.1
# host on lan network where ports are normally forwarded
tgthost=192.168.10.5
# ports to forward as a list or range
tcpports=8080,9090
udpports=12345

prechain=prerouting_${srcname}_rule
postchain=postrouting_${srcname}_rule

# reset the tables to prevent duplicate rules
iptables -t nat -F ${prechain}
iptables -t nat -F ${postchain}

iptables -t nat -A ${prechain} -s ${srcnet} -d ${wanip}/32 -p tcp -m tcp -m multiport --dports ${tcpports} -m comment --comment "${srcname} NAT reflection TCP DNAT" -j DNAT --to-destination ${tgthost}
iptables -t nat -A ${postchain} -s ${srcnet} -d ${tgthost}/32 -p tcp -m tcp -m multiport --dports ${tcpports} -m comment --comment "${srcname} NAT reflection TCP SNAT" -j SNAT --to-source ${tgtrouter}
iptables -t nat -A ${prechain} -s ${srcnet} -d ${wanip}/32 -p udp -m udp -m multiport --dports ${udpports} -m comment --comment "${srcname} NAT reflection UDP DNAT" -j DNAT --to-destination ${tgthost}
iptables -t nat -A ${postchain} -s ${srcnet} -d ${tgthost}/32 -p udp -m udp -m multiport --dports ${udpports} -m comment --comment "${srcname} NAT reflection UDP SNAT" -j SNAT --to-source ${tgtrouter}

Para admitir reinicios, necesitaba ejecutar lo siguiente desde la línea de comandos ssh en openwrt (de lo contrario, creo que hay una condición de carrera en la que se agregaron algunas reglas y luego se enjuagaron durante el reinicio):

uci set firewall.@include[0].reload="1"
uci commit firewall

La reflexión NAT se configura para conexiones dentro de la red LAN a sí misma, pero no a otras redes si ha creado múltiples interfaces para aislar el tráfico. Intenté configurar una regla de reenvío desde la interfaz web, pero eso envía todo el tráfico a un puerto desde la red invitada a ese host LAN. Lo anterior solo intercepta las solicitudes a la IP WAN en lugar de todo el tráfico de red.

Se podría usar un DNS interno en lugar de esto, pero solo si todos los puertos hacia adelante solo van a un solo host. Si tiene varios hosts donde reenvía diferentes puertos, puede repetir las reglas para diferentes puertos a diferentes tgthostIP y puertos.