Après le déchiffrement : quelle politique voit d’abord votre trafic VPN

Un flux VPN peut être parfaitement chiffré et parfaitement authentifié et aboutir malgré tout là où personne ne l’avait prévu. Le câble que vous branchez ne détermine pas quelle règle traite le paquet interne ; ce sont le crochet de politique et la route qui le font. Deux conceptions identiques sur un schéma de baie peuvent donc avoir une application totalement différente. Choisir entre elles commence par nommer le contrôle qui voit le flux déchiffré en premier.

Décidez par le crochet de politique, pas par le port

Chaque plateforme VPN évalue le trafic déchiffré à un moment donné avant de le transmettre, et ce point porte un nom dans la configuration. Sur une plateforme c’est un filtre de politique de groupe, sur une autre une politique d’interface ou une paire de zones, et sur un équipement qui route ce peut être simplement la chaîne forward. Le crochet applique la règle, tandis que le port du commutateur n’est que l’endroit où le câble se termine. Trouver le crochet est la première décision, car tout le reste est un placement par rapport à lui.

Avant de regarder le matériel, écrivez le flux : qui est la source, où il va, quel protocole le transporte et quel service est autorisé. Trouvez ensuite le contrôle qui applique chacun de ces quatre faits.

Deux chemins, deux histoires d’application

Deux formes sont courantes, et chacune peut être correcte pour une exigence différente.

endpoint -> shared inside subnet -> server
endpoint -> dedicated transit -> policy firewall -> server subnet

La première forme peut appliquer tout ce qu’il faut sur la passerelle, à condition que la politique soit écrite pour cette destination et que le serveur n’ait pas de chemin qui la contourne. La seconde ajoute une frontière, mais seulement si les routes et la politique font réellement traverser celle-ci au trafic. Un serveur sur le même segment que le point de terminaison peut ne jamais suivre le saut intermédiaire imaginé. Le schéma montre l’intention, la table de routage montre ce qui se passe.

Vérifiez par une recherche de route plutôt que par le dessin. L’interface par laquelle un paquet sort et le saut suivant qu’il choisit décident si la seconde forme se comporte comme prévu.

ip route get 10.30.7.20
sudo iptables -S FORWARD
sudo tcpdump -ni inside0 host 10.30.7.20

Séparez la topologie de l’isolation

Partager un sous-réseau ne rend pas un endroit non fiable, et un transit dédié ne le rend pas protégé. Ce qui décide, c’est la restriction réellement appliquée, le transfert qui a réellement lieu et qui administre chaque pièce. Compter les commutateurs ne dit rien de ces trois points. Décidez à partir de la politique et de la route, puis laissez la topologie suivre la décision.

Traitez aussi les populations de trafic séparément. Les pools d’accès distant, les préfixes site à site et les réseaux de lignes privées peuvent partager un équipement et néanmoins exiger des règles différentes, car leur identité et leur risque diffèrent. Une règle écrite pour une population couvre silencieusement les autres lorsqu’elles partagent un plan d’adressage.

Vérifiez la panne et l’administration de chaque emplacement

Chaque emplacement a un mode de panne, et la question utile est ce qui fonctionne encore lorsqu’un composant s’arrête. Plusieurs interfaces logiques sur un seul équipement mort ne donnent aucune reprise indépendante, et un pare-feu en aval partageant la même alimentation ou le même administrateur n’est pas une seconde frontière. Demandez où passe le chemin d’administration, car une console joignable uniquement par le tunnel n’est pas du tout un chemin de reprise ; ssh [email protected] true depuis l’extérieur du tunnel est le moyen le moins coûteux de prouver que la console n’en dépend pas. La documentation de politique de groupe d’une plateforme place son filtre sur le trafic après déchiffrement et avant chiffrement, ce qui est exactement le type de crochet nommé à rechercher dans tout produit.

Écrivez l’histoire de panne de chaque candidat à côté de l’histoire d’application. Un emplacement qui gagne à l’inspection et perd à la reprise est un compromis, et il doit être consigné comme tel plutôt que découvert lors d’un incident.

Acceptez avec un flux autorisé et un flux refusé

Avec un plan de test approuvé, vérifiez trois choses depuis la véritable source VPN : une application qui doit fonctionner, une ressource qui ne doit pas, et la direction par laquelle la réponse revient. Le refus est la preuve que la politique est engagée, tandis que le flux autorisé prouve seulement qu’un chemin existe.

Conservez le chemin choisi et le résultat de la politique ensemble, car un résultat sans chemin ne peut être reproduit et un chemin sans résultat ne peut être défendu. Cette paire est bien plus utile pour choisir un point de rattachement que toute affirmation sur la couche de commutation intrinsèquement plus sûre.