Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID:
El 2009-09-15 a las 23:30 +0200, Camaleón escribió:
Yo lo veo igual que tener un servidor dhcp o dns en marcha: si no lo necesito, no lo configuro... ¿para qué? ¿para que el vecino, a través del wifi, pueda obtener una ip en mi rango y acceder fácilmente a los recursos de la red? Pues no. Si en algún momento tengo que conectar un equipo a la red que necesita una IP asignada automáticamente, entonces me plantearé la configuración del servidor dhcp, pero no antes.
Vamos a intentar entender esto del zeroconf.
Bueno, lo dejo para la tarde, me tengo que ir.
[...]
Tenemos una red, por ejemplo con IPs en el rango 192.168.1.0, todo con IPs fijas. Todos se hablan entre si, tan contentos, sin problemas. No necesitamos zeroconf. No tenemos dhcp. Pero el sistema ha metido las rutas de link-local.
De repente llega alguien y conecta un portatil sin darle una IP, por error, desconocimiento, o malicia. ¿Que ocurre? Pues exactamente no lo se, pero una de dos: o el nuevo escucha para saber que IPs hay libres, o el nuevo emite un broadcast especial, al que le contestan los demás diciendole que IPs están ocupadas. El nuevo probablemente coja una de las libres, y emita un broadcast para anunciarlo. Si hay colisión, pues volverá a negociar otra IP.
Los demás no tienen que hacer nada, siguen con sus IPs fijas; si reciben una petición cualquiera, procedente de esa IP en link-local, pues le contestarán a esa IP, puesto que tienen la ruta definida.
Hay dos o tres mecanismos que entran en juego acá: uno es la ruta de linnklocal:
link-local * 255.255.0.0 U 0 0 0 eth0
y que no actúa mientras no haya que enviar un paquete o contestar a otro.
Pero hay otro mecanismo que consiste en escuchar los paquetes broadcast del mecanismo de zeroconf, que pueden ser para negociar una IP libre entre todos, o que pueden ser también para anunciar a los demás donde están los servicios de impresión, por ejemplo.
Y el único mecanismo sobre el que estais actuando es la ruta.
¿Que sucede si quitais la ruta? Queda esto:
Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default router 0.0.0.0 UG 0 0 0 eth0
Si alguien enchufa el portatil en la red como antes, pues va a conectar igual de bien... (o casi), tanto si le contestan como si no. El mecanismo de negociación sigue intacto (y si no le contestan, es que todas las IPs están libres).
Hay una diferencia: que cuando el portatil mande un paquete cualquiera a una de nuestras máquinas sin ruta link-local, la máquina le va a contestar, porque no está prohibido; pero como la IP a la que tiene que contestar no está en ninguna de las entradas "Destination", pues va a "default", sea lo que sea que esté ahí: router, gateway, cortafuegos... Nuestro portatil "intruso" hace una petición al servidor web, y el apache le contesta, pero envía el paquete al gateway, no al portatil. Ya la tenemos liada.
Luego el objetivo de evitar que alguien se conecte y use link-local sin nuestro consentimiento no se ha conseguido.
¿Capishi?
No, no, no y no. Vamos a ver. La primera parte de tu disertación es correcta al 35%. Preguntas: - ¿Que es un broadcast especial? Yo solo conozco uno y es el que incluye el direccionamiento de una red. ¿O te refieres a un multicast? - Si los switches están configurados como dios manda, el señor que conecta el portatil no verá ninguna IP, sencillamente porque el switch tendrá una tabla de ARP en cada una de sus bocas correspondientes y las IPs asociadas a esas ARPs, que será por donde encaminará las peticiones de los distintos dispositivos que configuran esa red. Por ende, tú no verás ninguna IP a menos que conozcas el direccionamiento, en cuyo caso podrás usar un scanner. Y mira por donde los switches donde yo tengo conectados esos servidores no admiten inserción dinámica de ARPs, están ajustadas estáticamente. Otro caso distinto es el de un hub, este útlimo escucha por todas sus bocas. La segunda no. Pero es que ya no sé como explicártelo, la forma más sencilla es que te simules un entorno de tres máquina: una de gateway, un servidor y una estación, y verás que un server sin zeroconf configurado no hace absolutamente NADA con una paquete emitido o recibido al direccionamiento zeroconf. Y el gateway (que es un firewall con IPS en modo transparente y con un TAP - http://en.wikipedia.org/wiki/Network_tap - que es el que ve las peticiones hacia/desde la red zeroconf. Y para colofón: en mi infraestructura, SI se ha conseguido que si tu conectas un pc y habilitas el zeroconf, no consigues nada. Cosa que no ocurría con el zeroconf activo. -- CL Martinez carlopmart {at} gmail {d0t} com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org