VPN imbriqué : quel tunnel transporte la connexion externe ?

Deux clients VPN actifs en même temps ne produisent pas un tunnel imbriqué ; ils produisent deux tunnels et une dispute sur le routage. Un tunnel imbriqué existe lorsque la connexion du client interne à son propre serveur est elle-même portée par le tunnel externe, et c’est un montage que l’on construit exprès. Bien fait, le serveur interne voit l’adresse du serveur externe ; mal fait, un client se reconnecte silencieusement autour de l’autre. Trois conditions décident si l’imbrication est réelle ou accidentelle.

Trois conditions décident de l’imbrication

La première est quel point de terminaison a besoin de quel chemin. Nommez l’adresse du serveur interne, nommez celle du serveur externe, et affirmez explicitement que le serveur interne n’est joignable que par le tunnel externe. Tout le reste découle de cette phrase, y compris quelles routes vont dans quelle table.

La deuxième est de savoir si vous pouvez voir le chemin à chaque couche. Si vous ne pouvez pas demander au noyau quelle route une destination donnée emprunterait, vous déduisez la chaîne d’une IP de sortie finale, et c’est exactement la preuve qui ne peut pas distinguer une imbrication d’une coïncidence.

La troisième est ce qui se passe quand le tunnel externe tombe. Le tunnel interne peut s’arrêter avec lui, se reconnecter par le réseau ordinaire ou rester bloqué jusqu’au retour du chemin externe, et les trois sont des politiques défendables. Ce ne sont pas la même politique, et le comportement par défaut de la plupart des clients est le deuxième. Un client qui reconnecte son point de terminaison par le réseau physique tout en affichant une connexion saine est la façon la plus courante dont une chaîne voulue devient discrètement deux tunnels sans rapport.

Première condition : quel point de terminaison a besoin de quel chemin

ip route get 203.0.113.10 répond directement à cette question : la commande affiche la route, l’adresse source et l’interface que le noyau utiliserait pour cette destination à cet instant.

Exécutez-la pour le serveur interne avant le démarrage du client interne puis de nouveau après, et comparez. Si la réponse passe de l’interface physique à l’interface du tunnel externe, l’imbrication est réelle à cet instant. Si elle ne change pas, le client interne se connecte directement, quoi qu’affiche le tableau de bord. Répétez pour l’adresse du serveur externe, qui doit toujours se résoudre par l’interface physique, car une route qui capture les deux points de terminaison de façon récursive est la panne qui coupe complètement la machine du réseau.

Deuxième condition : inspecter le chemin à chaque couche

La sélection de route dépasse la table principale sur un client moderne. Des règles de politique peuvent envoyer des paquets marqués vers une autre table, un client peut lier sa socket à une interface, et un conteneur ou un namespace a ses propres tables. ip rule et ip route show table all sont le moyen de savoir lequel de ces mécanismes est en jeu.

Un client qui pose SO_MARK sur sa propre socket, ou qui est configuré pour se lier à un périphérique précis, contourne la route par défaut que vous croyiez avoir mise en place. C’est une fonctionnalité et non un défaut, et cela signifie que la seule vérification fiable est celle qui s’exécute dans le même namespace que le client. Si les clients tournent dans des conteneurs, lancez les vérifications dans ces conteneurs plutôt que sur l’hôte.

Troisième condition : ce qui se passe quand le tunnel externe tombe

Le comportement en cas de panne demande une décision, pas un défaut. Écrivez ce qui doit arriver au tunnel interne quand l’externe disparaît, puis faites en sorte que les clients appliquent cela.

Les options sont concrètes. Arrêter le client interne quand le chemin externe disparaît donne une chaîne propre et une panne évidente. Le laisser se reconnecter directement donne de la disponibilité et retire silencieusement la propriété pour laquelle la chaîne a été construite. Bloquer jusqu’au retour du chemin externe est la plus stricte et la plus pénible à exploiter, car chaque oscillation du tunnel externe devient un incident visible.

Testez les trois avec du trafic inoffensif et une panne provoquée du tunnel externe, car lire la configuration ne vous dira pas laquelle vous avez. Coupez le tunnel externe, observez ce que fait le client interne et vérifiez la route pendant qu’il est coupé. Ramenez ensuite le tunnel externe et confirmez que la chaîne se reforme au lieu de laisser le client interne sur le chemin direct qu’il a choisi entre-temps.

Ce que la chaîne ne vous donne pas

Les couches supplémentaires ajoutent des points de terminaison, des clés et des modes de panne ; elles n’ajoutent aucune garantie d’anonymat et elles n’empêchent pas l’opérateur externe de voir qu’un tunnel existe. Toute affirmation sur ce que protège l’imbrication doit nommer l’observateur contre lequel elle protège.

Le livrable est un court document plutôt qu’une connexion qui fonctionne : quel point de terminaison utilise quel chemin, ce qui se passe en cas de panne externe, et les trois commandes qui montrent l’état actuel. La documentation de strongSwan sur le forwarding est une référence utile pour la façon dont le trafic de tunnel est transmis entre interfaces sur un hôte Linux. Relancez les vérifications après chaque mise à jour de client, car les valeurs par défaut qui ont produit votre chaîne ne sont pas un contrat. Un tunnel imbriqué que vous ne pouvez pas inspecter est une rumeur avec un voyant d’état.