Proxy SOCKS5 pour OpenVPN : tunnel TCP ou proxyfier les applications ?

Les réseaux qui n'autorisent qu'une sortie via proxy sont ceux où un profil qui fonctionnait meurt soudainement. L'adresse du proxy est la variable la moins intéressante de cet échec. Tout dépend de la forme du trafic que le proxy relaiera, car ces proxys transportent un flux d'octets et un tunnel UDP n'en est pas un. Il reste deux architectures, et elles cassent à des endroits différents.

Une contrainte décide de la conception

SOCKS5 spécifie bien un mode d'association UDP. La prise en charge du proxy par le client OpenVPN est néanmoins construite autour des flux : socks-proxy est documenté pour les profils TCP, et un proxy HTTP CONNECT n'a aucun chemin pour les datagrammes. Une ligne de documentation tranche l'architecture avant que vous touchiez un fichier de configuration.

La question n'est donc pas quel proxy choisir. Elle est de savoir si le tunnel devient un flux, ou reste un datagramme et laisse autre chose absorber le proxying.

Option A : transformer le tunnel en flux

Cela exige un serveur avec un écouteur TCP, et un profil client qui nomme le proxy. Les deux pièces sont nécessaires, et le côté serveur est celui que l'on oublie :

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Remplacez la dernière ligne par http-proxy proxy.internal 8080 lorsque le proxy parle HTTP, et ajoutez un fichier d'identifiants s'il en exige un. Le proxy doit accepter d'exécuter CONNECT vers votre port VPN, et le serveur doit répondre en TCP ; un écouteur uniquement UDP ignore la tentative. Choisir 443 est un choix pratique, car beaucoup de réseaux restrictifs l'autorisent et peu autre chose.

Le coût, c'est TCP empilé sur TCP. Un segment extérieur perdu bloque tous les flux intérieurs qui partagent cette connexion, si bien qu'une reprise normalement indépendante devient partagée. La mise en place prend aussi plus de temps, et un chemin extérieur instable devient un tunnel instable plutôt que lent.

Option B : laisser le tunnel tranquille

Quand le tunnel doit rester en UDP, ce n'est pas le tunnel qu'on configure. À la place, le TCP sortant des applications est redirigé vers un écouteur SOCKS local, et les applications n'apprennent jamais qu'un proxy existe. Sous Linux, c'est généralement redsocks plus une règle NAT REDIRECT dans la table nat.

TCP uniquement, encore. Un proxy uniquement HTTP comme privoxy ne peut pas relayer des protocoles arbitraires, et cette conception n'ajoute pas non plus de prise en charge des datagrammes pour les applications.

Dire à chaque application qu'un proxy existe est généralement mieux là où le logiciel le permet. C'est plus facile à auditer, et cela échoue à un endroit que vous pouvez réellement voir.

Où chaque option échoue

L'option A échoue quand le serveur n'a pas d'écouteur TCP, quand le proxy refuse la cible CONNECT, ou quand le flux extérieur est limité en dessous de ce dont le tunnel a besoin. Les deux premières laissent une entrée dans le journal du proxy ; la troisième laisse une connexion qui s'établit puis semble anormale. Lisez ce journal avant de modifier le profil, car il sépare un problème d'autorisation d'un problème de capacité. Un CONNECT terminé déplace l'enquête à l'intérieur du tunnel.

L'option B échoue pour tout ce qui a besoin de datagrammes, pour les protocoles que le proxy ne comprend pas, et silencieusement sur les hôtes où la règle de redirection existe mais où le routage fait passer le trafic à côté.

Aucune des deux options ne change l'exigence de l'appareil. Les paquets ont toujours besoin d'un nœud TUN ou TAP avant que le noyau ne les route, donc le processus a toujours besoin d'une autorisation sur /dev/net/tun. Un enrobage change ce qui se passe une fois ce nœud ouvert, pas si vous en avez besoin.

Prouver quel chemin vous avez construit

Regardez les sockets plutôt que l'icône de la zone de notification. Le processus VPN doit maintenir une connexion établie vers l'adresse du proxy, et le proxy doit avoir journalisé la cible qu'on lui a demandé d'atteindre :

ss -tnp | grep openvpn

Ensuite, visez une destination que seul le tunnel peut servir, et un nom que seul le résolveur du tunnel peut résoudre. Une connexion proxy terminée avec un tunnel mort signifie généralement que l'extrémité distante n'a jamais proposé le transport nommé dans votre profil.

Notez le transport et le proxy qui accepte dans un endroit durable. Quand le même profil échoue sur un autre réseau, cette note écarte ou confirme le proxy en quelques secondes.