DHCP-relay på ASA over en site-til-site-VPN: en gjennomgang

Relayen arbeider i tre bein, og bare det midterste krysser VPN-en. En klient kringkaster på filialsegmentet, ASA-en gjør om kringkastingen til en unicast-forespørsel til DHCP-serveren, og serveren svarer på relayadressen i stedet for klienten. Gå gjennom beina i den rekkefølgen, og de fleste tilfellene av «relayen er ødelagt» ender i en manglende policy eller en feilleset setroute-linje.

Bein én: aktiver relay på det klientvendte grensesnittet

På filialens ASA er relay en egenskap ved grensesnittet som vender mot klientene. Serveren kan erklæres globalt med sitt tilgjengelige grensesnitt, eller under det klientvendte grensesnittet slik at rutetabellen velger utgangen. De to formene er ikke utbyttbare, og å kopiere den gale er det første stedet en gjennomgang går galt.

Sjekk den kjørende konfigurasjonen før du endrer noe: hvilket grensesnitt som har relay aktivert, hvilken serverform som finnes, og om setroute er knyttet til klientgrensesnittet. Hvis ASA-en også kjører en DHCP-server for et annet segment, stopp og les begrensningslisten; server og relay kan ikke være aktivert samtidig på samme boks.

Relayen setter sin egen klientvendte adresse i gateway-adressefeltet. Det er den adressen serveren vil svare på, så den må være tilgjengelig fra det fjerne stedet gjennom tunnelen, ikke bare lokalt.

Bein to: bær ASA-generert trafikk gjennom tunnelen

Dette er trinnet folk hopper over. En policybasert site-til-site-VPN bygges vanligvis for trafikk mellom subnet, og relayforespørselen genereres av ASA-en selv. Hvis tunnelens tilgangsliste og kryptokartet bare matcher strømmer fra filialvert til serversubnett, kan det hende relaypakken aldri kommer inn i tunnelen. Sjekk tilgangslisten i begge retninger, ikke bare linjen fra filial til server.

Bekreft at den interessante trafikken dekker relaykilden til ASA-en og serveradressen, og at returretningen også er tillatt. I et VTI-basert design er rutingsavgjørelsen enklere, men relaystøtte over VTI kom i en bestemt versjon; DHCP-veiledningen for ASA angir 9.14(1), så sjekk avbildet før du kopierer et VTI-eksempel til et eldre apparat.

En ping fra ASA-en til serveren beviser lite i seg selv. Den kan lykkes via en annen vei, med en annen kildeadresse, eller under en policy som relaypakkene ikke matcher.

Bein tre: les svaret og setroute-alternativet

RFC 2131 sier at serveren sender svaret sitt til adressen i giaddr når feltet ikke er null. Altså må returveien rute til relayadressen, og tunnelpolicyen må tillate retningen fra server til relay. Hvis forespørselen kom gjennom men tilbudet aldri ankommer, er det her du skal se.

Skill så to ting som høres like ut. Nøkkelordet setroute endrer eller legger til standardruteralternativet som ASA-en gir klienten. Det installerer ikke en rute på ASA-en og oppretter ikke VPN-policy. En klient som får en adresse men ikke når noe, har ofte et setroute- eller scope-problem, ikke et tunnelproblem. Test det med en klient uten statisk gateway og se hvilken standardruter som dukker opp i tilbudet.

Les tilbudet fra ende til annen: tilbudt adresse, maske, standardruter, DNS og leietid. La deretter leien fornyes. En relay som virker én gang og feiler ved fornyelse, har vanligvis et scope-, leie- eller returveiproblem som den første utvekslingen skjulte.

Hva jeg sjekker før jeg kaller det løst

Start ved klienten og fang kringkastingen, bekreft deretter at ASA-en videresendte den med sin egen adresse som giaddr. På den fjerne siden bekrefter du at serveren så forespørselen og valgte et scope som passer filialen. Tilbake i filialen bekrefter du at klienten godtok tilbudet og når gatewayen sin.

Hvis noe bein er stille, sjekk den tilhørende policyen eller ruten i stedet for å legge til enda en relay-setning. Relaykonfigurasjonen er vanligvis riktig når noen eskalerer; det er tunnelpolicyen eller returveien som er endret.

Skriv de tre beina i endringsloggen: klientvendt grensesnitt, VPN-policy som dekker relaytrafikk, og serverens returvei til giaddr. Det er den loggen som gjør den neste filialutbyggingen til et repeterbart arbeid i stedet for en feilsøkingsøkt. Den forteller også den neste ingeniøren hvilken kommando-utdata som skal samles inn først.