iptables SNAT,DNAT y caso extraño que no funciona
Un saludo a la lista:
He estado jugueteando con iptables y me he encontrado con un caso en el
que no funciona como yo me esperaba. De hecho, me parece que no debería
funcionar así, pero me gustaría que alguien opinara al respecto.
El supuesto es el siguiente:
Máquina 1 192.168.255.2
|
Cortafuegos -----+
192.168.255.1 |
Máquina 2 192.168.255.3
O sea las tres máquinas están en la misma red. La prueba consiste en
enviar un ping de M1 a M2, pero pasando por el cortafuegos, de modo que
M1 cree que le responde el cortafuegos y M2 que quien le hace ping es
también el cortafuegos.
De este supuesto he hecho tres casos distintos:
Caso A) El cortafuegos escucha en la red a través de eth2.
Caso B) M1 y M2 están en dos segmentos distintos de la red, que se
encuentran unidos gracias al cortafuegos. En este caso, eth1 conecta
con el segmento de M1 y eth2 conecta con el segmento de M2. eth1 y
eth2 están dentro de una interfaz puente br0.
Caso C) Como B) se monta una interfaz puente br0, pero M1 y M2 caen en
el mismo segmento de RED, así que los paquetes siempre salen y entran
por eth1.
Para lograr que M1 y M2 crean que se está comunicando con el cortafuegos
y no entre ellas, he usado SNAT y DNAT. Para el caso A):
# iptables -t nat -A PREROUTING -i eth2 -p icmp \
-j DNAT --to-destination 192.168.255.3
# iptables -t nat -A POSTROUTING -o eth2 -p icmp -m conntrack --ctstate DNAT \
-j SNAT --to-source 192.168.255.1
Y para el B) y C) lo mismo pero sustituyendo eth2 por br0. Además para
estar seguro de que M2 sólo es capaz de comunicarse con el cortafuegos:
# iptables -A INPUT -p icmp ! -s 192.168.255.1 -j DROP
# iptables -A OUTPUT -p icmp ! -d 192.168.255.1 -j DROP
Pues bien si en M1 hago:
$ ping -c1 192.168.255.1
Se obtiene respuesta perfectamente en el caso A) y B), pero no en el C).
Pero lo más curioso del asunto, es que si en el caso C), me pongo a
escuchar con tcpdump la interfaz br0 del cortafuegos a ver si saco algo
en claro, śí funciona. :/
Las salidas de tcpdump en el cortafuegos son:
Caso A)
# tcpdump -ni eth1 icmp
18:02:24.110695 IP 192.168.255.2 > 192.168.255.1: ICMP echo request, etc.
18:02:24.110779 IP 192.168.255.1 > 192.168.255.3: ICMP echo request, etc.
18:02:24.111491 IP 192.168.255.3 > 192.168.255.1: ICMP echo reply, etc.
18:02:24.111510 IP 192.168.255.1 > 192.168.255.2: ICMP echo reply, etc.
Caso B)
# tcpdump -ni eth1 icmp
17:36:57.270693 IP 192.168.255.2 > 192.168.255.1: ICMP echo request, etc.
17:36:57.271098 IP 192.168.255.1 > 192.168.255.2: ICMP echo reply, etc.
# tcpdump -ni eth2 icmp
17:36:40.651471 IP 192.168.255.1 > 192.168.255.3: ICMP echo request, etc.
17:36:40.651928 IP 192.168.255.3 > 192.168.255.1: ICMP echo reply, etc.
Caso C)
# tcpdump -ni eth1 icmp
18:27:36.902663 IP 192.168.255.2 > 192.168.255.1: ICMP echo request, etc.
#tcpdump -ni br0 icmp
18:28:23.735113 IP 192.168.255.2 > 192.168.255.3: ICMP echo request, etc.
18:28:23.735171 IP 192.168.255.1 > 192.168.255.3: ICMP echo request, etc.
18:28:23.735536 IP 192.168.255.3 > 192.168.255.2: ICMP echo reply, etc.
18:28:23.735547 IP 192.168.255.1 > 192.168.255.2: ICMP echo reply, etc.
Esta última monitorizacióm no sé cómo interpretarla. La lógica sería la
del caso A.
--
Harto sabe, si me sabe bien.
--- Francisco de Quevedo ---
Reply to: