Hoy hemos visto como Xavi enlazaba con scuba (hemos comprobado su MAC varias veces y así era), pero recibía respuesta a sus peticiones DHCP desde club radio (IP en la subred 10.1.1.0 y puerta de enlace correspondiente). Raro.
Entonces me he acordado que anoche recibí 2 respuestas DHCP cuando enlazaba con club radio... la verdad es que lo vi y me llamó la atención, pero como estaba impaciente por ver como iba la conexión con blackshell, enseguida aparté el hecho y lo olvidé.
Una de las respuestas era de club radio, además recuerdo que me dió la IP 10.1.1.72. La otra ahora sé que era de scuba, porque en el dhcpd.leases de scuba aparece mi petición.
Esto es teóricamente imposible, estamos en subredes distintas y no hay bridges, por los que las peticiones DHCP (que van a nivel ARP) no deberían pasar así de un sitio a otro.
Sabemos lo que ha pasado, y sabemos lo que no puede pasar. Pero no sabemos como ha pasado lo que no puede pasar :(.
Rubén es un gurú de las redes, por si alguien no lo sabía:
<Rubén> linux:/etc# iptables -L -t nat | wc -l
12
linux:/etc# iptables -L -t mangle | wc -l
20
linux:/etc# iptables -L | wc -l
34
linux:/etc# ip route list table 44 | wc -l
9
linux:/etc# ip route list table 30 | wc -l
2
linux:/etc# ip route list | wc -l
93
linux:/etc#
<Rubén> me vuelve loco :)
<Rubén> es una perfecta azaña para un admin de redes...
¡Y tanto! IMPRESIONANTE lo que hay montado en club radio. El problema puede estar por ahí, pero queremos mucho a Rubén y no nos gustaría que se hiciera daño, por no decir que no sabemos que demonios ha pasado :'(.
Vamos a intentar solucionar el tema con unas sencillas reglas en el iptables de scuba, así no hay que lidiar con club radio y no le damos más problemas a Rubén.

![[xml]](/images/xml.gif)
