ASA VPN hairpin : router deux tunnels par une seule interface

Un utilisateur distant se connecte à l'ASA, demande un hôte derrière une agence, et l'ASA envoie cette requête par l'interface même par laquelle l'utilisateur est arrivé. Rien de tout cela n'exige un second port physique. Ce que cela exige, ce sont quatre décisions indépendantes que les gens ont tendance à fondre en une : l'autorisation de faire du hairpin, un tunnel qui protège les bonnes adresses, une politique NAT qui conserve la source que vous avez promise et une politique d'accès qui autorise le service.

Un paquet, deux tunnels

Suivez le flux et l'ordre des opérations cesse d'être mystérieux. Le paquet arrive dans le tunnel d'accès distant, est déchiffré et devient un paquet IP ordinaire dont la source provient du pool de clients. L'ASA le route ensuite, le compare à l'ACL de chiffrement de site à site, le chiffre de nouveau et l'envoie par l'interface extérieure vers l'agence.

Les adresses ci-dessous sont illustratives, mais la forme compte : la source est le pool, pas le LAN interne de l'ASA.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

Deux choses en découlent. Le client a besoin d'une route pour le préfixe de l'agence via sa connexion d'accès distant, ce qui signifie que le split-tunnel ou la liste de routes poussée doit l'inclure. Et l'agence doit savoir comment renvoyer le trafic vers 10.77.0.20 ou vers l'adresse que votre conception NAT a substituée.

L'autorisation hairpin est globale

La commande vers laquelle on se tourne est same-security-traffic permit intra-interface. Elle permet au trafic d'entrer et de sortir par la même interface, ce qui est exactement ce dont ce chemin a besoin. C'est aussi un réglage global : l'activer change le comportement d'autres flux qui traversent accidentellement deux fois la même interface.

C'est pourquoi elle relève d'un registre de changement plutôt que d'une session de débogage. Demandez ce qui d'autre sur l'équipement pourrait désormais emprunter un chemin par la même interface, et si quelque chose devrait le faire. Sur un bord chargé avec des réseaux invités ou des tunnels partenaires qui se chevauchent, la réponse n'est pas automatiquement non. Écrivez la raison à côté du réglage, car le prochain ingénieur trouvera la commande et non la conversation.

Portée de protection et NAT sont distincts

Le tunnel de site à site protège ce que sélectionne son ACL de chiffrement. Si cette ACL désigne le sous-réseau interne de l'ASA comme source, le pool d'accès distant n'est pas protégé et le paquet sera soit rejeté, soit envoyé en clair, selon le comportement de la plateforme face au trafic non correspondant. Ajoutez le pool au flux protégé lorsque la conception conserve les adresses du pool.

Le NAT décide ensuite si l'adresse du pool survit. L'Identity NAT la conserve, et l'agence voit 10.77.0.20 comme source. La traduction change le contrat : l'agence renvoie désormais le trafic vers l'adresse traduite, et sa propre politique doit l'accepter. L'ordre des règles détermine si l'ACL de chiffrement correspond avant ou après la traduction, alors lisez le flux effectif au lieu de supposer laquelle l'emporte.

Ne supprimez pas les règles PAT générales d'internet pour faire fonctionner un seul cas de transit. Une exemption ciblée ou une règle d'identité délibérée est plus facile à expliquer et à annuler qu'un trou dans la politique sortante.

Le chiffrement n'est pas une autorisation

Un tunnel qui fonctionne prouve seulement que deux pairs s'accordent sur les clés et les sélecteurs. Il ne dit rien sur la question de savoir si cet utilisateur peut atteindre ce service. Le filtre VPN ou la politique de groupe attachés à la connexion d'accès distant doivent toujours autoriser la destination et le port de l'agence, et l'ACL d'interface sur le chemin extérieur s'applique toujours.

Testez la réponse dans les deux sens. Une connexion qui réussit alors qu'un service voisin devrait échouer est plus instructive qu'un seul ping réussi, car elle montre que la politique est sélective et non grande ouverte. Si le test censé être refusé réussit, ce n'est pas le tunnel qu'il faut blâmer, mais la politique. Conservez les deux résultats dans le registre de changement afin que la personne suivante sache quel comportement était voulu.

Hairpin ou une seconde interface

Le transit hairpin garde la conception compacte et coûte un réglage global. Une interface séparée, ou un tunnel basé sur le routage avec sa propre interface virtuelle, isole le chemin de transit et vous donne une politique par interface, au prix de l'adressage et d'une autre carte de chiffrement ou d'un autre profil. Aucune n'est plus correcte ; elles échouent différemment.

Les conceptions basées sur le routage sont un autre agencement, pas une case à cocher dans la même configuration. Si vous en adoptez une, la discussion ci-dessus sur l'ACL de chiffrement basée sur des politiques cesse de s'appliquer et la table de routage commence à faire le travail de sélection.

Vérifiez depuis le vrai client

Une sonde lancée depuis l'ASA a une adresse source différente et n'exercera pas le chemin du pool vers l'agence. Utilisez packet-tracer pour vérifier le quintuplet, puis ouvrez une véritable connexion depuis le client distant réel, car le traceur simule et ne remplace pas le routage et la politique propres au client.

Après un changement planifié, connectez-vous à un service qui devrait fonctionner, puis à un autre qui devrait être refusé, et confirmez ensuite la route de retour de l'agence. Les les exemples de NAT hairpin VPN de Cisco gardent l'autorisation intra-interface, le NAT et les ACL visiblement séparés, et c'est le modèle mental qu'il vaut la peine de copier.