Re: DHCP: máquinas que consumen dos ips
El Mon, 13 Oct 2014 21:52:21 +0200, José Miguel (sio2) escribió:
> El Mon, 13 de Oct de 2014, a las 05:39:34PM +0000, Camaleón dijo:
>
>> ¿Qué es lo que viola el protocolo? ¿Que se identifique al equipo por la
>> MAC en lugar del identificador? ¿Dónde has leído eso? :-?
>
> Pues no recuerdo bien (incluso quizás me lo he inventado o lo me
> malinterpretado), así que me he ido al RFC 2131 y he leído en la sección
> 4.2:
>
>
> DHCP server needs to use some unique identifier to associate a client
> with its lease. The client MAY choose to explicitly provide the
> identifier through the 'client identifier' option. If the client
> supplies a 'client identifier', the client MUST use the same 'client
> identifier' in all subsequent messages, and the server MUST use that
> identifier to identify the client. If the client does not provide a
> 'client identifier' option, the server MUST use the contents of the
> 'chaddr' field to identify the client. It is crucial for a DHCP client
> to use an identifier unique within the subnet to which the client is
> attached in the 'client identifier' option. Use of 'chaddr' as the
> client's unique identifier may cause unexpected results, as that
> identifier may be associated with a hardware interface that could be
> moved to a new client. Some sites may choose to use a manufacturer's
> serial number as the 'client identifier', to avoid unexpected changes in
> a clients network address due to transfer of hardware interfaces among
> computers. Sites may also choose to use a DNS name as the 'client
> identifier', causing address leases to be associated with the DNS name
> rather than a specific hardware box.
>
> Ahí dice que el servidor debe usar el UID si el cliente se lo ha
> enviado; y sólo usar la MAC, si no le envió ninguno. Así que pasar del
> UID y fijarse sólo en la MAC, viola este RFC. Yo lo entiendo así y
> supongo que por eso el servidor del ISC no lo ha implementado.
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) ;-)
>> El cliente no debe pedir ninguna IP en especial,
>
> Sí, sí que puede pedir una: es la opción 50. El paquete DHCPREQUEST
> incluye esa opción. Mira el contenido de este tipo de paquete:
(...)
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.
>> eso es otra cosa que tendrías que revisar, el motivo de por qué la
>> solicita una vez que ya la tiene. Si no quieres que renueve su IP (esto
>> es algo que se suele hacer con clientes móviles que pasan de un
>> servidor DHCP a otro) configúralo para que no haga.
>
> No entiendo qué quieres decir.
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.
>> Lo interesante no es lo que dicen del "one-leases-per-client" sino lo
>> que opina de la función del "deny duplicates", que aunque esté activado
>> el cliente obtendrá una segunda dirección y en el caso de que lo
>> necesite, podrá reutilizar la anterior. Eso no concuerda con la idea
>> que tienes del funcionamiento del "deny duplicates", por eso decía que
>> quizá lo estemos interpretando mal.
>
> El único elemento de juicio que tenemos para opinar es lo que dice la
> página del manual, que copio otra vez:
(...)
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 entendí en un principio que esto me servía, porque era una forma de
> violar el punto 4.2 del RFC: aunque los UID sean diferentes, si la MAC
> es igual (siempre que haya una declaración "host" con ella según el
> primer párrafo), el servidor desecha todas las otras reservas que le
> hizo a esa MAC. Entendí que me servía, porque esto me aseguraría que
> siempre habría una sola ip reservada para cada MAC.
Y no eres el único que lo entiende así, como ya has visto. Pero parece
que no hace lo que la gente espera.
> Tú argumentaste que quizás lo único que hace es evitar que me dé otra
> ip. Releyendo ahora me parece que no tienes razón o que no se puede
> entender lo que pensaste en un momento.
Mi argumento iba en relación a la prueba que habías hecho de pasarle
primero un UID, pedir una IP y después volver a pedirle una IP sin
pasarle el identificador.
> 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.
> No sé. Creo que las cosas tendrían que haber funcionado, pero no lo han
> hecho. A menos que haya un detalle en mi configuración que lo malogra
> todo. Quizás debería montarme un DHCP limpito con una configuración muy,
> muy sencilla y probar a ver si funciona el "deny duplicates".
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.
Saludos,
--
Camaleón
Reply to: