El servicio que emite direcciones IP a dispositivos en la red local parece ser uno de los más simples y familiares. Sin embargo, mis colegas más jóvenes todavía ocasionalmente tienen preguntas como "la computadora está recibiendo una dirección extraña", y la aparición de un segundo servidor DHCP en un segmento de red causa algunos problemas de emoción o de red.
Para que quienes lean este material no tengan esas preguntas, me gustaría reunir una gran cantidad de información básica sobre el funcionamiento de los mecanismos de emisión de direcciones IP, características y ejemplos de configuración de configuraciones a prueba de fallas. Sí, y quizás especialistas inexpertos estén interesados en refrescar las conexiones neuronales.
Un poco de teoría y soluciones a problemas interesantes y no muy prácticos, debajo del corte.
En una red de área local moderna, la emisión de direcciones generalmente se realiza mediante servicios especializados con soporte de protocolo. El más popular de estos es DHCP (Protocolo de configuración dinámica de host).
Zeroconf o por qué necesitamos algún tipo de DHCP
En principio, se creó una pila de tecnología llamada Zeroconf específicamente para redes pequeñas. Le permite prescindir de los servicios y servidores centralizados, incluidos, entre otros, la emisión de direcciones IP. Cierran (bueno, o casi cierran) las siguientes preguntas:
Obtención de una dirección IP (direccionamiento IP privado automático o APIPA). El sistema mismo asigna una IP de la red 169.254.0.0/16 (excepto las cuadrículas / 24 al principio y al final del rango), en función de la dirección MAC y el generador de números pseudoaleatorios. Este sistema le permite evitar conflictos, y la dirección de esta red se llama link-local, incluso porque estas direcciones no están enrutadas.
Busca por nombre . El sistema anuncia su nombre de red, y cada computadora trabaja con él como con DNS, almacenando entradas en su caché. Apple usa la tecnología mDNS (DNS de multidifusión), y Microsoft usa LLMNR (Resolución de nombre de multidifusión local de enlace), mencionada en el artículo " Dominios, direcciones y Windows: mezclar, pero no agitar ".
Busca servicios de red . Por ejemplo, impresoras. Quizás el protocolo más famoso es UPnP , que, entre otras cosas, puede abrir puertos en los enrutadores. El protocolo es bastante complicado, usa un conjunto completo de complementos como el uso de http, a diferencia del segundo protocolo conocido: DNS-SD (DNS Service Discovery), que simplemente usa registros SRV, incluso cuando se trabaja con mDNS.
Con todas las ventajas de Zeroconf, sin ningún conocimiento sagrado, puede construir una red que funcione simplemente conectando computadoras en el nivel físico, incluso puede interferir con los especialistas de TI.
Un poco molesto, ¿no?
En los sistemas Windows, para deshabilitar el autoajuste en todos los adaptadores de red, debe crear un parámetro DWORD con el nombre IPAutoconfigurationEnabled en la sección HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters y establecerlo en 0.
Por supuesto, Zeroconf es adecuado solo para redes pequeñas y aisladas (por ejemplo, conociste a un amigo con computadoras portátiles, las conectaste a través de Wi-Fi y juguemos a Diablo II, sin perder tiempo en ningún servidor), y también quiero obtener una red local para Internet . Para no sufrir con la configuración estática de cada computadora, se crearon protocolos especiales, incluido el héroe del día: DHCP.
DHCP y sus progenitores
Una de las primeras implementaciones del protocolo para emitir direcciones IP apareció hace más de 30 años y se llamó RARP (Protocolo de resolución de direcciones inversas). Si simplificamos un poco el principio de su funcionamiento, se veía así: el cliente hizo una solicitud a la dirección de transmisión de la red, el servidor la aceptó, encontró el enlace de la dirección MAC e IP del cliente en su base de datos y envió una respuesta IP.
Esquema del protocolo RARP.
Y todo parecía funcionar. Pero el protocolo tenía sus inconvenientes: era necesario configurar el servidor en cada segmento de la red local, registrar las direcciones MAC en este servidor y no había forma de transmitir información adicional al cliente. Por lo tanto, para reemplazarlo, se creó el protocolo BOOTP (Protocolo Bootstrap).
Inicialmente, se usaba para estaciones de trabajo sin disco, que necesitaban no solo dar una dirección IP, sino también transmitir información adicional al cliente, como la dirección del servidor TFTP y el nombre del archivo de descarga. A diferencia de RARP, el protocolo ya admitía retransmisión: pequeños servicios que reenviaban solicitudes al servidor "principal". Esto hizo posible utilizar un servidor en varias redes simultáneamente. Solo quedaba la necesidad de configurar manualmente las tablas y el límite de tamaño para obtener información adicional. Como resultado, el protocolo DHCP moderno ha entrado en escena, que es una extensión compatible de BOOTP (el servidor DHCP admite clientes heredados, pero no al revés).
Una diferencia importante de los protocolos obsoletos es la capacidad de emitir temporalmente una dirección (arrendamiento) y transferir una gran cantidad de información diferente al cliente. Esto se logra debido al procedimiento menos trivial para obtener la dirección. Si en los antiguos protocolos el esquema era simple, del tipo de solicitud-respuesta, entonces el esquema es el siguiente:
- El cliente busca el servidor con una solicitud de difusión, solicitando también configuraciones adicionales.
- El servidor responde al cliente ofreciéndole una dirección IP y otras configuraciones.
- El cliente confirma la información recibida por solicitud de difusión, indicando en la confirmación la dirección IP del servidor seleccionado.
- El servidor acuerda con el cliente enviándole una solicitud, una vez recibido, el cliente ya configura la interfaz de red o la rechaza.
El esquema de comunicación del cliente con el servidor de reenvío y el servidor.
Puede leer más sobre el esquema de interacción servidor-cliente y la estructura de las solicitudes y respuestas, por ejemplo, en el material " Estructura, formato y propósito de los paquetes DHCP ".
En varias entrevistas me preguntaron: "¿Qué transporte y puerto utiliza DHCP?" Por si acaso, respondemos: "Servidor UDP: 67, cliente UDP: 68".
Muchas implementaciones de un servidor DHCP han sido encontradas por muchos, incluso al configurar una red doméstica. De hecho, ahora el servidor es:
- En casi cualquier enrutador, especialmente SOHO.
- En sistemas Windows Server. Puede leer sobre el servidor y su configuración en la documentación oficial.
- En sistemas * nix. Quizás el software más popular es el servidor DHCP ISC (dhcpd) y el "cosechador" Dnsmasq .
Hay muchas implementaciones específicas, pero, por ejemplo, la configuración del servidor está limitada en los enrutadores SOHO. Esto se refiere principalmente a configuraciones adicionales, además de la clásica "dirección IP, máscara, puerta de enlace, servidor DNS". Y son precisamente estas opciones adicionales las que causan el mayor interés en el funcionamiento del protocolo. La lista completa se puede encontrar en el RFC correspondiente, pero analizaré algunos ejemplos interesantes.
Increíbles opciones de DHCP
En esta sección, analizaré el uso práctico de las opciones de DHCP en los equipos MikroTik. Inmediatamente llamaré la atención sobre el hecho de que no todas las opciones están configuradas obviamente, el formato de los parámetros se describe en la wiki . También debe tenerse en cuenta que el cliente aplica las opciones solo cuando las solicita. En algunos servidores, puede forzar el envío de la configuración: por ejemplo, en el servidor ISC DHCP, la directiva dhcp-parameter-request-list es responsable de esto, y en Dnsmasq - * * --dhcp-option-force . MikroTik y Windows no saben cómo.
Opción 6 y Opción 15. Comencemos con una simple. La configuración número 6 son los servidores DNS asignados a los clientes, 15 es el sufijo DNS. Asignar un sufijo DNS puede ser útil cuando se trabaja con recursos de dominio en una red que no es de dominio, como describí en el artículo " Cómo redujimos el personal a través de Wi-Fi ". Configure MikroTik bajo el spoiler.
Configurar MikroTik, opción 15 Saber que un servidor DNS también es una opción recientemente ha sido útil cuando diferentes clientes tuvieron que emitir diferentes servidores DNS. La decisión del formulario "emitir un servidor y hacer diferentes reglas dst-nat para el puerto 53" no encajaba por varias razones. Parte de la configuración está nuevamente bajo el spoiler.
Configurar MikroTik, opción 6 Opción 66 y Opción 67 . Estas configuraciones regresaron de BOOTP y le permiten especificar el servidor TFTP y la imagen para el arranque de la red. Para una sucursal pequeña, es bastante conveniente instalar Mikrotik y estaciones de trabajo sin disco allí y lanzar una imagen preparada de alguna ThinStation en el enrutador . Ejemplo de configuración de DHCP:
/ip dhcp-server option add name="option66" code=66 value="s'192.168.88.1'" add name="option67" code=67 value="'pxelinux.0'" /ip dhcp-server option sets add name="set-pxe" options=option66,option67
Opción 121 y Opción 249 . Se utilizan para transferir rutas adicionales al cliente, que en algunos casos puede ser más conveniente que registrar rutas en la puerta de enlace predeterminada. La configuración es casi idéntica, excepto que los clientes de Windows prefieren la última. Para configurar el parámetro, las rutas deben convertirse a hexadecimales, recogiendo la máscara de red de destino, la dirección de red y la puerta de enlace en una línea. Además, por RFC, debe agregar una ruta predeterminada. La opción de ajuste está debajo del spoiler.
Configuración de rutaSupongamos que necesitamos agregar una ruta como dst-address = 10.0.0.0 / 24 gateway = 192.168.88.2 a los clientes, y la puerta de enlace principal será 192.168.88.1. Traigámoslo todo en HEX:
Recolectemos toda esta felicidad en una línea y obtengamos la configuración:
/ip dhcp-server option add code=121 name=classless value=0x0A0000c0a8580200c0a85801
Lea más en el artículo " Mikrotik, DHCP Classless Route ".
Opción 252. Configuración automática del servidor proxy. Si por alguna razón la organización usa un proxy opaco, será conveniente configurarlo con los clientes a través de un archivo especial wpad (pac). Un ejemplo de configuración de dicho archivo se describe en el material de Proxy Auto Configuration (PAC) . Desafortunadamente, MiroTik no tiene un servidor web incorporado para alojar este archivo. Puede usar el paquete de puntos de acceso o las funciones de metarouter para esto, pero es mejor colocar el archivo en otro lugar.
Opción 82 . Una de las opciones más útiles no es solo para el cliente, sino también para el relé DHCP. Le permite transferir información sobre el puerto del conmutador al que está conectado el cliente y la identificación del propio conmutador. En base a esta información, el servidor, a su vez, ya puede emitir un determinado conjunto de configuraciones para el cliente o simplemente iniciar sesión; para encontrar el puerto de conexión del cliente, no era necesario ir a todos los conmutadores en una fila (especialmente si no están en la pila).
Después de que se configura DHCP-Relay en el enrutador, los campos ID del circuito del agente e ID remota del agente aparecerán en la información del cliente, donde el primero es el identificador de puerto del conmutador y el segundo es el identificador del conmutador.
Emisión de direcciones con la opción 82.
La información se proporciona en formato hexadecimal. Para mayor comodidad, puede usar scripts para analizar el registro de DHCP. Por ejemplo, una solución para una solución de Microsoft se publica en la galería de scripts de Technet llamada " Decoración de las opciones de DHCP 82 ".
La opción 82 también se usa activamente en el sistema de facturación de los proveedores y en la protección de la red de interferencias externas. Esto es un poco más detallado.
Agregue redes de confiabilidad y seguridad
Debido a la simplicidad del protocolo y la presencia de solicitudes de difusión, existen ataques efectivos a la infraestructura, principalmente del tipo MITM ("hombre en el medio"). Los ataques se llevan a cabo elevando su servidor o retransmisor DHCP: después de todo, si controla la emisión de la configuración de red, puede redirigir fácilmente el tráfico a una puerta de enlace comprometida. Para facilitar el ataque, se utiliza el hambre DHCP (pretendiendo ser un cliente o un retransmisor, el atacante obliga al servidor DHCP "nativo" a agotar sus direcciones IP). Puede leer más sobre la implementación del ataque en el artículo " Atacar a DHCP ", mientras que DHCP Snooping es el método de protección.
Esta es una función de conmutación que le permite "vincular" un servidor DHCP a un puerto específico. Se bloquearán las respuestas de DHCP en otros puertos. En algunos conmutadores, puede configurar el trabajo con la Opción 82 cuando se detecta en el paquete (lo que indica la presencia de un relé): descartar, reemplazar, dejarlo sin cambios.
En los conmutadores MikroTik, la inspección DHCP está habilitada en la configuración del puente:
La configuración en otros conmutadores es similar.
Vale la pena señalar que no todos los modelos MikroTik tienen soporte completo de hardware para DHCP Snooping, solo CRS3xx lo tiene.
Además de la protección contra piratas informáticos malintencionados, esta función aliviará los dolores de cabeza cuando aparezca otro servidor DHCP en la red, por ejemplo, cuando un enrutador SOHO utilizado como un interruptor con un punto de acceso restablece su configuración. Desafortunadamente, en redes donde se encuentran equipos SOHO, no siempre existe una estructura de red de cable competente con enrutadores administrados. Pero esa es otra pregunta.
Hermoso cambio es la clave para la salud.
Otros métodos de protección incluyen la Seguridad del puerto ("vincular" una dirección MAC específica al puerto del enrutador; si se detecta tráfico de otras direcciones, se bloqueará el puerto), Análisis de tráfico para la cantidad de solicitudes y respuestas de DHCP o limitar su número y, por supuesto, varios sistemas IPS \ IDS .
Si hablamos no solo de protección de red, sino también de confiabilidad, no estará fuera de lugar mencionar las capacidades de DHCP a prueba de fallas. De hecho, con su simplicidad, DHCP es a menudo uno de los servicios clave, y si falla, el trabajo de la organización puede paralizarse. Pero si solo instala dos servidores con configuraciones idénticas, entonces nada más que un conflicto de direcciones IP conducirá a esto.
Parece que puede dividir el área de distribución entre dos servidores y dejar que uno proporcione la mitad de las direcciones y el otro proporcione el otro. Aquí hay solo una mitad paralizada de la infraestructura que es ligeramente mejor que la totalidad.
Analizaremos opciones más prácticas.
En los sistemas Windows Server a partir de 2012, el sistema de redundancia DHCP funciona de inmediato, en modo de equilibrio de carga (activo-activo) o en modo de tolerancia a fallas (activo-pasivo). Puede encontrar una descripción detallada de la tecnología y la configuración en la documentación oficial. Observo que la tolerancia a fallas se configura a nivel de zona, por lo que diferentes zonas pueden funcionar en diferentes modos.
Configuración de la conmutación por error del servidor DHCP en Windows.
El servidor DHCP de ISC utiliza la directiva de conmutación por error para configurar la tolerancia a fallos; se propone sincronizar los datos de forma independiente, por ejemplo, utilizando rsync. Lea más en el artículo " Dos servidores DHCP en Centos7 ... "
Si crea una solución tolerante a fallas basada en MikroTik, entonces no puede prescindir de trucos. Una de las opciones para resolver el problema se anunció en MUM RU 18, y luego se publicó en el blog del autor . En resumen: dos servidores están configurados, pero con un parámetro de umbral de retardo diferente (retardo de respuesta). Luego, el servidor emitirá la dirección con menos demora y con una demora más larga, solo cuando la primera falla. La sincronización de la información nuevamente debe hacerse con scripts.
Personalmente, en un momento palmeé mis nervios cuando un enrutador apareció en la red "accidentalmente" y se conectó a la red de área local, tanto a las interfaces WAN como a la LAN.
Dime, ¿tuviste que lidiar con la lepra DHCP?