Dante SOCKS par VPN : tunnel complet ou routage par source

Vous voulez que le trafic du proxy SOCKS sorte par le VPN tandis que le reste de l'hôte garde son chemin habituel. Deux conceptions le font, et elles diffèrent par ce qui casse quand quelque chose va mal. L'une pousse une route par défaut dans le tunnel puis la contourne ; l'autre laisse la table principale tranquille et envoie une seule adresse source vers une seconde table. La seconde est plus propre, et elle a ses propres pièges.

Deux conceptions, deux rayons de dégâts différents

La conception en tunnel complet est ce que font par défaut la plupart des clients VPN : remplacer la route par défaut pour que tout suive le tunnel, puis exclure ce qui ne le doit pas. Elle est facile à raisonner et difficile à garder étroite, car chaque service local ajouté hérite du tunnel jusqu'à ce que vous l'excluiez. Le mode de défaillance est large, car une seule mauvaise route emporte la connectivité de l'hôte lui-même.

La conception par sélection de source va dans l'autre sens. La table principale reste telle quelle, et une règle de politique envoie les paquets d'une adresse locale précise vers une table dotée d'une route par défaut vers le tunnel. Rien d'autre ne change, ce qui veut dire que le rayon de dégâts est une adresse.

Cette étroitesse est aussi la contrainte : la conception ne fonctionne que si les paquets sortants du proxy portent réellement cette adresse.

Ce que fait le réglage external de Dante

Le réglage external choisit les adresses que le proxy utilise pour les connexions sortantes ; il ne touche pas à la politique de routage du noyau. C'est cette séparation qui rend la seconde conception possible, et c'est aussi là que les gens lisent mal la documentation. Pointer external vers une adresse du tunnel fait que le proxy émet ses connexions depuis cette adresse, et la table de routage décide ensuite où vont ces paquets.

L'écouteur est une autre affaire. Gardez internal limité aux clients qui doivent utiliser le proxy, exigez une authentification et fermez le port par un pare-feu, car un écouteur ouvert n'est pas une caractéristique d'une sortie VPN.

Vérifiez que l'adresse configurée appartient réellement au tunnel dans l'espace de noms réseau du proxy.

Construire la table par sélection de source

Pour une adresse TUN de 10.90.0.2/24 avec un pair joignable à 10.90.0.1, et un numéro de table que rien d'autre n'utilise, la disposition ressemble à ceci :

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

La route inatteignable est la partie que les gens sautent. Sans elle, une table dont la route de tunnel disparaît retombe sur la route par défaut ordinaire et le proxy sort silencieusement par le WAN. Avec elle, la recherche échoue, ce qui est une défaillance visible plutôt qu'une fuite silencieuse. La priorité de la règle doit aussi se situer devant tout ce qui correspond à cette source.

Ces valeurs décrivent une topologie. Les pairs point à point, l'adressage net30 et les clients qui distribuent un préfixe différent ont tous besoin de leurs propres routes, alors copiez la forme, pas les adresses.

Où la règle de source fuit

Une règle qui correspond à une adresse source touche chaque processus qui l'utilise, pas seulement le proxy. Si un autre démon lie la même adresse, son trafic prend aussi le tunnel, et la défaillance ressemblera à un problème de service sans rapport. Donnez au proxy une adresse que rien d'autre n'utilise, ou acceptez que la portée soit l'adresse et non le processus.

DNS est l'autre fuite. Une socket de résolution n'utilise pas forcément la source de données sortantes du proxy, donc les résolutions de noms peuvent encore sortir par le WAN. Testez la résolution séparément de l'établissement de connexion, et décidez si ce résultat est acceptable.

IPv6 a besoin de ses propres règles et routes, car une disposition IPv4 ne prouve rien à son sujet.

Choisissez selon la défaillance que vous pouvez tolérer

Choisissez le tunnel complet quand l'hôte doit être protégé dans son ensemble et que vous pouvez tenir la liste des exclusions. Choisissez le routage par source quand l'hôte doit garder son propre chemin et qu'un seul service doit être redirigé. Les deux sont légitimes ; l'erreur est d'en choisir un puis de le tester comme s'il s'agissait de l'autre.

Quel que soit votre choix, vérifiez des deux côtés : une requête via le proxy et une requête directe depuis l'hôte, avec l'adresse de sortie observée notée pour chacune.

Si le tunnel tombe, décidez à l'avance si le proxy doit échouer ou revenir en arrière, et laissez la table de routage exprimer cette décision.