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 --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150422194251.ga10...@cubo.casa