Re: iptables SNAT,DNAT y caso extraño que no funciona
El Thu, 23 de Apr de 2015, a las 02:17:07PM +0000, 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 ---
Reply to: