Relay DHCP pe ASA peste un VPN site-to-site: un ghid pas cu pas

Relayul funcționează în trei etape și doar cea din mijloc traversează VPN-ul. Un client difuzează în segmentul sucursalei, ASA transformă acea difuzare într-o cerere unicast către serverul DHCP, iar serverul răspunde la adresa de relay, nu la client. Parcurgeți etapele în această ordine și majoritatea cazurilor de «relayul este stricat» se reduc la o politică lipsă sau la o linie setroute citită greșit.

Etapa întâi: activați relayul pe interfața orientată spre client

Pe ASA sucursalei, relayul este o proprietate a interfeței care privește spre clienți. Serverul poate fi declarat global cu interfața sa accesibilă, sau sub acea interfață orientată spre client pentru ca tabela de rutare să aleagă ieșirea. Aceste două forme nu sunt interschimbabile, iar copierea celei greșite este primul loc unde un ghid o ia greșit.

Verificați configurația curentă înainte de a schimba ceva: ce interfață are relayul activat, ce formă de server există și dacă setroute este atașat interfeței clientului. Dacă ASA rulează și un server DHCP pentru alt segment, opriți-vă și citiți lista de restricții; serverul și relayul nu pot fi activate simultan pe același echipament.

Relayul pune propria adresă orientată spre client în câmpul de adresă a gateway-ului. Aceea este adresa la care va răspunde serverul, așa că trebuie să fie accesibilă de la site-ul îndepărtat prin tunel, nu doar local.

Etapa a doua: duceți traficul generat de ASA prin tunel

Acesta este pasul pe care oamenii îl sar. Un VPN site-to-site bazat pe politici este de obicei construit pentru traficul dintre subrețele, iar cererea de relay este generată de ASA însuși. Dacă lista de acces a tunelului și harta criptografică corespund doar fluxurilor de la gazda sucursalei la subrețeaua serverului, pachetul de relay poate să nu intre niciodată în tunel. Verificați lista de acces în ambele direcții, nu doar linia de la sucursală la server.

Confirmați că traficul de interes acoperă sursa de relay a ASA și adresa serverului și că și direcția de retur este permisă. Într-un design bazat pe VTI decizia de rutare este mai simplă, dar suportul de relay peste VTI a apărut într-o versiune anume; ghidul DHCP al ASA indică 9.14(1), așa că verificați imaginea înainte de a copia un exemplu VTI pe un echipament mai vechi.

Un ping de la ASA la server dovedește puțin de unul singur. Poate reuși pe altă cale, cu altă adresă sursă sau sub o politică pe care pachetele relayului nu o îndeplinesc.

Etapa a treia: citiți răspunsul și opțiunea setroute

RFC 2131 spune că serverul își trimite răspunsul la adresa din giaddr atunci când acel câmp nu este zero. Deci calea de retur trebuie rutată către adresa de relay, iar politica tunelului trebuie să permită direcția de la server la relay. Dacă cererea a trecut, dar oferta nu sosește niciodată, aici este locul de căutat.

Apoi separați două lucruri care sună la fel. Cuvântul-cheie setroute modifică sau adaugă opțiunea de router implicit pe care ASA o dă clientului. Nu instalează o rută pe ASA și nu creează politică VPN. Un client care primește o adresă, dar nu ajunge nicăieri, are adesea o problemă de setroute sau de scop, nu de tunel. Testați cu un client fără gateway static și urmăriți care router implicit apare în ofertă.

Citiți oferta de la început la sfârșit: adresa oferită, masca, routerul implicit, DNS și durata de închiriere. Apoi lăsați închirierea să se reînnoiască. Un relay care funcționează o dată și eșuează la reînnoire are de obicei o problemă de scop, de închiriere sau de cale de retur pe care primul schimb a ascuns-o.

Ce verific înainte să spun că este rezolvat

Începeți de la client și capturați difuzarea, apoi confirmați că ASA a retransmis-o cu propria adresă ca giaddr. Pe partea îndepărtată confirmați că serverul a văzut cererea și a ales un scop potrivit sucursalei. Întors în sucursală, confirmați că clientul a acceptat oferta și ajunge la gateway-ul său.

Dacă vreo etapă este mută, verificați politica sau ruta corespunzătoare în loc să adăugați o altă instrucțiune de relay. Configurația relayului este de obicei deja corectă când cineva escaladează; politica tunelului sau ruta de retur este ce s-a schimbat.

Scrieți cele trei etape în registrul de modificări: interfața orientată spre client, politica VPN care acoperă traficul de relay și ruta de retur a serverului către giaddr. Acel registru este ce face din următoarea construcție de sucursală o muncă repetabilă în loc de o sesiune de depanare. Le spune și următorului inginer ce ieșire de comandă să colecteze mai întâi.