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

Relayen arbeider i tre bein, og berre det midtre kryssar VPN-en. Ein klient kringkastar på filialsegmentet, ASA-en gjer om kringkastinga til ein unicast-førespurnad til DHCP-tenaren, og tenaren svarar på relayadressa i staden for klienten. Gå gjennom beina i den rekkjefølgja, og dei fleste tilfella av «relayen er øydelagd» endar i ein manglande politikk eller ei feillesen setroute-linje.

Bein éin: slå på relay på det klientvende grensesnittet

På filialens ASA er relay ein eigenskap ved grensesnittet som vender mot klientane. Tenaren kan erklærast globalt med sitt tilgjengelege grensesnitt, eller under det klientvende grensesnittet slik at rutetabellen vel utgangen. Dei to formene er ikkje utbyttbare, og å kopiere den gale er den fyrste staden ein gjennomgang går gale.

Sjekk den køyrande konfigurasjonen før du endrar noko: kva grensesnitt som har relay slått på, kva tenarform som finst, og om setroute er knytt til klientgrensesnittet. Viss ASA-en òg køyrer ein DHCP-tenar for eit anna segment, stopp og les avgrensingslista; tenar og relay kan ikkje vere slått på samstundes på same boks.

Relayen set si eiga klientvende adresse i gateway-adressefeltet. Det er den adressa tenaren vil svare på, så ho må vere tilgjengeleg frå den fjerne staden gjennom tunnelen, ikkje berre lokalt.

Bein to: ber ASA-generert trafikk gjennom tunnelen

Dette er trinnet folk hoppar over. Ein policybasert site-til-site-VPN blir vanlegvis bygd for trafikk mellom subnett, og relayførespurnaden blir generert av ASA-en sjølv. Viss tilgangslista til tunnelen og kryptokartet berre matcher straumar frå filialvert til tenarsubnett, kan det hende relaypakken aldri kjem inn i tunnelen. Sjekk tilgangslista i båe retningar, ikkje berre lina frå filial til tenar.

Stadfest at den interessante trafikken dekkjer relaykjelda til ASA-en og tenaradressa, og at returretninga òg er tillaten. I eit VTI-basert design er rutingsavgjerda enklare, men relaystøtte over VTI kom i ein bestemd versjon; DHCP-veiledninga for ASA nemner 9.14(1), så sjekk avbildet før du kopierer eit VTI-døme til eit eldre apparat.

Ein ping frå ASA-en til tenaren provar lite i seg sjølv. Han kan lukkast via ein annan veg, med ei anna kjeldeadresse, eller under ein politikk som relaypakkane ikkje matchar.

Bein tre: les svaret og setroute-valet

RFC 2131 seier at tenaren sender svaret sitt til adressa i giaddr når feltet ikkje er null. Altså må returvegen rute til relayadressa, og tunnelpolitikken må tillate retninga frå tenar til relay. Viss førespurnaden kom gjennom men tilbodet aldri kjem, er det her du skal sjå.

Skil så to ting som høyrest like ut. Nøkkelordet setroute endrar eller legg til standardrutervalet som ASA-en gir klienten. Det installerer ikkje ei rute på ASA-en og opprettar ikkje VPN-politikk. Ein klient som får ei adresse men ikkje når noko, har ofte eit setroute- eller scope-problem, ikkje eit tunnelproblem. Test det med ein klient utan statisk gateway og sjå kva standardruter som dukkar opp i tilbodet.

Les tilbodet frå ende til annan: tilboden adresse, maske, standardruter, DNS og leigetid. La deretter leiga fornyast. Ein relay som verkar éin gong og feilar ved fornying, har vanlegvis eit scope-, leige- eller returvegsproblem som den fyrste utvekslinga skjulte.

Kva eg sjekkar før eg kallar det løyst

Start ved klienten og fang kringkastinga, stadfest deretter at ASA-en vidaresende henne med si eiga adresse som giaddr. På den fjerne sida stadfestar du at tenaren såg førespurnaden og valde eit scope som passar filialen. Tilbake i filialen stadfestar du at klienten tok imot tilbodet og når gatewayen sin.

Viss eit bein er stille, sjekk den tilhøyrande politikken eller ruta i staden for å leggje til endå ei relay-setning. Relaykonfigurasjonen er vanlegvis rett når nokon eskalerer; det er tunnelpolitikken eller returvegen som er endra.

Skriv dei tre beina i endringsloggen: klientvendt grensesnitt, VPN-politikk som dekkjer relaytrafikk, og returvegen til tenaren til giaddr. Det er den loggen som gjer den neste filialutbygginga til eit repeterbart arbeid i staden for ei feilsøkingsøkt. Han fortel òg den neste ingeniøren kva kommando-utdata som skal samlast inn fyrst.