Re: DHCP: máquinas que consumen dos ips
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.
> 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:
http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_request
Incluye la opción 50.
Y una explicación más prolija de para qué sirve la opción 50, aquí:
http://www.cisco.com/c/en/us/td/docs/net_mgmt/network_registrar/6-1-1/user/guide/users/UserApB.html#wp1069731
"Used in a client request (DHCPDISCOVER) to allow the client to request
that a particular IP address be assigned."
En el DHCPDISCOVER (si miras la página de la wiki) verás que también se
puede incluir la opción.
Esa es la razón por la que los ordenadores (si son menos que ips
disponibles) suelen obtener siempre la misma ip: piden la que obtuvieron
por última vez, y, si tienen suerte, estará libre y el servidor se la
volverá a conceder. Si no lo está, el servidor les asigna otra.
> 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.
> 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:
$ man 5 dhcpd.conf
[...]
The duplicates keyword
allow duplicates;
deny duplicates;
Host declarations can match client messages based on the DHCP
Client Identifier option or based on the client's network
hardware type and MAC address. If the MAC address is used, the
host declaration will match any client with that MAC address -
even clients with different client identifiers. This doesn't
normally happen, but is possible when one computer has more than
one operating system installed on it - for example, Microsoft
Windows and NetBSD or Linux.
The duplicates flag tells the DHCP server that if a request is
received from a client that matches the MAC address of a host
declaration, any other leases matching that MAC address should be
discarded by the server, even if the UID is not the same. This
is a violation of the DHCP protocol, but can prevent clients
whose client identifiers change regularly from holding many
leases at the same time. By default, duplicates are allowed.
[...]
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.
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.
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").
La interpretación que hacen esa persona en esa lista dice que quizás el
servidor no le da la misma, sino que le da la misma en caso de que sea
necesario. Muy bien, eso no desmiente mi interpretación en absoluto. De
hecho lo primero que probé fue a meter al cliente en un rango de una
sola ip: hay obviamente es forzoso reutilizar la ip. Después pensé que
quizás la liberación se producía después de que el servidor hubiera
concedido la ip. Si sólo hay una ip disponible, no hay una segunda ip
que ofrecer y el cliente se queda sin ip y no se produce la liberación.
Así que hice un rango de dos ips y volví a probar. pero volvió a fallar
todo.
El "one-lease-for-client" creo que pinta poco en todo esto porque para
esta directiva se identifica al cliente por UID. Supongo que servirá
cuando tengo un portatil y se me da una IP. Luego me marcho a otra red
(en que coinciden los rangos de IP) y se me da otra distinta. Vuelvo a
la primera red y pida ip sugiriendo la que se me dio en la segunda red.
Como en esta red esa ip existe y quizás está libre, se me concede y
resulta que he reservado dos ips.
A lo sumo habría que suarlo en conjunción con "deny duplicates", pero en
el manual no pone que para que se descarten reservas en que coincida la
MAC haya que usar one-lease-for-client. De todos modos usé ambas a la
vez sin éxito.
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".
> Saludos,
Saludos.
--
Todos buscan quien ampare, yo quien enmiende; que más
quiero ir entendido que defendido.
--- Lope de Vega ---
Reply to: