Router un compte Linux via OpenVPN avec une règle UID

Le routage par compte convient lorsque chaque socket IPv4 détenu par un utilisateur Linux doit sortir par un tunnel existant, et il ne convient pas lorsque vous avez besoin d’une isolation au niveau du programme. Il sélectionne par UID, donc tout ce qui s’exécute sous ce compte entre dans le périmètre, y compris la tâche batch que vous avez oubliée. Tranchez cette question avant de toucher une seule ip rule.

L’exemple ci-dessous suppose un compte de navigateur dédié à l’UID 1500, un périphérique de tunnel tun-office portant l’adresse locale 10.80.0.11, et un VPN qui autorise les destinations en question. Le démon lui-même s’exécute en dehors de cet UID.

Trois conditions qui choisissent le mécanisme

Choisissez une règle UID lorsque l’identité qui fait le travail est le compte, lorsque déplacer tout son trafic est acceptable et lorsqu’un namespace serait plus lourd que la tâche ne le mérite. Choisissez un namespace réseau lorsque la charge de travail a besoin de ses propres interfaces, résolveur et table de routage. Choisissez un proxy ou une liaison par processus lorsqu’exactement une application doit bouger pendant que le reste de la session reste sur le chemin local. Écrire ces trois points évite une règle qui couvre silencieusement plus que prévu.

L’erreur à éviter est de supposer qu’un lanceur définit le propriétaire. Un navigateur auquel la session d’un autre utilisateur a passé une URL n’a pas créé de sockets sous l’UID 1500, et aucune règle ne déplacera le trafic qu’il génère.

La table, la règle et le garde-fou

Après avoir vérifié les règles existantes et choisi des numéros de table et de priorité inutilisés, la disposition est courte : une route par défaut dans une table dédiée portant l’adresse source du tunnel, une règle qui envoie les recherches du compte vers cette table, et une règle terminale qui bloque le repli. Écrit, cela donne un remplacement de route idempotent, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, suivi de ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

Le garde-fou est ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, et il compte plus que sa longueur ne le suggère. Sans lui, une route manquante dans la table 51820 retombe sur le lien montant ordinaire et le compte fuit silencieusement le trafic que la politique devait capturer. Avec lui, la même défaillance devient un délai d’attente, donc un blocage plutôt qu’un repli.

Gardez la règle normale d’adresse locale devant celles-ci, et décidez consciemment si les exceptions LAN ou d’administration vont avant la table sélectionnée. Une route par défaut trouvée là ne consulte pas ensuite main pour une route LAN plus spécifique, ce qui surprend ceux qui attendent que la correspondance du plus long préfixe s’applique entre tables. Écrivez la liste d’exceptions prévue dans la note de changement pendant que le raisonnement est encore frais.

Ce que le routage par UID laisse de côté : le DNS

Le démon résolveur ouvre ses sockets amont sous son propre UID, donc sélectionner 1500 ne déplace pas ces requêtes dans la table 51820. L’intégration DNS est une décision distincte : pointez le compte vers un résolveur joignable par le tunnel, ou acceptez que la résolution de noms suive le chemin de l’hôte alors que le trafic non.

Une requête en loopback vers un stub local ne prouve pas que la requête amont a utilisé la route du navigateur, et un chargement de page réussi depuis le cache non plus.

IPv6 mérite sa propre phrase dans la conception

Les règles ci-dessus ne couvrent qu’IPv4. Si l’exigence est un tunnel IPv4 sans IPv6 direct depuis ce compte, ajoutez une règle terminale revue comme ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, puis vérifiez les règles IPv6 antérieures ainsi que les exceptions loopback que vous voulez conserver.

Bloquer IPv6 direct n’est pas du tunnel double pile ; c’est une frontière. L’appeler tunnel brouillera la personne suivante qui lira la politique, et la confusion remontera sous forme de ticket d’assistance sur un site IPv6 cassé.

Vérifiez avec le vrai compte, puis assumez le cycle de vie

Comparez les recherches : ip -4 route get 198.51.100.25 uid 1500 contre la même destination avec un UID ordinaire. Faites ensuite une requête autorisée sous le compte dédié et vérifiez l’adresse source que voit l’extrémité distante. Une adresse source préférée n’est pas du source NAT, et elle ne supplantera pas une application qui lie autre chose. Si les deux recherches renvoient le même chemin, la règle ne fait pas ce que vous croyez.

Gardez la table, les règles et la durée de vie de la route du tunnel sous un seul propriétaire, testez une reconnexion et une perte de tunnel, et au retrait de la politique supprimez seulement ses entrées exactes. Un namespace reste disponible si des interfaces séparées et un état séparé sont ce dont vous avez réellement besoin.