ASA : port VPN et PAT statique DMZ sur une seule IP publique

Deux services, une adresse publique et un nom DNS qui donne l'impression de réserver un port. Il ne le fait pas. Avant de publier un serveur DMZ à côté de l'entrée VPN sur un ASA, notez les tuples d'entrée et vérifiez-les dans l'ordre ; le premier champ qui correspond à un service existant est l'endroit où le plan s'arrête. Tout ce qui suit suppose que le VPN se termine sur l'appliance elle-même, pas sur un serveur interne.

Écrivez les cinq champs avant d'écrire la commande

Pour chaque entrée publique, notez la famille d'adresses, l'adresse publique, le transport, le port public et le propriétaire. Le propriétaire est soit un service local à l'ASA, soit un serveur interne traduit. Deux entrées peuvent partager une adresse et rester des tuples différents, et deux entrées peuvent sembler différentes sur un schéma tout en entrant en collision sur l'appliance.

Gardez une seconde colonne pour le port réel, celui sur lequel le serveur interne écoute vraiment. Le port public et le port réel sont des choix indépendants, et au moment où vous les fusionnez en une seule colonne, vous perdez la capacité de relire votre propre traduction plus tard.

Lisez correctement les positions réelle et mappée

Partez du tuple que vous avez déjà, pas du serveur que vous voulez ajouter. Une répartition illustrative garde l'entrée VPN approuvée sur le TCP 443 public et publie un serveur DMZ HTTPS sur le TCP 8443 public pendant que ce serveur continue d'écouter sur 443 :

Public TCP 443  -> ASA VPN listener
Public TCP 8443 -> DMZ server TCP 443

Dans la commande déployée, le service réel et le service mappé occupent des positions fixes, et les inverser décrit un autre mappage, pas un mappage cassé. C'est la façon la plus courante dont une traduction fonctionnelle devient une énigme : la configuration est valide, elle pointe simplement ailleurs.

Le guide NAT ASA 9.16 de Cisco documente le PAT statique, l'usage de l'adresse d'interface et la signification du port réel par rapport au port mappé. Lisez la section correspondant à la version que vous exécutez réellement ; une commande mémorisée d'une plateforme plus ancienne n'est pas une configuration actuelle complète.

Comptez le transport comme faisant partie de la réservation

TCP 443 et UDP 443 sont des tuples différents, et cette différence ne vous offre pas l'UDP gratuitement. Un VPN peut avoir des listeners TLS et DTLS distincts, et d'autres services configurés peuvent déjà détenir le transport que vous voulez. Inventoriez les listeners effectifs et la politique d'accès au lieu de supposer que la page web constitue toute l'entrée VPN.

Un second nom d'hôte qui résout vers la même adresse ne résout pas non plus une collision au niveau du transport. Le DNS est un mappage nom vers adresse, pas un courtier de ports, et publier un serveur via PAT n'est pas la même opération que déplacer le listener VPN vers un autre port.

Si l'entrée VPN doit réellement bouger, quatre choses changent ensemble : le profil client, l'URL publique, le filtrage en amont et chaque transport utilisé par le déploiement. Faites-les dans une seule fenêtre plutôt qu'une par une. Gardez un chemin de gestion séparé vers l'appliance ouvert avant de toucher au service qui vous sert à l'atteindre. Sans second chemin, le déplacement est un changement dont vous ne pouvez pas revenir depuis l'extérieur.

Vérifiez depuis l'extérieur avec de nouvelles connexions

N'autorisez que l'application DMZ prévue sous la politique d'accès effective, puis vérifiez l'ordre de traduction correspondant, le chemin de retour du serveur et le nom d'hôte du certificat. Le PAT change la destination réseau ; il n'accorde pas l'accès applicatif et ne répare pas un certificat qui nomme un autre hôte.

Testez les deux services avec de nouvelles connexions depuis un hôte externe autorisé : le VPN devrait toujours s'établir, et la requête DMZ devrait atteindre son listener prévu. Une session établie peut conserver un état antérieur, elle ne prouve donc rien sur un mappage modifié il y a une minute.

Bouclez la boucle en mettant à jour l'inventaire des entrées avec ce que vous avez déployé, y compris tout listener que vous avez découvert plutôt que créé. La prochaine personne qui publiera un service sur cette adresse partira de votre tableau, et une ligne erronée y coûte plus qu'une commande erronée ici.