Re: DHCP: máquinas que consumen dos ips
El Thu, 16 Oct 2014 18:27:37 +0200, José Miguel (sio2) escribió:
> El Tue, 14 de Oct de 2014, a las 02:01:16PM +0000, Camaleón dijo:
>
>> Pero ahí no dice que el uso único de MAC como identificador vulnere
>> ninguna especificación ni normativa, sólo avisa de que ese valor no es
>> fiable y puede cambiar por lo que recomiendan (MAY) usar otro sistema.
>> De hecho dice expresamente (MUST) que si el cliente no envía UID alguno
>> el servidor usará la MAC. Además, nada te impide usar la dirección MAC
>> como identificador (UID) ;-)
>
> Claro, si el cliente no envía UID se usa la MAC, pero al cliente no lo
> controlas, así que no puedes forzarlo que no te envíe un UID y, si te lo
> envía, debes (MUST) usarlo. Si el servidor no atiende el UID y sólo se
> fija en la MAC, viola el RFC.
Sí, eso está claro, pero estamos hablando de tu caso donde además
necesitas una configuración muy concreta y donde sí controlas los
clientes y puedes elegir enviar el valor que prefieras (UID o MAC). Y
además, puedes configurar los clientes para que envíen como UID la
dirección MAC.
>> Me refería a que en tu configuración, que no tiene configurada ninguna
>> reserva específica de direcciones IP para los clientes (ya has dicho
>> que no quieres usar la opción de "fixed-address") cuando un equipo pide
>> renovar la IP no solicita al servidor ninguna en concreto, sólo que la
>> renueve.
>
> La opción "fixed-address" está fijada en el servidor: el cliente no
> tiene nada que ver con ella (salvo que tiene la MAC que hay en la
> declaración "host"). Así que haya "fixed-address" o no la haya el
> cliente siempre se comporta de la misma manera: pidiendo la última ip
> que se le concedió. El que actúa de diferente forma es el servidor, que
> siempre le da la misma en cualquier caso (incluso si no coinciden los
> UID).
¿Dices que el cliente mantiene una base de datos local con la última
dirección que se le ha asignado y solicita esa dirección cuando tiene que
renovar la IP? Pensaba que eso no dependía del cliente sino del servidor.
> Para comprobar el "one-lease-per-client true;", yo mismo me metí en la
> caché del cliente y sustituí un 66, por un 67; para hacerle creer al
> cliente que le habían concedido anteriormente la 67. Cuando volví a
> pedir ip, el servidor le dio la .67 y desechó la .66: señal de que el
> cliente le había pedido la .67.
Bueno, ahí estás manipulando la configuración y además sin reiniciar los
demonios, no es una prueba fiable. De todas formas, si aumentas el nivel
de depuración del registro esa información debería aparecer en el syslog,
bien del cliente o del servidor.
>> Simplemente que revises cuándo expiran los leases de los clientes y
>> mires a ver si no te convendría hacerlos perpetuos (que no renueven
>> bajo ninguna circunstancia), así el servidor sólo les asignará una
>> dirección.
>
> Eso no resuelve el problema: mi problema no es que expiren las ips, sino
> que una MAC puede recibir varias concesiones si se enviaron distintos
> UID. Es más, esto agravaría el problema: si las concesiones son cortas,
> puede que tenga suerte y, cuando arranque linux, ya haya expirado la
> concesión que se hizo cuando arranqué windows.
¿Y no crees que si los clientes no solicitaran la renovación el servidor
mantendría una única IP (la primera que les ha dado) para cada uno de
ellos?
> Sí soluciona el problema "fixed-address", porque se puede asociar la ip
> a una MAC con independencia del UID.
Pero ya has dicho que esta opción no la querías usar ¿no? :-?
>> Hombre, el comentario que he puesto antes es de la lista de usuarios de
>> ISC (DHCP), no se alguien que pasaba por ahí ;-) y como ves, la
>> definición del manual da lugar a muchas interpretaciones.
>
> Yo, en realidad, lo que veo es gente que interpreta más o menos lo mismo
> que interpreté yo, pero a la que luego no le salen las cosas. Y, además,
> no hay nadie que argumente por qué no salen.
>
> No sé, o hay un error en la programación o un error en la documentación.
Yo apuesto más por el fallo humano, que nos gustaría que se tratara de un
parámetro que haga lo que queremos pero que sirve para otra cosa O:-)
>> > Creo que la interpretación más lógica es la siguiente:
>> >
>> > 1. En el servidor hay una reserva vigente asociada a una MAC.
>> > 2. Le llega la petición de un cliente con una MAC igual, pero
>> > distinto
>> > UID (si el UID fuera el mismo, no hay ningún problema).
>> > 3. El servidor desecha la reserva anterior asociada a esa MAC y le da
>> > una ip al cliente. No se especifica que sea la misma o no. Incluso
>> > podría ser distinta, si el propio cliente le sugiere que le dé
>> > otra diferente. El caso es que en el servidor siempre hay una sóla
>> > reserva asociada a cada MAC (de ahí el nombre de "deny
>> > duplicates").
>>
>> Pero no serviría para el propósito que persigue el "deny duplicates"
>> que es evitar que un cliente solicite direcciones IP
>> indiscriminadamente y las agote.
>
> ¿Por qué no? Si al concedérsele una IP, se desechan las otras
> concesiones a esa misma MAC, resulta que una MAC sólo estaría reservando
> en cada momento una sola IP. Por tanto, un cliente (entendiendo
> cliente=MAC) no agotaría indiscriminadamente ips.
Porque entonces el cliente podría estar pidiendo direcciones IP distintas
continuamente, primero una (192.168.0.1), luego otra (192.168.0.2) y
reserva la anterior, luego pide otra (192.168.0.n) y aunque sigue con la
primera reservada no la usa, luego pide otra y se le da la reservada
(192.168.0.1) y así...
>> Los resultados que has obtenido son los mismos que los que ha obtenido
>> el resto de personas que lo han intentado pensando que servía para eso.
>> Se ve que no.
>
> Es cierto, no tengo mucha fe. De todos modos, algunos de los casos que
> he consultado en internet tenían un error manifiesto de configuración:
> la MAC no la habían declarado en una declaración HOST, cosa que el
> manual dice que es necesario.
>
> Otros en cambio, sí lo habían hecho...
>
> Ya hice la prueba de meter a las máquinas que arrancan por red
> (PXEClient) en una clase aparte y hacerles:
>
> a) Cortita la concesión de la ip.
> b) Meterlos en el pool "general", de manera que reciban una ip del rango
> que queda para las máquinas que no son de ninguna clase en especial.
>
> Con eso y con configurar el dhclient para que envíe el mismo UID que
> linux, basta. No me entusiasma la solución, pero no hay otra (excepto la
> de usar fixed-address, claro).
Ese es otro de los baipases que he leído, y oye, si te sirve... pues a
correr :-)
Saludos,
--
Camaleón
Reply to: