Relais DHCP de l’ASA sur un VPN site à site : un parcours guidé

Le relais fonctionne en trois étapes, et seule celle du milieu traverse le VPN. Un client diffuse sur le segment de l’agence, l’ASA transforme cette diffusion en requête unicast vers le serveur DHCP, et le serveur répond à l’adresse du relais plutôt qu’au client. Parcourez les étapes dans cet ordre, et la plupart des cas « le relais est cassé » se ramènent à une politique manquante ou à une ligne setroute mal lue.

Première étape : activez le relais sur l’interface côté client

Sur l’ASA de l’agence, le relais est une propriété de l’interface tournée vers les clients. Le serveur peut être déclaré globalement avec son interface joignable, ou sous cette interface côté client pour que la table de routage choisisse la sortie. Ces deux formes ne sont pas interchangeables, et copier la mauvaise est le premier endroit où un parcours dérape.

Vérifiez la configuration en cours avant de changer quoi que ce soit : quelle interface a le relais activé, quelle forme de serveur est présente, et si setroute est rattaché à l’interface client. Si l’ASA fait aussi tourner un serveur DHCP pour un autre segment, arrêtez-vous et lisez la liste des restrictions ; serveur et relais ne peuvent pas être activés en même temps sur la même machine.

Le relais place sa propre adresse côté client dans le champ d’adresse de passerelle. C’est cette adresse que le serveur va servir, elle doit donc être joignable depuis le site distant via le tunnel, pas seulement en local.

Deuxième étape : faites passer le trafic généré par l’ASA dans le tunnel

C’est l’étape que les gens sautent. Un VPN site à site basé sur des politiques est généralement construit pour le trafic entre sous-réseaux, et la requête de relais est générée par l’ASA elle-même. Si la liste d’accès du tunnel et la carte cryptographique ne correspondent qu’aux flux d’un hôte de l’agence vers le sous-réseau du serveur, le paquet de relais peut ne jamais entrer dans le tunnel. Vérifiez la liste d’accès dans les deux sens, pas seulement la ligne de l’agence vers le serveur.

Confirmez que le trafic intéressant couvre la source de relais de l’ASA et l’adresse du serveur, et que le sens retour est autorisé aussi. Dans une conception à base de VTI, la décision de routage est plus simple, mais la prise en charge du relais sur VTI est arrivée dans une version précise ; le guide DHCP de l’ASA identifie la 9.14(1), vérifiez donc l’image avant de copier un exemple VTI sur un équipement plus ancien.

Un ping de l’ASA vers le serveur ne prouve pas grand-chose à lui seul. Il peut réussir par un autre chemin, avec une autre adresse source, ou sous une politique que les paquets du relais ne respectent pas.

Troisième étape : lisez la réponse et l’option setroute

La RFC 2131 dit que le serveur envoie sa réponse à l’adresse du champ giaddr lorsque ce champ n’est pas nul. Donc le chemin retour doit router vers l’adresse du relais, et la politique du tunnel doit autoriser le sens serveur vers relais. Si la requête a traversé mais que l’offre n’arrive jamais, c’est ici qu’il faut regarder.

Séparez ensuite deux choses qui se ressemblent. Le mot-clé setroute modifie ou ajoute l’option de routeur par défaut que l’ASA remet au client. Il n’installe pas de route sur l’ASA et ne crée pas de politique VPN. Un client qui obtient une adresse mais n’atteint rien souffre souvent d’un problème de setroute ou de portée, pas de tunnel. Testez-le avec un client sans passerelle statique et regardez quel routeur par défaut apparaît dans l’offre.

Lisez l’offre de bout en bout : adresse offerte, masque, routeur par défaut, DNS et durée du bail. Laissez ensuite le bail se renouveler. Un relais qui fonctionne une fois et échoue au renouvellement a généralement un problème de portée, de bail ou de chemin retour que le premier échange a masqué.

Ce que je vérifie avant de dire que c’est réparé

Partez du client et capturez la diffusion, puis confirmez que l’ASA l’a relayée avec sa propre adresse comme giaddr. Côté distant, confirmez que le serveur a vu cette requête et choisi une portée correspondant à l’agence. De retour dans l’agence, confirmez que le client a accepté l’offre et atteint sa passerelle.

Si une étape est silencieuse, vérifiez la politique ou la route correspondante plutôt que d’ajouter une autre instruction de relais. La configuration du relais est généralement correcte au moment où quelqu’un escalade ; ce qui a changé, c’est la politique du tunnel ou la route retour.

Écrivez les trois étapes dans le journal des changements : interface côté client, politique VPN couvrant le trafic de relais, et route retour du serveur vers giaddr. C’est ce journal qui fait du prochain déploiement d’agence un travail reproductible plutôt qu’une session de débogage. Il indique aussi au prochain ingénieur quelle sortie de commande collecter en premier.