Publier un service interne via un VPN site à site ASA

Publier un service qui vit derrière un VPN site à site est une seule tâche avec cinq points de défaillance, et ils échouent dans un ordre fixe. Le tunnel monte, la traduction correspond, l’agence répond et la réponse revient par le même chemin. Quand l’un de ces points est faux, le navigateur affiche la même chose : une connexion qui reste en attente ou qui est réinitialisée. Parcourez la liste de haut en bas et arrêtez-vous à la première vérification qui échoue.

Vérification 1 : le tunnel protège l’adresse d’origine

Partez d’un tunnel qui transporte déjà du trafic, puis confirmez que l’adresse que vous comptez publier se trouve dans la plage protégée. Sur un ASA, cette plage vient de l’ACL de chiffrement ou des routes d’un VTI, et elle doit couvrir l’adresse réelle de l’origine, pas le sous-réseau que l’agence utilise pour l’administration. Un sélecteur qui manque l’origine vous donne un tunnel monté et un flux qui n’y entre jamais.

Confirmez-le avec les compteurs du tunnel et la table de routage avant de toucher à la traduction. Si l’origine n’est pas joignable depuis le concentrateur à travers le tunnel, rien plus loin dans cette liste ne peut le réparer.

Arrêtez-vous ici si la plage protégée et l’adresse d’origine ne concordent pas.

Vérification 2 : décidez quelle source l’agence verra

L’agence voit soit l’adresse d’origine du client, soit une adresse traduite, et ce choix décide du chemin de retour. Conserver l’adresse du client se lit plus proprement dans les journaux de l’origine, mais l’agence doit alors renvoyer les réponses destinées aux clients publics par le tunnel ; une route par défaut internet ordinaire les envoie dans l’autre sens et la connexion meurt dans une direction. Traduire la source vers une adresse que l’agence route déjà par le tunnel supprime cette exigence.

La traduction change aussi ce que l’origine peut journaliser et ce à quoi les règles fondées sur la source peuvent correspondre. Si l’application a besoin de connaître la personne derrière une requête, cela relève d’un proxy inverse authentifié, pas d’une décision de NAT.

Vérification 3 : écrivez la traduction en fonction des interfaces réelles

Un ASA évalue les règles de traduction dans l’ordre et indique laquelle a correspondu, donc la paire d’interfaces dans la règle n’est pas cosmétique. Une règle écrite pour un chemin de l’extérieur vers l’intérieur ne correspondra pas à un flux dont l’entrée et la sortie diffèrent de celles que vous avez supposées.

Le chemin que vous construisez a quatre segments, et les quatre doivent concorder :

Considérez les plages de ce tableau comme des espaces réservés. L’important est que le tuple après traduction soit une adresse que l’agence accepte par le tunnel, et que le mappage inverse existe dans l’état NAT pour que la réponse soit restaurée à la sortie.

Vérification 4 : limitez la règle d’accès au port publié

Publiez le port, pas l’hôte. Une règle qui autorise l’origine sur tous les services transforme une application publiée en chemin vers tout ce que l’origine exécute, y compris l’interface d’administration que vous avez volontairement gardée hors d’internet. Autorisez le port publié depuis la source traduite vers l’origine, et laissez les services administratifs sur leur chemin réservé au VPN.

Vérifiez l’ordre des règles en même temps. Une autorisation large placée au-dessus de votre règle spécifique rend la règle spécifique invisible.

Vérification 5 : tracez une requête et sa réponse

Ne commencez pas par un navigateur, car un navigateur cache quel segment a échoué. Tracez le flux sur le concentrateur et lisez le résultat avant de changer quoi que ce soit.

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

La trace nomme la traduction qui a correspondu, la règle d’accès qui a autorisé ou refusé le flux, et si le paquet a été routé dans le tunnel. Si elle montre le flux sortant par une interface que vous n’attendiez pas, la paire d’interfaces de la règle NAT est fausse. Si elle montre un refus, l’ordre des règles est faux. S’il atteint le tunnel mais que l’origine ne répond jamais, le problème est le chemin de retour de l’agence.

Envoyez ensuite une vraie requête depuis l’extérieur et confirmez que la réponse revient par le même tunnel. Consignez l’entrée publiée, la traduction, la paire d’adresses protégée et la route de retour comme registre de publication.