[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: iptables SNAT,DNAT y caso extraño que no funciona



El Wed, 22 Apr 2015 21:42:51 +0200, José Miguel (sio2) escribió:

> 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).

Lo que te quiero decir es que el uso de iptables en el escenario que 
describes entiendo que es opcional o dicho de otro modo ¿por qué has 
usado iptables?
 
>>, 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.

(...)

A eso iba... ¿te has planteado una configuración sin iptables? Si 
configuras los enrutados únicamente con "ip" podrías descartar que el 
problema te venga de los filtros que tienes en iptables.

Digo esto porque entiendo que existen otras opciones (vlan, ip) para 
conseguir un entorno aislado y que M1 y M2 sólo "hablen" con/a través del 
cortafuegos. Al añadir el filtrado de paquetes con iptables añades 
igualmente una capa adicional de posibles problemas y dado que estás 
probando la comunicación básica (ping) entre los 3 equipos no necesitas 
(al menos en este momento de la configuración) reglas sofisticadas para 
la manipulación de paquetes.

>> En el caso C) tenemos dos interfaces de red (eth0 + eth1) configuradas
>> como br0 ¿no?
> 
> Sí... y no.

(...)

> 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, 

¿¡Quemu!? Haber empezado por ahí. Si hay virtualziación de por medio la 
cosa se complica aún más :-)

> 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:

(...)

Casi que mejor con datos de los 3 equipos: "/etc/network/interfaces", "ip 
ro"...
 
>> 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.

¿Has revisado el registro de iptables? Ahí podrás ver si llega el ping y 
cómo lo trata.
 
> 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é?

Tráfico le llega.

> ¿Qué más da que esté monitorizando tráfico que no lo esté haciendo?

Está haciendo algo más que monitorizar, había un "DROP" por ahí.

> 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.

(...)

¿Cuál es el mensaje que recibe M1 cuando haces un ping al cortafuegos 
(caso C)? Por cierto, juega con los parámetros "-RBI" del comando por si 
vieras alguna cosa "rara".

Saludos,

-- 
Camaleón


Reply to: