ASA-DHCP-Relay über ein Site-to-Site-VPN: ein Durchgang

Das Relay arbeitet in drei Etappen, und nur die mittlere durchquert das VPN. Ein Client sendet einen Broadcast im Filialsegment, die ASA macht daraus eine Unicast-Anfrage an den DHCP-Server, und der Server antwortet auf die Relay-Adresse statt auf den Client. Gehen Sie die Etappen in dieser Reihenfolge durch, und die meisten Fälle von „das Relay ist kaputt“ lösen sich in eine fehlende Richtlinie oder eine falsch gelesene setroute-Zeile auf.

Etappe eins: Relay auf der clientzugewandten Schnittstelle aktivieren

Auf der ASA der Filiale ist Relay eine Eigenschaft der Schnittstelle, die zu den Clients zeigt. Der Server lässt sich global mit seiner erreichbaren Schnittstelle deklarieren oder unter dieser clientzugewandten Schnittstelle, damit die Routingtabelle den Ausgang wählt. Diese beiden Formen sind nicht austauschbar, und die falsche zu kopieren ist die erste Stelle, an der ein Durchgang schiefgeht.

Prüfen Sie die laufende Konfiguration, bevor Sie etwas ändern: welche Schnittstelle Relay aktiviert hat, welche Serverform vorhanden ist und ob setroute an der Client-Schnittstelle hängt. Wenn die ASA zusätzlich einen DHCP-Server für ein anderes Segment betreibt, halten Sie an und lesen Sie die Einschränkungsliste; Server und Relay lassen sich nicht gleichzeitig auf derselben Box aktivieren.

Das Relay setzt seine eigene clientzugewandte Adresse in das Gateway-Adressfeld. Auf diese Adresse wird der Server antworten, also muss sie vom fernen Standort über den Tunnel erreichbar sein, nicht nur lokal.

Etappe zwei: den von der ASA erzeugten Verkehr durch den Tunnel führen

Dies ist der Schritt, den Leute überspringen. Ein richtlinienbasiertes Site-to-Site-VPN wird üblicherweise für Verkehr zwischen Subnetzen gebaut, und die Relay-Anfrage erzeugt die ASA selbst. Wenn die Zugriffsliste des Tunnels und die Krypto-Map nur Flüsse vom Filialhost zum Server-Subnetz abdecken, gelangt das Relay-Paket möglicherweise nie in den Tunnel. Prüfen Sie die Zugriffsliste in beide Richtungen, nicht nur die Zeile von der Filiale zum Server.

Bestätigen Sie, dass der interessante Verkehr die Relay-Quelle der ASA und die Serveradresse abdeckt und dass auch die Rückrichtung erlaubt ist. Bei einem VTI-basierten Entwurf ist die Routingentscheidung einfacher, aber Relay-Unterstützung über VTI kam in einem bestimmten Release; der DHCP-Leitfaden der ASA nennt 9.14(1), prüfen Sie also das Image, bevor Sie ein VTI-Beispiel auf ein älteres Gerät kopieren.

Ein Ping von der ASA zum Server beweist für sich genommen wenig. Er kann über einen anderen Pfad gelingen, mit einer anderen Quelladresse oder unter einer Richtlinie, zu der die Pakete des Relays nicht passen.

Etappe drei: die Antwort und die setroute-Option lesen

RFC 2131 besagt, dass der Server seine Antwort an die Adresse in giaddr sendet, wenn dieses Feld ungleich null ist. Also muss der Rückweg zur Relay-Adresse routen, und die Tunnelrichtlinie muss die Richtung vom Server zum Relay erlauben. Wenn die Anfrage durchkam, das Angebot aber nie ankommt, ist hier die Stelle zum Nachsehen.

Trennen Sie dann zwei Dinge, die ähnlich klingen. Das Schlüsselwort setroute ändert oder ergänzt die Standardrouter-Option, die die ASA dem Client übergibt. Es installiert keine Route auf der ASA und erzeugt keine VPN-Richtlinie. Ein Client, der eine Adresse bekommt, aber nichts erreicht, hat oft ein setroute- oder Scope-Problem, kein Tunnelproblem. Testen Sie es mit einem Client ohne statisches Gateway und beobachten Sie, welcher Standardrouter im Angebot erscheint.

Lesen Sie das Angebot von Anfang bis Ende: angebotene Adresse, Maske, Standardrouter, DNS und Lease-Zeit. Lassen Sie dann die Lease erneuern. Ein Relay, das einmal funktioniert und bei der Erneuerung scheitert, hat meist ein Scope-, Lease- oder Rückwegproblem, das der erste Austausch verdeckt hat.

Was ich prüfe, bevor ich es als behoben bezeichne

Beginnen Sie beim Client und zeichnen Sie den Broadcast auf, dann bestätigen Sie, dass die ASA ihn mit ihrer eigenen Adresse als giaddr weitergeleitet hat. Auf der Gegenseite bestätigen Sie, dass der Server die Anfrage gesehen und einen Scope gewählt hat, der zur Filiale passt. Zurück in der Filiale bestätigen Sie, dass der Client das Angebot angenommen hat und sein Gateway erreicht.

Wenn eine Etappe stumm bleibt, prüfen Sie die passende Richtlinie oder Route, statt eine weitere Relay-Anweisung hinzuzufügen. Die Relay-Konfiguration ist meist schon richtig, wenn jemand eskaliert; geändert hat sich die Tunnelrichtlinie oder die Rückroute.

Schreiben Sie die drei Etappen in den Änderungsdatensatz: clientzugewandte Schnittstelle, VPN-Richtlinie, die Relay-Verkehr abdeckt, und die Rückroute des Servers zu giaddr. Dieser Datensatz macht den nächsten Filialaufbau zu einer wiederholbaren Aufgabe statt zu einer Debugging-Sitzung. Er sagt dem nächsten Ingenieur auch, welche Befehlsausgabe zuerst zu sammeln ist.