Même IP de serveur, deux chemins : marquer le flux externe d'OpenVPN

La protection de boucle habituelle est une route d'hôte : envoyez le trafic vers l'adresse publique du serveur VPN par le lien montant afin que la session chiffrée n'entre jamais dans son propre tunnel. Cela fonctionne jusqu'au moment où vous voulez aussi atteindre un service web sur ce même serveur à travers le tunnel, car l'exemption est liée à la destination et la destination est identique. La sortie consiste à cesser de classer par destination et à commencer à classer selon la socket qui a envoyé le paquet.

Commencez par les deux flux que vous voulez séparer

Un flux est le transport OpenVPN chiffré lui-même, qui doit sortir par le lien montant, sinon le tunnel porterait sa propre connexion externe. L'autre est une requête HTTPS ordinaire vers la même adresse publique, que vous voulez à l'intérieur du tunnel pour qu'elle arrive au service depuis une source de tunnel. Même destination, souvent même numéro de port, chemin requis différent.

Pour ce parcours, supposez un client sur 10.90.0.10 via tun1, une adresse publique de serveur de 198.51.100.25 et une table principale intacte dont la route par défaut pointe vers le lien montant ordinaire. Le côté serveur doit aussi accepter le service web sur le chemin interne et renvoyer le trafic vers la source du tunnel ; envoyer un paquet vers une adresse publique ne contourne ni l'écouteur ni la politique de pare-feu du serveur.

Avant de changer quoi que ce soit, relevez les règles actuelles de l'hôte et choisissez des valeurs que personne d'autre n'utilise : une marque, un numéro de table et trois priorités de règle. Gardez un chemin de retour vers la machine qui ne passe pas par cette connexion, car une erreur ici supprime votre propre accès distant au lieu de seulement casser un onglet du navigateur.

Marquez la socket qui porte l'enveloppe

La configuration du client gagne une marque pour ses paquets chiffrés sortants, et cesse d'installer des routes elle-même afin que la politique de remplacement soit la seule à décider des chemins :

mark 42
route-noexec
disable-dco

Le décimal 42 est l'hexadécimal 0x2a, et c'est la forme hexadécimale que les règles de routage vont faire correspondre. La référence des link-options décrit mark comme s'appliquant aux paquets chiffrés sortants sous Linux, soit exactement la socket dont vous devez contrôler le chemin. Désactiver l'offload du canal de données maintient cet exemple sur le chemin de l'espace utilisateur, où le comportement de la marque est celui décrit.

route-noexec supprime les ajouts et retraits automatiques de routes d'OpenVPN. Il n'installe rien à leur place, donc à partir de ce moment le propriétaire des routes doit maintenir chaque route dont le tunnel a besoin. Si une destination privée disparaît après le changement, c'est la politique de remplacement manquante, pas un défaut de la marque.

Ne conservez pas de route d'hôte dans la table principale pour 198.51.100.25 pendant cette opération. Une telle route réintroduit exactement l'exemption que la conception cherche à restreindre, et elle gagnera pour le flux HTTPS avant que l'une des politiques ci-dessous ne soit consultée.

Envoyez tout le reste vers la table du tunnel

Une fois l'interface du tunnel créée et son adresse en place, la politique ressemble à ceci :

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

La première règle garde visibles les routes spécifiques de l'hôte, y compris tout réseau local approuvé, tout en rendant invisible la route par défaut de la table principale pour cette recherche. Cette distinction compte : supprimer la route par défaut n'est pas la même chose qu'ignorer la table, et les exceptions locales dont vous avez encore besoin survivent précisément grâce à elle. Lisez ces exceptions une par une au lieu de supposer que le résultat est un interrupteur d'arrêt universel.

Le trafic non marqué retombe alors sur la table du tunnel, prend la source du tunnel et sort par le VPN. Le trafic marqué échoue au test fwmark sur les deux règles suivantes et continue vers la recherche principale ordinaire plus bas dans la liste, où la route par défaut du lien montant se trouve toujours. La règle unreachable finale est ce qui empêche un flux non marqué de retomber discrètement sur le lien montant lorsque la route du tunnel manque. Le sélecteur est la marque du début à la fin, et l'adresse de destination n'entre jamais dans la décision.

Maintenez ce garde-fou en place entre les déconnexions, et installez-le avec le reste de la politique plutôt qu'à la main. Une règle qui disparaît avec l'interface n'est pas une politique, c'est une coïncidence. Supprimer la politique quand le tunnel tombe change le mode de défaillance de « bloqué » à « fuité », et une route de tunnel obsolète qui expire plus tard est un problème bien plus facile à expliquer que du trafic sorti par la mauvaise interface.

Faites voir la même marque au chemin de retour

Les marques sortantes ne sont que la moitié du mécanisme, et c'est la partie que la plupart des reproductions omettent. Les réponses à la session chiffrée arrivent par le lien montant et sont soumises à la validation du chemin de retour, qui demande si la source serait routée en retour par le même chemin. Sans aide, cette recherche applique votre politique de tunnel non marquée et conclut que le paquet est sur la mauvaise interface.

Le correctif appartient au propriétaire du pare-feu : enregistrez la marque sur la connexion sortante, restaurez-la sur les paquets entrants correspondants et activez la gestion des marques validée par la source pour le chemin concerné. Qu'OpenVPN pose une marque de socket ne fait aucune de ces trois choses, et une recette qui ne liste que les options du client est incomplète. Demandez cette intégration par écrit, car c'est la partie la moins visible de la conception et la plus facile à perdre lors d'une reconstruction.

La vérification laxiste du chemin de retour n'est pas non plus un substitut. Le mode laxiste exige encore qu'une route existe pour la source, et le garde-fou unreachable que vous avez ajouté en retire délibérément une pour les recherches non marquées. Faites terminer et relire l'intégration de la marque de connexion avant de vous appuyer sur cette conception, et traitez les filtres d'hôte comme une question distincte : une marque est un signal de routage, pas une autorisation. Si l'intégration manque, le symptôme est une session qui s'établit puis devient silencieuse dès que les réponses commencent à arriver.

Prouvez-le avec deux recherches de route

Comparez ce que le noyau décide pour les deux contextes, et lisez les champs dev et src plutôt que le code de sortie :

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

La première recherche devrait résoudre vers tun1 avec la source du tunnel, et la seconde vers le lien montant. Ce sont des recherches synthétiques, elles prouvent donc la politique et non le processus actif : confirmez séparément le chemin de transport réel du client en cours d'exécution, puis faites une vraie requête HTTPS avec la vérification des certificats activée.

Notez ce que la conception ne couvre pas avant de la déclarer terminée. DNS, IPv6 et le cycle de vie des règles demandent chacun leur propre décision, et ceci est un exemple de routage IPv4 plutôt qu'une configuration de confidentialité complète. Sa valeur est le sélecteur : l'enveloppe obtient l'exemption du lien montant, et un service ordinaire à la même adresse n'a pas à en hériter.