Redsocks écoute sur la boucle locale mais le trafic VPN n'arrive jamais

Un tunnel monte, le client peut pinguer la passerelle, et chaque requête web passant par le chemin du proxy meurt. Le processus redsocks tourne et son port écoute, donc le service semble sain depuis la passerelle elle-même. Ce qui échoue, c'est l'étape de livraison : un paquet redirigé depuis le tunnel n'atterrit pas sur le socket que vous avez démarré. L'adresse de liaison et la cible de redirection doivent concorder, et une seule des deux est généralement vérifiée.

Où atterrit réellement un paquet redirigé

Le proxy transparent sur une passerelle utilise REDIRECT dans la table nat à PREROUTING pour réécrire la destination d'une connexion entrante vers un port local. La destination réécrite est une adresse locale telle que la voit l'interface par laquelle le paquet est arrivé, et non l'adresse de boucle locale d'un processus démarré ailleurs. Un écouteur lié uniquement à 127.0.0.1 accepte les connexions déjà locales sur l'hôte, et c'est exactement le cas qui continue de fonctionner alors que le trafic du tunnel échoue. La boucle locale du client est une troisième adresse et n'est jamais la cible de la règle de la passerelle.

Ainsi, avant de toucher aux identifiants du niveau supérieur, établissez deux faits : vers quelle adresse locale la règle réécrit, et à quelle adresse le socket du proxy est lié.

Lisez l'écouteur et la règle de redirection ensemble

Affichez la table des sockets et les règles nat dans la même passe, car une règle qui pointe vers un port que personne ne possède ressemble à l'identique à une règle qui pointe vers la mauvaise adresse. sudo ss -ltnp | grep redsocks montre l'adresse de liaison et le processus propriétaire. sudo iptables -t nat -S PREROUTING montre la cible REDIRECT, et sudo iptables -t nat -L PREROUTING -v -n montre si quelque chose y a correspondu.

Un saut vers une chaîne utilisateur nommée REDSOCKS n'accomplit rien si cette chaîne n'existe pas et ne porte pas les exclusions prévues et l'action REDIRECT. Lisez la chaîne vers laquelle il saute avec sudo iptables -t nat -S REDSOCKS au lieu de supposer que le nom fait le travail.

Comparez ensuite les deux valeurs. Si la règle redirige vers une adresse de passerelle sur le port 12345 et que l'écouteur signale 127.0.0.1:12345, la discordance explique l'échec sans aucun diagnostic supplémentaire.

Liez étroitement, puis limitez ce qui peut l'atteindre

La configuration d'exemple du niveau supérieur met l'écouteur sur la boucle locale pour une bonne raison : un proxy transparent accepte des connexions au nom de quiconque peut l'atteindre. Passer la liaison à 0.0.0.0 corrige la livraison et ouvre simultanément le port sur toutes les interfaces, ce qui est un changement de sécurité, pas une réparation neutre. Préférez une liaison à l'adresse locale précise que la redirection cible, et gardez le port fermé sur les interfaces non fiables. Si une liaison plus large est inévitable, ajoutez une règle de pare-feu d'hôte qui n'autorise que la plage source du tunnel et le trafic local propre à la passerelle.

Ouvrir le port sur l'interface publique n'est jamais nécessaire pour le trafic VPN redirigé, car la connexion se termine localement après la réécriture. N'exposez pas le proxy à internet pour faire fonctionner une redirection locale.

Prouvez-le avec une nouvelle connexion depuis un client

Testez depuis un vrai client VPN avec une connexion TCP neuve, pas depuis un shell sur la passerelle. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com sur le client exerce le chemin redirigé de bout en bout.

Confirmez ensuite qu'une connexion directe à l'écouteur depuis un réseau non fiable est toujours refusée, et que la connexion amont du proxy n'est pas capturée à nouveau par la même règle. La capture récursive se manifeste comme un proxy qui se connecte à lui-même et ne termine jamais une requête. Ajoutez la destination du proxy à l'ensemble des exclusions, ou marquez ses paquets sortants pour que la chaîne les saute.

Enfin, rappelez-vous ce que ce chemin ne couvre pas. La redirection TCP ordinaire de redsocks ne transforme pas UDP, QUIC ou DNS en trafic SOCKS, et les destinations privées nécessitent généralement des exclusions explicites. Un test local réussi ne prouve que le chemin de boucle locale qui n'était jamais le problème.