Relé DHCP de l’ASA sobre una VPN de lloc a lloc: guia pràctica
Recorreu les tres etapes d’un relé DHCP de l’ASA sobre una VPN de lloc a lloc: la interfície del client, la política del túnel per al trànsit de relé i la resposta a giaddr.
El relé funciona en tres etapes i només la del mig travessa la VPN. Un client fa broadcast al segment de la sucursal, l’ASA converteix aquest broadcast en una petició unicast al servidor DHCP, i el servidor respon a l’adreça del relé i no al client. Recorreu les etapes en aquest ordre i la majoria de casos de «el relé està trencat» es resolen en una política que falta o en una línia setroute mal llegida.
Etapa primera: activeu el relé a la interfície orientada al client
A l’ASA de la sucursal, el relé és una propietat de la interfície que mira cap als clients. El servidor es pot declarar globalment amb la seva interfície accessible, o bé sota aquesta interfície orientada al client perquè la taula d’encaminament triï la sortida. Aquestes dues formes no són intercanviables, i copiar la incorrecta és el primer lloc on una guia es desvia.
Reviseu la configuració en curs abans de canviar res: quina interfície té el relé activat, quina forma de servidor hi és present i si setroute està enllaçat a la interfície del client. Si l’ASA també executa un servidor DHCP per a un altre segment, atureu-vos i llegiu la llista de restriccions; el servidor i el relé no poden estar activats alhora a la mateixa màquina.
El relé posa la seva pròpia adreça orientada al client al camp d’adreça de passarel·la. És aquesta adreça la que respondrà el servidor, així que ha de ser accessible des del lloc remot a través del túnel, no només localment.
Etapa segona: porteu el trànsit generat per l’ASA pel túnel
Aquest és el pas que la gent se salta. Una VPN de lloc a lloc basada en polítiques normalment es construeix per al trànsit entre subxarxes, i la petició de relé la genera la mateixa ASA. Si la llista d’accés del túnel i el mapa criptogràfic només coincideixen amb fluxos d’amfitrió de la sucursal a la subxarxa del servidor, potser el paquet de relé no entra mai al túnel. Reviseu la llista d’accés en tots dos sentits, no només la línia de la sucursal al servidor.
Confirmeu que el trànsit interessant cobreix l’origen del relé de l’ASA i l’adreça del servidor, i que el sentit de tornada també està permès. En un disseny basat en VTI la decisió d’encaminament és més simple, però el suport de relé sobre VTI va arribar en una versió concreta; la guia de DHCP de l’ASA identifica la 9.14(1), així que comproveu la imatge abans de copiar un exemple VTI en un dispositiu més antic.
Un ping de l’ASA al servidor demostra ben poc per si sol. Pot tenir èxit per un camí diferent, amb una adreça d’origen diferent o sota una política que els paquets del relé no compleixen.
Etapa tercera: llegiu la resposta i l’opció setroute
L’RFC 2131 diu que el servidor envia la seva resposta a l’adreça de giaddr quan aquest camp no és zero. Per tant, el camí de tornada ha d’encaminar-se a l’adreça del relé, i la política del túnel ha de permetre el sentit del servidor al relé. Si la petició ha passat però l’oferta no arriba mai, és aquí on cal mirar.
Després separeu dues coses que sonen igual. La paraula clau setroute canvia o afegeix l’opció d’encaminador per defecte que l’ASA lliura al client. No instal·la cap ruta a l’ASA ni crea política de VPN. Un client que obté una adreça però no arriba enlloc sovint té un problema de setroute o d’àmbit, no de túnel. Proveu-ho amb un client sense passarel·la estàtica i observeu quin encaminador per defecte apareix a l’oferta.
Llegiu l’oferta de cap a cap: adreça oferta, màscara, encaminador per defecte, DNS i temps de concessió. Després deixeu que la concessió es renovi. Un relé que funciona un cop i falla en la renovació sol tenir un problema d’àmbit, de concessió o de camí de tornada que el primer intercanvi va amagar.
Què comprovo abans de donar-ho per arreglat
Comenceu pel client i captureu el broadcast, després confirmeu que l’ASA l’ha retransmès amb la seva pròpia adreça com a giaddr. A la banda remota, confirmeu que el servidor ha vist aquesta petició i ha triat un àmbit que coincideix amb la sucursal. De tornada a la sucursal, confirmeu que el client ha acceptat l’oferta i pot arribar a la seva passarel·la.
Si alguna etapa està en silenci, reviseu la política o la ruta corresponent en lloc d’afegir una altra declaració de relé. La configuració del relé normalment ja és correcta quan algú escala el cas; el que ha canviat és la política del túnel o la ruta de tornada.
Escriviu les tres etapes al registre de canvis: interfície orientada al client, política de VPN que cobreix el trànsit de relé i la ruta del servidor de tornada a giaddr. Aquest registre és el que converteix la propera construcció d’una sucursal en una feina repetible en lloc d’una sessió de depuració. També diu al següent enginyer quina sortida de comanda cal recollir primer.