Retransmisión DHCP do ASA sobre unha VPN de sitio a sitio: guía paso a paso

A retransmisión funciona en tres etapas e só a do medio cruza a VPN. Un cliente difunde no segmento da sucursal, o ASA converte esa difusión nunha solicitude unicast ao servidor DHCP, e o servidor responde ao enderezo de retransmisión e non ao cliente. Percorra as etapas nesa orde e a maioría dos casos de «a retransmisión está rota» resólvense nunha política que falta ou nunha liña setroute mal lida.

Etapa primeira: active a retransmisión na interface orientada ao cliente

No ASA da sucursal, a retransmisión é unha propiedade da interface que mira cara aos clientes. O servidor pode declararse globalmente coa súa interface accesible, ou baixo esa interface orientada ao cliente para que a táboa de rutas escolla a saída. Esas dúas formas non son intercambiables, e copiar a incorrecta é o primeiro punto onde unha guía se desvía.

Revise a configuración en execución antes de cambiar nada: que interface ten a retransmisión activada, que forma de servidor está presente e se setroute está asociado á interface do cliente. Se o ASA tamén executa un servidor DHCP para outro segmento, detéñase e lea a lista de restricións; o servidor e a retransmisión non poden estar activados á vez no mesmo equipo.

A retransmisión coloca o seu propio enderezo orientado ao cliente no campo de enderezo de pasarela. Ese enderezo é o que responderá o servidor, así que debe ser accesible desde o sitio remoto a través do túnel, non só localmente.

Etapa segunda: leve o tráfico xerado polo ASA polo túnel

Este é o paso que a xente se salta. Unha VPN de sitio a sitio baseada en políticas adoita construírse para o tráfico entre subredes, e a solicitude de retransmisión xéraa o propio ASA. Se a lista de acceso do túnel e o mapa criptográfico só coinciden con fluxos de host da sucursal á subrede do servidor, pode que o paquete de retransmisión nunca entre no túnel. Revise a lista de acceso en ambos os sentidos, non só a liña de sucursal a servidor.

Confirme que o tráfico interesante cobre a orixe de retransmisión do ASA e o enderezo do servidor, e que tamén se permite o sentido de volta. Nun deseño baseado en VTI a decisión de encamiñamento é máis simple, pero o soporte de retransmisión sobre VTI chegou nunha versión concreta; a guía de DHCP do ASA identifica a 9.14(1), así que comprobe a imaxe antes de copiar un exemplo VTI nun equipo máis antigo.

Un ping do ASA ao servidor demostra pouco por si só. Pode ter éxito por outra ruta, con outro enderezo de orixe ou baixo unha política que os paquetes da retransmisión non cumpren.

Etapa terceira: lea a resposta e a opción setroute

O RFC 2131 di que o servidor envía a súa resposta ao enderezo de giaddr cando ese campo non é cero. Polo tanto, a ruta de volta debe encamiñarse ao enderezo de retransmisión, e a política do túnel debe permitir o sentido de servidor a retransmisión. Se a solicitude cruzou pero a oferta nunca chega, aquí é onde hai que mirar.

Despois separe dúas cousas que soan igual. A palabra clave setroute cambia ou engade a opción de enrutador predeterminado que o ASA entrega ao cliente. Non instala unha ruta no ASA nin crea política de VPN. Un cliente que obtén un enderezo pero non chega a nada adoita ter un problema de setroute ou de ámbito, non de túnel. Probeo cun cliente sen pasarela estática e observe que enrutador predeterminado aparece na oferta.

Lea a oferta de principio a fin: enderezo ofrecido, máscara, enrutador predeterminado, DNS e tempo de concesión. Logo deixe que a concesión se renove. Unha retransmisión que funciona unha vez e falla na renovación adoita ter un problema de ámbito, de concesión ou de ruta de volta que o primeiro intercambio ocultou.

Que comprobo antes de dalo por arranxado

Empece polo cliente e capture a difusión, logo confirme que o ASA a retransmitiu co seu propio enderezo como giaddr. No lado remoto, confirme que o servidor viu esa solicitude e escolleu un ámbito que coincide coa sucursal. De volta na sucursal, confirme que o cliente aceptou a oferta e chega á súa pasarela.

Se algunha etapa está en silencio, revise a política ou a ruta correspondente en lugar de engadir outra sentenza de retransmisión. A configuración de retransmisión adoita estar ben cando alguén escala o caso; o que cambiou é a política do túnel ou a ruta de volta.

Escriba as tres etapas no rexistro de cambios: interface orientada ao cliente, política de VPN que cobre o tráfico de retransmisión e a ruta do servidor de volta a giaddr. Ese rexistro é o que converte a seguinte construción dunha sucursal nun traballo repetible en lugar dunha sesión de depuración. Tamén lle di ao seguinte enxeñeiro que saída de comando recoller primeiro.