Acceder a servicio en ip publica mapeada a tu propia maquina con iptables

root — Thu, 31 Dec 2009 10:07:03 +0000

La semana pasada tuve que mapear un puerto de una ip del firewall para que llegase a una máquina de una subred interna que tenía como puerta de enlace una ip de la subred interna del firewall. Accediendo desde afuera de nuestra red el puerto funcionaba sin problemas haciendo la redirección con rinetd o con las siguientes reglas en iptables.

iptables -A INPUT -i INTERFAZ_PUBLICO_FIREWALL -p tcp –dport PUERTO_PUBLICO_FIREWALL -j ACCEPT
iptables -A PREROUTING -i INTERFAZ_PUBLICO_FIREWALL -t nat -p tcp –dport PUERTO_PUBLICO_FIREWALL -j DNAT –to IP_SERVICIO_RED_INTERNA:PUERTO_SERVICIO_RED_INTERNA
iptables -A FORWARD -i INTERFAZ_PUBLICO_FIREWALL -p tcp -d IP_SERVICIO_RED_INTERNA –dport PUERTO_SERVICIO_RED_INTERNA -j ACCEPT

De esta manera todos los paquetes que vengan de Internet al puerto publico de mi firewall irán al puerto del servicio que está corriendo en la ip de la máquina de la subred interna. El problema es cuando te intentas conectar desde un host de la misma red local a la que pertenece el servidor interno (conectándote a la ip pública del firewall) . No se puede. Es un problema de enrutado: comenzaremos estudiando lo que ocurre en el caso normal. Veamos que ocurre paso a paso:

El paquete deja la máquina de la red interna para dirigirse a ip pública del firewall.

El paquete llega al cortafuegos.

El paquete sufre la traducción DNAT y todas las acciones necesarias se toman en consecuencia, si bien al paquete no se le efectúa ninguna traducción SNAT y mantiene la misma dirección IP de origen (es decir una ip de la red interna)

El paquete sale del cortafuegos y alcanza la máquina que está corriendo el servicio

El servidor interno intenta responder al paquete y observa en las tablas de enrutado que el
paquete viene de una máquina local de la misma red, por lo que intenta enviar el paquete
directamente a la dirección IP de origen (que a partir de ese momento se convierte en la dirección IP
de destino).

El paquete llega al cliente, que no sabe qué hacer puesto que el paquete devuelto no proviene del
host al que envió la petición original. Por éllo el cliente desecha el paquete y continúa esperando la
respuesta válida.

Solución

Una solución es hacer una traducción SNAT a todos los paquetes que entren al cortafuegos y a los que sabemos que también se les va a aplicar la traducción DNAT. Por ej., vamos a efectuar una traducción SNAT a los paquetes que entren al firewall y estén destinados a la ip interna de nuestro servicio en el puerto correspondiente, de forma que parecerá que provengan de la ip de la subred interna del firewall. Ésto forzará al servidor interno a devolver los paquetes a través del cortafuegos, que invertirá la traducción DNAT y los reenviará al cliente.

iptables -A INPUT -i INTERFAZ_PUBLICO_FIREWALL -p tcp –dport PUERTO_PUBLICO_FIREWALL -j ACCEPT
iptables -t nat -A PREROUTING –dst IP_PUBLICA_FIREWALL -p tcp –dport PUERTO_PUBLICO_FIREWALL -j DNAT –to-destination IP_SERVIDOR_INTERNO:PUERTO_SERVICIO_INTERNO
iptables -t nat -A POSTROUTING -p tcp –dst IP_SERVIDOR_INTERNO –dport IP_SERVICIO_INTERNO -j SNAT –to-source IP_INTERNA_FIREWALL
iptables -t nat -A OUTPUT –dst IP_PUBLICA_FIREWALL -p tcp –dport PUERTO_PUBLICO_FIREWALL -j DNAT –to-destination IP_SERVIDOR_INTERNO:PUERTO_SERVICIO_INTERNO
iptables -A FORWARD -i INTERFAZ_PUBLICO_FIREWALL -p tcp -d IP_SERVIDOR_INTERNO –dport PUERTO_SERVICIO_INTERNO -j ACCEPT

No sé si lo he explicado claro y si hay alguna forma mejor de hacerlo, pero a mi me ha funcionado.

La entrada Acceder a servicio en ip publica mapeada a tu propia maquina con iptables se publicó primero en Android, administracion de sistemas y seo.

firewall - Soi57.net

Acceder a servicio en ip publica mapeada a tu propia maquina con iptables

Solución