Retransmisión DHCP del ASA sobre una VPN de sitio a sitio: guía paso a paso

La retransmisión funciona en tres etapas y solo la del medio cruza la VPN. Un cliente difunde en el segmento de la sucursal, el ASA convierte esa difusión en una solicitud unicast al servidor DHCP, y el servidor responde a la dirección de retransmisión y no al cliente. Recorra las etapas en ese orden y la mayoría de los casos de «la retransmisión está rota» se resuelven en una política que falta o en una línea setroute mal leída.

Etapa primera: active la retransmisión en la interfaz orientada al cliente

En el ASA de la sucursal, la retransmisión es una propiedad de la interfaz que mira hacia los clientes. El servidor puede declararse globalmente con su interfaz accesible, o bajo esa interfaz orientada al cliente para que la tabla de rutas elija la salida. Esas dos formas no son intercambiables, y copiar la incorrecta es el primer punto donde una guía se descarrila.

Revise la configuración en ejecución antes de cambiar nada: qué interfaz tiene la retransmisión activada, qué forma de servidor está presente y si setroute está asociado a la interfaz del cliente. Si el ASA también ejecuta un servidor DHCP para otro segmento, deténgase y lea la lista de restricciones; el servidor y la retransmisión no pueden estar activados a la vez en el mismo equipo.

La retransmisión coloca su propia dirección orientada al cliente en el campo de dirección de puerta de enlace. Esa dirección es la que responderá el servidor, así que debe ser accesible desde el sitio remoto a través del túnel, no solo localmente.

Etapa segunda: lleve el tráfico generado por el ASA por el túnel

Este es el paso que la gente se salta. Una VPN de sitio a sitio basada en políticas suele construirse para el tráfico entre subredes, y la solicitud de retransmisión la genera el propio ASA. Si la lista de acceso del túnel y el mapa criptográfico solo coinciden con flujos de host de sucursal a subred del servidor, puede que el paquete de retransmisión nunca entre en el túnel. Revise la lista de acceso en ambos sentidos, no solo la línea de sucursal a servidor.

Confirme que el tráfico interesante cubre el origen de retransmisión del ASA y la dirección del servidor, y que también se permite el sentido de vuelta. En un diseño basado en VTI la decisión de encaminamiento es más simple, pero el soporte de retransmisión sobre VTI llegó en una versión concreta; la guía de DHCP del ASA identifica la 9.14(1), así que compruebe la imagen antes de copiar un ejemplo VTI en un equipo más antiguo.

Un ping del ASA al servidor demuestra poco por sí solo. Puede tener éxito por otra ruta, con otra dirección de origen o bajo una política que los paquetes de la retransmisión no cumplen.

Etapa tercera: lea la respuesta y la opción setroute

El RFC 2131 dice que el servidor envía su respuesta a la dirección de giaddr cuando ese campo no es cero. Por tanto, la ruta de vuelta debe encaminarse a la dirección de retransmisión, y la política del túnel debe permitir el sentido de servidor a retransmisión. Si la solicitud cruzó pero la oferta nunca llega, aquí es donde hay que mirar.

Después separe dos cosas que suenan igual. La palabra clave setroute cambia o añade la opción de enrutador predeterminado que el ASA entrega al cliente. No instala una ruta en el ASA ni crea política de VPN. Un cliente que obtiene una dirección pero no llega a nada suele tener un problema de setroute o de ámbito, no de túnel. Pruébelo con un cliente sin puerta de enlace estática y observe qué enrutador predeterminado aparece en la oferta.

Lea la oferta de principio a fin: dirección ofrecida, máscara, enrutador predeterminado, DNS y tiempo de concesión. Luego deje que la concesión se renueve. Una retransmisión que funciona una vez y falla en la renovación suele tener un problema de ámbito, de concesión o de ruta de vuelta que el primer intercambio ocultó.

Qué compruebo antes de darlo por arreglado

Empiece por el cliente y capture la difusión, luego confirme que el ASA la retransmitió con su propia dirección como giaddr. En el lado remoto, confirme que el servidor vio esa solicitud y eligió un ámbito que coincide con la sucursal. De vuelta en la sucursal, confirme que el cliente aceptó la oferta y llega a su puerta de enlace.

Si alguna etapa está en silencio, revise la política o la ruta correspondiente en lugar de añadir otra sentencia de retransmisión. La configuración de retransmisión suele estar bien cuando alguien escala el caso; lo que ha cambiado es la política del túnel o la ruta de vuelta.

Escriba las tres etapas en el registro de cambios: interfaz orientada al cliente, política de VPN que cubre el tráfico de retransmisión y la ruta del servidor de vuelta a giaddr. Ese registro es lo que convierte la siguiente construcción de una sucursal en un trabajo repetible en lugar de una sesión de depuración. También dice al siguiente ingeniero qué salida de comando recoger primero.