Re: Routing directo sin pasar por el gateway en la misma LAN
El día 4 de abril de 2014, 15:58, Santiago Liz <lizsanti@gmail.com> escribió:
> El día 4 de abril de 2014, 5:28, Roberto Leon Lopez
> <i32lelor.debian@gmail.com> escribió:
>> El día 3 de abril de 2014, 22:59, Raúl Alexis Betancor Santana
>> <rabs@dimension-virtual.com> escribió:
>>> On Thu, Apr 03, 2014 at 05:53:59PM -0300, Santiago Liz wrote:
>>>> E3 si envía la respuesta a través de GW porque están en redes lógicas
>>>> distintas con E2 (aunque si en el mismo segmento ethernet)
>>>
>>> Haz la prueba y luego hablamos ... ;), te vas a llevar una sorpresa,
>>> NO contesta a través de GW, porque lo primero que hace el kernel es
>>> comprobar si tiene acceso directo a la IP de E2, le importa un carajo
>>> que la mac que le viene sea la de GW.
>>>
>>>> Podría apostar que no es así. Que no hace falta tener una segunda IP
>>>> para que esto ocurra.
>>>> Veremos si Roberto envía alguna captura.
>>>
>>> Ya digo ... solo hay UNA opción, cuando se tienen varias redes lógicas
>>> en una misma red física, la única forma de crear ese tipo de 'planos
>>> de espaguettis' de problemas, es haciendo que alguno de los equipos
>>> tenga 2 ip's
>>>
>>> Otra opción que se me ocurre ahora ... es que incluso tenga 2 DHCP's
>>> en la misma red ... lo cual ya sería cachondísimo ... XDD ... o
>>> incluso con un solo DHCP, si tienes la red mal configura ... la tienes
>>> mal configurada, punto pelota.
>>>
>>> No hay switches, ni pilas TCP/IP tan jodidamente rotas, como para
>>> mezclar redes lógicas de esa manera.
>>>
>>> Saludos
>>>
>>>
>>> --
>>> To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
>>> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>>> Archive: 20140403205926.GA1995@salma.divi.prv">https://lists.debian.org/20140403205926.GA1995@salma.divi.prv
>>>
>>
>> Comprobado con tcpdump, este es el comportamiento:
>>
>> 1) El host 192.168.0.8 no tiene en su tabla arp la mac del host
>> destino 192.168.2.21.
>> 2) Al hacer un ping de 192.168.0.8 a 192.168.2.21 tcpdump esta
>> escuchando en el gateway y muestra como se le ofrece la mac del host
>> destino.
>> 3) Si hicieramos sucesivos ping veríamos como el nuevo tráfico no pasa
>> por el gateway y no aparece en el tcpdump=> ES DECIR VA DIRECTO!!!
>> 4) Lo mismo comprobado con el tráfico ssh, puede que la primera
>> intentona pase por el gateway, pero las siguiente va directa al host
>> de la otra subred.
>>
>> tcpdump -i br0 host 192.168.0.8 and not 10.8.0.114
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
>> 10:26:41.334256 IP milethos > 192.168.0.8: ICMP echo request, id 3749,
>> seq 0, length 72
>> 10:26:41.334541 IP 192.168.0.8 > milethos: ICMP echo reply, id 3749,
>> seq 0, length 72
>> 10:26:48.282864 ARP, Request who-has 192.168.0.8 tell 192.168.2.21, length 46
>> 10:27:00.071736 ARP, Request who-has 192.168.0.8 tell milethos, length 28
>> 10:27:00.072000 ARP, Reply 192.168.0.8 is-at 00:1e:58:30:a5:e1 (oui
>> Unknown), length 46
>>
>
> Roberto, deshabilita el envío de ICMP Redirect en el gateway y prueba
> nuevamente antes habiendo borrado las entradas de las tablas arp.
> Por defecto, un gateway Debian envía este tipo de paquetes:
> Ej.:
>
> Gateway 172.20.11.1 y 172.20.10.1
> Host 172.20.11.10
> Server 172.20.10.20
>
> hacia el cliente...
> ethertype IPv4 (0x0800), length 142: 172.20.11.1 > 172.20.11.10: ICMP
> redirect 172.20.10.20 to host 172.20.10.20, length 108
>
> hacia el server con ssh...
> ethertype IPv4 (0x0800), length 94: 172.20.10.1 > 172.20.10.20: ICMP
> redirect 172.20.11.10 to host 172.20.11.10, length 60
>
> [172.20.10.20]# arp -n
> Address HWtype HWaddress Flags Mask Iface
> 172.20.11.10 ether xx:xx:xx:xx:0a:d8:36 C
> eth0
> 172.20.10.1 ether xx:xx:xx:xx:05:39:60 C
> eth0
>
>
> Lo curioso es que estos redirect son aceptados y luego se agregan las
> mac en las tablas arp locales sin chistar, pero al querer borrarlas
> con arp -d, da un mensaje de network unreachable.
> Este comportamiento es raro, para agregarla a la tabla arp no
> comprueba que esté dentro de la misma red (le alcanza con que alguien
> conteste el ARP request), pero para borrar si hace la comprobación.
>
> Para deshabilitar el envío de ICMP Redirect en el gateway prueba con
> lo que se ajuste a tus necesidades, ej.:
> net.ipv4.conf.all.send_redirects = 0
> net.ipv4.conf.default.send_redirects = 0
> net.ipv4.conf.lo.send_redirects = 0
> net.ipv4.conf.eth0.send_redirects = 0
>
> echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
> ...
> echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects
>
>
> o lo bloqueas con
> iptables -t mangle -A OUTPUT -p icmp --icmp-type redirect -j DROP
>
>
>>
>> --
>> To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>> Archive: https://lists.debian.org/CALzPpQooYhwaUóT9eJJWEeGda1Qr-M06rNDxvQVoc3n28REw@mail.gmail.com
>>
>
> Saludos,
> Santiago.-
Efectivamente, ese es el comportamiento, aprende la mac y luego va
directo a su objetivo.
Al deshabilitar el redirect del icmp si que pasa todo los ping al
destino de la otra subred.....
La verdad que esta no es una situación deseable para mantener a menos
que tengamos una separación física o modifiquemos la mascara de la
subred de clase C para que incluya mas posibles equipos.
Gracias a todos!!!!
Reply to: