DHCP-relä på ASA över ett site-till-site-VPN: en genomgång

Relän arbetar i tre ben, och bara det mellersta korsar VPN:en. En klient sänder ut på filialsegmentet, ASA:n gör om utsändningen till en unicast-förfrågan till DHCP-servern, och servern svarar på reläadressen i stället för på klienten. Gå igenom benen i den ordningen, och de flesta fall av «relän är trasig» landar i en saknad policy eller en felläst setroute-rad.

Ben ett: aktivera relä på det klientvända gränssnittet

På filialens ASA är relä en egenskap hos gränssnittet som vetter mot klienterna. Servern kan deklareras globalt med sitt nåbara gränssnitt, eller under det klientvända gränssnittet så att routingtabellen väljer utgången. De två formerna är inte utbytbara, och att kopiera den felaktiga är första stället en genomgång går snett.

Kontrollera den körande konfigurationen innan du ändrar något: vilket gränssnitt som har relä aktiverat, vilken serverform som finns och om setroute är kopplat till klientgränssnittet. Om ASA:n också kör en DHCP-server för ett annat segment, stanna och läs begränsningslistan; server och relä kan inte vara aktiverade samtidigt på samma enhet.

Relän lägger sin egen klientvända adress i gateway-adressfältet. Det är den adressen servern kommer att svara på, så den måste vara nåbar från den avlägsna platsen genom tunneln, inte bara lokalt.

Ben två: bär den ASA-genererade trafiken genom tunneln

Det här är steget folk hoppar över. Ett policybaserat site-till-site-VPN byggs vanligtvis för trafik mellan subnät, och reläförfrågan genereras av ASA:n själv. Om tunnelns åtkomstlista och kryptokartan bara matchar flöden från filialvärd till serversubnät, kan reläpaketet aldrig komma in i tunneln. Kontrollera åtkomstlistan i båda riktningarna, inte bara raden från filial till server.

Bekräfta att den intressanta trafiken täcker ASA:ns reläkälla och serveradressen, och att returriktningen också är tillåten. I en VTI-baserad design är routingbeslutet enklare, men relästöd över VTI kom i en bestämd version; DHCP-guiden för ASA anger 9.14(1), så kontrollera avbildningen innan du kopierar ett VTI-exempel till en äldre enhet.

En ping från ASA:n till servern bevisar lite i sig själv. Den kan lyckas via en annan väg, med en annan källadress eller under en policy som reläpaketen inte matchar.

Ben tre: läs svaret och setroute-alternativet

RFC 2131 säger att servern skickar sitt svar till adressen i giaddr när fältet inte är noll. Alltså måste returvägen routas till reläadressen, och tunnelpolicyn måste tillåta riktningen från server till relä. Om förfrågan kom igenom men erbjudandet aldrig anländer, är det här du ska titta.

Skilj sedan på två saker som låter likadana. Nyckelordet setroute ändrar eller lägger till standardrouteralternativet som ASA:n ger klienten. Det installerar ingen rutt på ASA:n och skapar ingen VPN-policy. En klient som får en adress men inte når något har ofta ett setroute- eller scope-problem, inte ett tunnelproblem. Testa med en klient utan statisk gateway och se vilken standardrouter som dyker upp i erbjudandet.

Läs erbjudandet från början till slut: erbjuden adress, mask, standardrouter, DNS och leasetime. Låt sedan leasen förnyas. En relä som fungerar en gång och misslyckas vid förnyelse har oftast ett scope-, lease- eller returvägsproblem som det första utbytet dolde.

Vad jag kontrollerar innan jag säger att det är åtgärdat

Börja vid klienten och fånga utsändningen, bekräfta sedan att ASA:n vidarebefordrade den med sin egen adress som giaddr. På den avlägsna sidan bekräftar du att servern såg förfrågan och valde ett scope som passar filialen. Tillbaka i filialen bekräftar du att klienten accepterade erbjudandet och når sin gateway.

Om något ben är tyst, kontrollera motsvarande policy eller rutt i stället för att lägga till ytterligare en reläsats. Reläkonfigurationen är oftast redan korrekt när någon eskalerar; det är tunnelpolicyn eller returvägen som ändrats.

Skriv de tre benen i ändringsloggen: klientvänt gränssnitt, VPN-policy som täcker relätrafik och serverns returväg till giaddr. Det är den loggen som gör nästa filialutbyggnad till ett repeterbart arbete i stället för en felsökningssession. Den berättar också för nästa ingenjör vilken kommandoutdata som ska samlas in först.