Sous-réseau aval vs VPN de bureau : exclure le transit, pas les applications

Une machine, deux métiers, un pare-feu : un lien montant Wi-Fi, un petit sous-réseau Ethernet derrière, et un client VPN de bureau qui suppose que tout ce qui sort de la machine est local. Les applications lancées localement sortent par le chemin de sortie local. Les appareils derrière le poste de travail arrivent sur le port Ethernet et ont besoin d'une décision de transfert. Une exclusion écrite pour le premier chemin ne voit jamais le second, et c'est pourquoi un navigateur contourne le tunnel alors que les appareils ne le font pas.

Deux chemins de paquets, une politique

La première ligne est ce que décrivent la plupart des guides de split tunneling. La seconde est une configuration de routeur qui se trouve par hasard sur la même machine. Les fusionner en un seul modèle mental est l'erreur ; ils partagent un noyau, pas une politique. Dessinez les deux chemins avant de modifier la moindre règle, et le reste de la conception découle de celui qui manque.

Le tableau explique aussi pourquoi une machine peut réussir un test et échouer à un autre. Le navigateur du poste de travail prouve le chemin local ; un portable branché sur le port Ethernet prouve le chemin de transfert. Validez chaque changement avec les deux, sinon le second reste non testé, quel que soit le nombre de rechargements du navigateur.

Ce qu'une exclusion d'application classe réellement

Une exclusion par application fonctionne généralement en marquant les paquets d'un processus ou d'un utilisateur, puis en routant le trafic marqué hors du tunnel. C'est une construction de sortie locale. Un paquet d'un appareil en aval n'a pas de processus local, il ne correspond donc jamais au sélecteur, quel que soit ce sélecteur.

Quel que soit le sélecteur, les deux listes ne sont pas la même liste, et c'est tout l'enjeu. Le guide Mullvad pour Linux décrit des marques consommées par son pare-feu et sa politique de routage, et ses exemples visent la sortie locale ; ils ne constituent pas une description prise en charge d'un routeur en aval. Les copier produit une machine qui croit avoir une exclusion tout en transférant tout dans le tunnel.

Rédiger le contrat de transit

Nommez ensemble le préfixe source en aval et l'interface d'entrée, puis restreignez ce préfixe à l'entrée. Sans la restriction, tout appareil qui atteint le port peut revendiquer une adresse exclue et sortir par le contournement. Traitez cela comme deux questions : ces hôtes peuvent-ils utiliser ce lien montant, et peuvent-ils atteindre le poste de travail ou les plages privées du tunnel ? Ce sont des autorisations supplémentaires, pas des effets de bord du choix du lien.

Autorisez le transfert, puis filtrez-le. La passerelle Linux a besoin du transfert activé, de règles autorisant le trafic prévu dans les deux sens, et soit d'une route de retour amont, soit d'une traduction de source volontairement limitée. NAT seul ne sélectionne pas le lien montant et n'accorde pas le passage à travers un filtre ; il ne réécrit une adresse qu'après ces décisions.

Le classement pour le transit doit avoir lieu avant la décision de route de transfert, c'est-à-dire à l'étape prerouting et non output. Une règle placée après la décision peut encore modifier le paquet, mais pas changer où il a déjà été envoyé.

Les marques appartiennent à l'application qui les possède

Les valeurs de marque, les numéros de table et les priorités de chaîne font partie de la politique de l'application VPN, ce ne sont pas des constantes éternelles. Un réseau durable qui dépend de l'insertion d'une règle dans une table qu'un autre programme régénère cassera à la prochaine mise à jour, généralement pendant une reconnexion et non au moment opportun.

Ajouter une seconde chaîne de base avec un verdict accept ne supplante pas forcément le drop d'une chaîne ultérieure. Les chaînes de base ont des hooks et des priorités, et le premier verdict dans l'ordre gagne ; un accept dans une chaîne n'annule pas un drop qu'une autre chaîne atteint d'abord. Regardez l'ensemble complet des règles et l'ordre de la politique de routage, pas le seul compteur qui a augmenté. Un compteur prouve qu'une règle s'est exécutée, jamais que son verdict est celui qui a été appliqué.

Intégrer, ou déplacer le sous-réseau

Les deux conceptions diffèrent par qui possède le contournement. Une conception intégrée garde une machine et une politique, au prix d'une dépendance au cycle de vie des tables de l'application VPN et à un ensemble de marques que sa documentation peut changer. Un routeur dédié pour le réseau aval supprime entièrement cette dépendance : le sous-réseau a son propre lien montant et le poste de travail reste un client sans rôle de transfert.

Choisissez la seconde quand le réseau aval doit continuer à fonctionner à travers les mises à jour du VPN, ou quand personne ne peut tester la politique intégrée après chaque version. Choisissez la première seulement quand l'intégration est documentée et que quelqu'un en est responsable.

Vérifiez la frontière dans quatre états : connecté, reconnexion, bloqué volontairement et arrêté. Contrôlez la résolution de noms et les deux familles d'adresses dans chacun, car un contournement qui fuit le DNS n'est pas l'exclusion que vous avez conçue. Le test doit prouver la frontière précise, pas seulement qu'une page s'est chargée.