Re: iptables SNAT,DNAT y caso extraño que no funciona
El Wed, 22 de Apr de 2015, a las 04:44:32PM +0000, Camaleón dijo:
> El Tue, 21 Apr 2015 18:31:30 +0200, José Miguel (sio2) escribió:
>
> > 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.
>
> (...)
>
> Es un poco lioso, pero me da la nariz que el problema está con alguna
> regla de iptables que además (y para el ejemplo que pones) me parece que
> no serían necesarias ya que si todas las máquinas están en la misma red
> física
Las tres máquinas están en la misma red. Ahora bien, la máquina M2 sólo
admite comunicaciones con el cortafuegos. Cualquier tráfico procedente
de otra máquina, lo veta. De ahí que necesite las reglas de iptables, ya
que la única forma que tiene M1 de acceder a los servicios de M2 es a
través del cortafuegos.
He usado el ping como podría haber usado cualquier servicio en M2
(incluso uno improvicado con netcat).
>, para asegurarte la salida por el cortafuegos con un esquema de
> enrutado sería suficiente (route/ip).
> (...)
No hay enrutamiento en este supuesto: las tres máquinas están en la
misma red.
> > Pues bien si en M1 hago:
> >
> > $ ping -c1 192.168.255.1
>
> Es decir, ejecutas un ping desde la máquina 1 al cortafuegos.
Sí, ya he dicho que M1 no puede acceder a M2 directamente (incluso
aunque estén en el mismo segmento de red), porque M2 sólo se habla 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
>> Se obtiene respuesta perfectamente en el caso A) y B), pero no en el C).
> En el caso C) tenemos dos interfaces de red (eth0 + eth1) configuradas
> como br0 ¿no?
Sí... y no.
En el caso A) el cortafuegos sólo tiene una interfaz de red (en la red
que tratamos). Pongamos que es eth1. Funciona.
En el caso B) hay interfaces de red (eth1 y eth2) en la red que son
puertos de un bridge br0. La máquina M1 cae en el segmento de red con el
que conecta físicamente eth1 y la máquina M2, en el segmento con el que
conecta eth2. Funciona.
El caso C) se configura exactamente igual que el caso B), pero en este
caso, ambas máquinas (M1 y M2) caen en el mismo segmento de red: al que
conecta el cortafuegos con eth1. No funciona.
Dicho de otro modo B) y C) son exactamente la misma configuración en
cortafuegos y máquinas, lo único que se hace es cambiar de segmento de
red una de las máquinas. Como trabajo con qemu, esto consiste en apagar
la máquina M2 y arrancarla con su eth0 en la misma vlan que la interfaz
eth1 del cortafuegos y la interfaz eth0 de M1. De esta forma, ambas
máquinas acaban cayendo en el mismo segmento de red y ambas máquinas se
comunican con el cortafuegos a través del mismo puerto (eth1).
Esquemáticamente:
Caso B: br0(eth1,eth2)
-----+ M1
| eth1 |
+-----------+
| eth2
+-----------+
| |
-----+ M2
Caso C: br0(eth1,eth2)
-----+ M1 M2
| eth1 | |
+-----------+------+
| eth2
+------ A edste segmento no hay ninguna máquina conectada.
|
-----+
> ¿Tienes activado en el cortafuegos el reenvío de IP?
Eso da igual: estoy conmutando, no encaminando paquetes. De todos modos,
está habilitado.
> Hum... que el ping al cortafuegos no obtenga respuesta en la máquina 1
> pero que éste (cortafuegos) sí escuche el tráfico parece indicar que los
> paquetes llegan pero se rechazan, quizá por alguna regla de iptables.
No hay más reglas que las dos que indiqué en el anterior mensaje:
# iptables -nL -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT icmp -- 0.0.0.0/0 0.0.0.0/0 to:192.168.255.3
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT icmp -- 0.0.0.0/0 0.0.0.0/0 ctstate DNAT to:192.168.255.1
Más las dos que hay en M2 para asegurarme que sólo habla con el
cortafuegos. He dejado más arriba escritas cuáles son.
Por supuesto, las reglas del caso B) y las del C) son exactamente las
mismas. Pero, lo que más me escama, es que cuando pongo a escuchar
tcpdump en la interfaz br0, el caso C), sí funciona. ¿Y eso por qué?
¿Qué más da que esté monitorizando tráfico que no lo esté haciendo?
No puedo estar haciendo nada mal. De hecho, si estuviera haciendo algo
mal no deberían funcionar ni B) ni C). Ni mucho menos funcionar C)
cuando tcpdump minitoriza br0, pero no cuando no lo hace.
> Puedes añadir más verbosidad a tcpdump (-vvv) a ver si te da alguna pista.
La única información que añade es el ToS de paquete y algún dato más sobre el
único paquete que detecta. No parece útil en absoluto.
> Saludos,
Un saludo.
--
Lee si puedes y enmienda si sabes.
--- Lope de Vega ---
Reply to: