Trafic client VPN et état du pare-feu : flux externe ou interne

La poignée de main VPN aboutit, le client obtient une adresse, et un service derrière la passerelle refuse toujours la connexion. Le pare-feu fait souvent exactement ce qu’on lui a dit. Il a autorisé le flux externe du tunnel, qui est un paquet différent de la connexion applicative décapsulée. Deux décisions s’ensuivent : quel flux vous autorisez, et si la frontière suit l’état du tout.

Tant que vous ne séparez pas ces deux choses, chaque changement de règle est une conjecture.

Le pare-feu voit deux paquets différents

Avant la décapsulation, le pare-feu voit le trafic adressé au point de terminaison VPN : un flux UDP externe vers l’écouteur. Après la décapsulation, un paquet transféré porte l’adresse interne du client et la destination du service.

Une autorisation pour le flux externe n’autorise pas la connexion TCP transférée. Elles peuvent être évaluées dans des chaînes différentes, sur des interfaces différentes et avec des adresses différentes après traduction.

Comparez des captures prises à des positions équivalentes des deux côtés. Une capture en bordure de tunnel et une capture sur le serveur montrent des tuples différents pour la même session.

Première décision : autoriser le tunnel ou le service

Si le client n’a besoin que du point de terminaison VPN lui-même, l’autorisation externe peut suffire. S’il a besoin d’un service au-delà de la passerelle, il vous faut une autorisation de transfert pour cette destination et ce port. Une règle de tunnel qui autorise aussi le service est un choix de conception que vous devriez nommer, pas un accident.

Gardez la plage client et la portée du service étroites. Une autorisation du sous-réseau du tunnel vers tout le réseau local est une décision de faire confiance à chaque hôte, pas un raccourci pour une application.

Écrivez les deux règles séparément. La règle du tunnel et la règle du service échouent de manières différentes et se diagnostiquent avec des preuves différentes. Quand l’une échoue, vous savez quelle couche inspecter en premier.

Deuxième décision : avec ou sans état à chaque frontière

Une règle de flux établi peut admettre les réponses d’un échange autorisé, mais son comportement dépend du produit. Un groupe de sécurité cloud tient généralement l’état ; une liste de contrôle de sous-réseau ne le tient souvent pas et exige un traitement explicite dans les deux sens. Ne supposez pas que chaque frontière du chemin traite l’état de la même façon. Listez chaque frontière et marquez-la avec ou sans suivi d’état avant de concevoir les règles.

Si une règle change, les flux suivis existants peuvent continuer de fonctionner alors que les nouveaux échouent, ou l’inverse. Cette différence est un indice utile, pas une raison de vider tout l’état des connexions sur une passerelle en production.

Testez avec une requête neuve et contrôlée et inspectez les compteurs pertinents. Un test propre vaut mieux qu’une réinitialisation perturbatrice. Notez le nom du compteur dans le journal des changements pour que le test suivant utilise la même preuve.

Vérifiez le chemin de retour sous la même politique

Envoyez une nouvelle requête du client vers le service, puis vérifiez les compteurs d’aller et de retour à chaque frontière. Confirmez que la réponse emprunte le chemin attendu, surtout si une traduction intervient.

Gardez la plage client prévue et la portée du service étroites, et vérifiez le chemin de retour sous le même jeu de règles qui a autorisé la requête. Une règle qui ne fonctionne que parce qu’un ancien flux est encore ouvert n’est pas une règle qui fonctionne.