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

Relayet arbejder i tre ben, og kun det midterste krydser VPN’en. En klient broadcaster på filialsegmentet, ASA’en laver den broadcast om til en unicast-anmodning til DHCP-serveren, og serveren svarer på relayadressen i stedet for klienten. Gå benene igennem i den rækkefølge, og de fleste tilfælde af «relayet er i stykker» ender med en manglende politik eller en fejllæst setroute-linje.

Ben et: aktivér relay på det klientvendte interface

På filialens ASA er relay en egenskab ved det interface, der vender mod klienterne. Serveren kan erklæres globalt med sit tilgængelige interface, eller under det klientvendte interface, så routingtabellen vælger udgangen. De to former kan ikke udskiftes, og at kopiere den forkerte er det første sted, en gennemgang går galt.

Kontrollér den kørende konfiguration, før du ændrer noget: hvilket interface har relay aktiveret, hvilken serverform er til stede, og er setroute knyttet til klientinterfacet. Hvis ASA’en også kører en DHCP-server for et andet segment, så stop og læs begrænsningslisten; server og relay kan ikke være aktiveret samtidig på samme boks.

Relayet sætter sin egen klientvendte adresse i gateway-adressefeltet. Det er den adresse, serveren vil svare på, så den skal være tilgængelig fra det fjerne site gennem tunnelen, ikke kun lokalt.

Ben to: bær ASA-genereret trafik gennem tunnelen

Det er det trin, folk springer over. En policybaseret site-til-site VPN bygges normalt til trafik mellem subnets, og relayanmodningen genereres af ASA’en selv. Hvis tunnelens accessliste og crypto map kun matcher flows fra filialvært til serversubnet, kommer relaypakken måske aldrig ind i tunnelen. Kontrollér accesslisten i begge retninger, ikke kun linjen fra filial til server.

Bekræft, at den interessante trafik dækker ASA’ens relay-kilde og serveradressen, og at returretningen også er tilladt. I et VTI-baseret design er routingbeslutningen enklere, men relay-understøttelse over VTI kom i en bestemt version; ASA’ens DHCP-vejledning angiver 9.14(1), så kontrollér imagen, før du kopierer et VTI-eksempel til et ældre apparat.

Et ping fra ASA’en til serveren beviser lidt i sig selv. Det kan lykkes ad en anden vej, med en anden kildeadresse eller under en politik, som relayets pakker ikke matcher.

Ben tre: læs svaret og setroute-indstillingen

RFC 2131 siger, at serveren sender sit svar til adressen i giaddr, når feltet ikke er nul. Altså skal returvejen route til relayadressen, og tunnelpolitikken skal tillade retningen fra server til relay. Hvis anmodningen kom igennem, men tilbuddet aldrig ankommer, er det her, du skal kigge.

Skel så to ting, der lyder ens. Nøgleordet setroute ændrer eller tilføjer den standardrouter-indstilling, som ASA’en giver klienten. Det installerer ikke en rute på ASA’en og opretter ikke VPN-politik. En klient, der får en adresse, men ikke kan nå noget, har ofte et setroute- eller scope-problem, ikke et tunnelproblem. Test det med en klient uden statisk gateway, og se hvilken standardrouter der dukker op i tilbuddet.

Læs tilbuddet fra ende til anden: tilbudt adresse, maske, standardrouter, DNS og lejetid. Lad derefter lejet forny. Et relay, der virker én gang og fejler ved fornyelse, har normalt et scope-, leje- eller returvejsproblem, som den første udveksling skjulte.

Hvad jeg kontrollerer, før jeg kalder det løst

Start ved klienten og fang broadcasten, og bekræft derefter, at ASA’en videresendte den med sin egen adresse som giaddr. På den fjerne side bekræfter du, at serveren så anmodningen og valgte et scope, der passer til filialen. Tilbage i filialen bekræfter du, at klienten accepterede tilbuddet og kan nå sin gateway.

Hvis noget ben er tavst, så kontrollér den matchende politik eller rute i stedet for at tilføje endnu en relay-erklæring. Relaykonfigurationen er normalt rigtig på det tidspunkt, nogen eskalerer; det er tunnelpolitikken eller returruten, der er ændret.

Skriv de tre ben ind i ændringsregistret: klientvendt interface, VPN-politik der dækker relaytrafik, og serverens rute tilbage til giaddr. Det er det register, der gør den næste filials opbygning til et gentageligt arbejde i stedet for en fejlfindingssession. Det fortæller også den næste ingeniør, hvilket kommandooutput der skal indsamles først.