Re: iptables SNAT,DNAT y caso extraño que no funciona
El Fri, 24 Apr 2015 18:42:05 +0200, José Miguel (sio2) escribió: El Thu, 23 de Apr de 2015, a las 02:17:07PM +, Camaleón dijo: 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. (...) Pues bien, este es el flujo de un paquete por una máquina linux: http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet- flow.svg Resulta que la cadena PREROUTING de la tabla nat en la que se hace el DNAT se encuentra antes de la decisión de conmutar el paquete. Así que en el momento de tomar la decisión el paquete tiene ya la IP y la MAC de M2. Pero M2 se encuentra en el mismo puerto por el que llega el datagrama y ¿qué hace un puente cuando el destino del datagrama se encuentra en el mismo puerto por el que lo recibe? Desecharlo. Y el paquete se desecha y no hay comunicación. En el caso B, como el destino estaba en el otro puerto del puente, sí funcionaba el ping. Esta conclusión, además, concuerda con lo que observaba cuando monitorizaba eth1: el paquete llegaba de M1, pero nunca salía hacia M2. Para hacer que esto funcione hay que montar un brouter. Lo he hecho y, efectivamente, funciona. Ya veo que te has dado una vuelta por la documentación de ebtables: http://ebtables.netfilter.org/br_fw_ia/br_fw_ia.html Resulta interesante saber que se pueden usar los dos juntos (iptables/ ebtables) cada uno gestionando su parte de la red. Saludos, -- Camaleón -- 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/pan.2015.04.25.14.27...@gmail.com
Re: iptables SNAT,DNAT y caso extraño que no funciona
El Thu, 23 de Apr de 2015, a las 02:17:07PM +, Camaleón dijo: 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. Sé que existen otras posibilidades para aislar una máquina de otra. Yo sólo estaba haciendo pruebas con este escenario y, cómo el caso C no sale, quería darle una explicación. Pura y sana curiosidad. Después de darle muchas vueltas y mirar cómo funciona también ebtables, creo que ya sé por qué falla el caso C (o al menos la explicación me parece plausible). En M1 hago un ping al cortafuegos: $ ping -c1 192.168.255.1 con el propósito de hacer en él un DNAT hacia M2. Pues bien, este es el flujo de un paquete por una máquina linux: http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg Resulta que la cadena PREROUTING de la tabla nat en la que se hace el DNAT se encuentra antes de la decisión de conmutar el paquete. Así que en el momento de tomar la decisión el paquete tiene ya la IP y la MAC de M2. Pero M2 se encuentra en el mismo puerto por el que llega el datagrama y ¿qué hace un puente cuando el destino del datagrama se encuentra en el mismo puerto por el que lo recibe? Desecharlo. Y el paquete se desecha y no hay comunicación. En el caso B, como el destino estaba en el otro puerto del puente, sí funcionaba el ping. Esta conclusión, además, concuerda con lo que observaba cuando monitorizaba eth1: el paquete llegaba de M1, pero nunca salía hacia M2. Para hacer que esto funcione hay que montar un brouter. Lo he hecho y, efectivamente, funciona. Saludos. -- Tu dulce habla, ¿en cúya oreja suena? --- Garcilaso de la 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/20150424164205.ga15...@cubo.casa
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 +, 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/00.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/00.0.0.0/0ctstate 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 -- To UNSUBSCRIBE, email to
Re: iptables SNAT,DNAT y caso extraño que no funciona
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, para asegurarte la salida por el cortafuegos con un esquema de enrutado sería suficiente (route/ip). (...) Pues bien si en M1 hago: $ ping -c1 192.168.255.1 Es decir, ejecutas un ping desde la máquina 1 al cortafuegos. 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? ¿Tienes activado en el cortafuegos el reenvío de IP? 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. :/ (...) 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. 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. Puedes añadir más verbosidad a tcpdump (-vvv) a ver si te da alguna pista. Saludos, -- Camaleón -- 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/pan.2015.04.22.16.44...@gmail.com
Re: iptables SNAT,DNAT y caso extraño que no funciona
El Wed, 22 de Apr de 2015, a las 04:44:32PM +, 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/00.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/00.0.0.0/0ctstate 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.
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 --- -- 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/20150421163130.ga5...@cubo.casa
Re: Un caso extraño para auto-iniciar paquete
El 19/08/05, Jesús Eberto García[EMAIL PROTECTED] escribió: Tengo instalado el servidor FTP vsftpd, lo hice desde una actualización 2.0.3 que bajé. Realicé los pasos que me guió un manual que encontré en escomposlinux.org. La guía explicaba la creación del usuario y grupo, luego, la compilación e instalación, la instalación del guión de inicio, y finalmente la configuración del archivo vsftpd.conf. Al terminar de instalarlo, funcionaba bien, pero tengo que cargarlo mediante: /usr/sbin/vsftp. Bueno, raro para mí porque este archivo es un ejecutable, o sea no puedo recibe parámetros stop/start/restart, sino que solo corre el proceso. Lo digo, porque hacer el enlace simbólico pero es un archivo de otro tipo. ¿Me pueden ayudar? Lo que te hace falta es un guion de arranque, de los que se localizan en /etc/init.d . Puedes hacerlo a mano (si conoces de programación en bash) usando como ejemplo alguno de los que esta ahí, o bajar uno ya hecho (deben andar rondado varios por internet). Mi pregunta es ¿Por que no usaste el paquete que existe en debian? ¿estaba muy desactualizado? Saludos, Jesús Eberto García
Un caso extraño para auto-iniciar paquete
Tengo instalado el servidor FTP vsftpd, lo hice desde una actualización 2.0.3 que bajé. Realicé los pasos que me guió un manual que encontré en escomposlinux.org. La guía explicaba la creación del usuario y grupo, luego, la compilación e instalación, la instalación del guión de inicio, y finalmente la configuración del archivo vsftpd.conf. Al terminar de instalarlo, funcionaba bien, pero tengo que cargarlo mediante: /usr/sbin/vsftp. Bueno, raro para mí porque este archivo es un ejecutable, o sea no puedo recibe parámetros stop/start/restart, sino que solo corre el proceso. Lo digo, porque hacer el enlace simbólico pero es un archivo de otro tipo. ¿Me pueden ayudar? Saludos, Jesús Eberto García
Re: Caso extraño
On Tue, Jan 28, 2003 at 02:19:08AM +0100, Aitor wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hola buenas noches: Antecedentes Ordenador Ciryx M II 266M 128 Mb de RAM 2 trajetas de Red (RealTek 8139) Llevo un rato, vamos desde esta mañana con un problema en la instalación de Woody/Potato/RedHat lo que sea, no consigo que coja la ip dinámica, puedo asignarle una (cosa que ya hago para la red interna en eth1) estática pero no puedo obtenerla por DHCP. Me pasa desde el arranque, ni instalando etherconf ya en la post-instalación. Os cuento esto para saber si a alguien le ha pasado algo parecido por que ya no se donde recurrir. Mi archivo de interfaces. Instalo en todos los casos el dhcp-client y nada # /etc/network/interfaces -- configuration file for ifup(8), ifdown(8) # The loopback interface auto lo iface lo inet loopback auto eth0 eth1 iface eth0 inet dhcp iface eth1 inet static address 172.26.0.5 netmask 255.255.255.240 network 172.26.0.0 broadcast 172.26.0.15 Bueno si alguien me diera alguna pista - -- _ Hola, no tengo mucha idea de DHCP, pero en casa de un colega una vez lo hicimos de forma automática con pump (es de red hat, pero también viene en woody) y él sólo se las apañó para configurarlo. Un saludo.
Re: Caso extraño
No sé si te lo han dicho ya porque voy un poco despistado, pero ¿hay algún firewall que pueda estar estorbando? ¿Tal vez en el propio cliente de DHCP? Pepe. -- José Marcos Chalmés García - Public key ID: 0x6FDE933B www.polinux.upv.es - www.debian.org - www.gnu.org - www.bsd.org - ... I use free software | Utilitze programari lliure | Uso software libre -
