DHCP-relay op de ASA over een site-to-site-VPN: een rondgang

De relay werkt in drie benen, en alleen het middelste steekt de VPN over. Een client zendt uit op het filiaalsegment, de ASA maakt van die uitzending een unicast-verzoek aan de DHCP-server, en de server antwoordt op het relayadres in plaats van op de client. Loop de benen in die volgorde door, en de meeste gevallen van «de relay is stuk» komen neer op een ontbrekend beleid of een verkeerd gelezen setroute-regel.

Been één: relay aanzetten op de clientgerichte interface

Op de ASA van de filial is relay een eigenschap van de interface die naar de clients kijkt. De server kan globaal worden gedeclareerd met zijn bereikbare interface, of onder die clientgerichte interface zodat de routetabel de uitgang kiest. Die twee vormen zijn niet uitwisselbaar, en de verkeerde kopiëren is de eerste plek waar een rondgang misgaat.

Controleer de lopende configuratie voordat je iets verandert: welke interface relay heeft ingeschakeld, welke servervorm aanwezig is, en of setroute aan de clientinterface hangt. Als de ASA ook een DHCP-server voor een ander segment draait, stop dan en lees de beperkingenlijst; server en relay kunnen niet tegelijk op dezelfde doos worden ingeschakeld.

De relay zet zijn eigen clientgerichte adres in het gateway-adresveld. Dat is het adres waarop de server zal antwoorden, dus het moet vanaf de verre locatie via de tunnel bereikbaar zijn, niet alleen lokaal.

Been twee: het door de ASA gegenereerde verkeer door de tunnel dragen

Dit is de stap die mensen overslaan. Een op beleid gebaseerde site-to-site-VPN wordt meestal gebouwd voor verkeer tussen subnetten, en het relayverzoek wordt door de ASA zelf gegenereerd. Als de toegangslijst van de tunnel en de cryptomap alleen overeenkomen met stromen van filiaalhost naar serversubnet, komt het relaypakket misschien nooit in de tunnel. Controleer de toegangslijst in beide richtingen, niet alleen de regel van filiaal naar server.

Bevestig dat het interessante verkeer de relaybron van de ASA en het serveradres dekt, en dat de retourrichting ook is toegestaan. Bij een op VTI gebaseerd ontwerp is de routingbeslissing eenvoudiger, maar relayondersteuning over VTI kwam in een specifieke release; de DHCP-gids van de ASA noemt 9.14(1), dus controleer de image voordat je een VTI-voorbeeld naar een ouder apparaat kopieert.

Een ping van de ASA naar de server bewijst op zichzelf weinig. Hij kan slagen via een ander pad, met een ander bronadres, of onder een beleid waarmee de pakketten van de relay niet overeenkomen.

Been drie: het antwoord en de setroute-optie lezen

RFC 2131 zegt dat de server zijn antwoord naar het adres in giaddr stuurt wanneer dat veld niet nul is. Dus moet de retourweg naar het relayadres routeren, en het tunnelbeleid moet de richting van server naar relay toestaan. Als het verzoek erdoor kwam maar het aanbod nooit aankomt, is dit de plek om te kijken.

Scheid dan twee dingen die hetzelfde klinken. Het sleutelwoord setroute wijzigt of voegt de standaardrouter-optie toe die de ASA aan de client geeft. Het installeert geen route op de ASA en maakt geen VPN-beleid. Een client die een adres krijgt maar niets bereikt, heeft vaak een setroute- of scopeprobleem, geen tunnelprobleem. Test het met een client zonder statische gateway en kijk welke standaardrouter in het aanbod verschijnt.

Lees het aanbod van begin tot eind: aangeboden adres, masker, standaardrouter, DNS en leasetijd. Laat de lease daarna vernieuwen. Een relay die één keer werkt en bij vernieuwing faalt, heeft meestal een scope-, lease- of retourwegprobleem dat de eerste uitwisseling verborgen hield.

Wat ik controleer voordat ik het opgelost noem

Begin bij de client en vang de uitzending, bevestig dan dat de ASA hem met zijn eigen adres als giaddr heeft doorgestuurd. Aan de verre kant bevestig je dat de server dat verzoek zag en een scope koos die bij de filiaal past. Terug in de filiaal bevestig je dat de client het aanbod accepteerde en zijn gateway bereikt.

Als een been stil is, controleer dan het bijbehorende beleid of de route in plaats van nog een relay-verklaring toe te voegen. De relayconfiguratie is meestal al juist op het moment dat iemand escaleert; het is het tunnelbeleid of de retourroute dat is veranderd.

Schrijf de drie benen in het wijzigingsregister: clientgerichte interface, VPN-beleid dat relayverkeer dekt, en de retourroute van de server naar giaddr. Dat register maakt de volgende filiaaluitbouw herhaalbaar werk in plaats van een debug-sessie. Het vertelt de volgende engineer ook welke commando-uitvoer eerst moet worden verzameld.