Listen, Bind et BindSame dans Tinyproxy : quelle adresse l’emporte

Le proxy répond, la requête aboutit et, pourtant, la destination enregistre toujours l’adresse du LAN. Rien dans le journal du proxy ne paraît anormal, et la ligne que vous avez modifiée est bien celle que la documentation vous demandait de changer. Sur un hôte qui possède à la fois une adresse LAN et une adresse de tunnel, trois directives décident quelle adresse apparaît où, et une seule concerne le côté sortant. Les lire dans le mauvais ordre vous envoie dans la table de routage sans raison.

Le symptôme : la destination voit l’adresse du LAN

Un client se connecte au proxy sur l’adresse du LAN, et le proxy ouvre sa propre connexion vers la destination. Cette seconde connexion choisit une adresse source selon les règles du noyau, et par défaut c’est celle que retient la recherche de route. La destination enregistre donc l’adresse principale de l’hôte alors que chaque octet est passé par le proxy. Rien n’est cassé côté transfert, et c’est pourquoi le journal du proxy n’a rien à en dire.

L’image inversée de ce défaut est plus facile à repérer : épinglez la source sortante sur l’adresse du tunnel et les clients du LAN n’atteignent plus du tout l’écouteur. Cette version s’annonce d’elle-même, tandis que la première se cache derrière une requête qui fonctionne. Les deux viennent du fait de traiter une directive comme si elle répondait aux deux questions.

Trois directives, trois adresses différentes

Listen nomme l’adresse locale qui accepte les clients du proxy. Bind fournit une adresse source pour les connexions que le proxy établit vers l’extérieur, et BindSame lui demande de réutiliser l’adresse locale de la connexion qu’il vient d’accepter. Ce sont trois questions distinctes, et une seule ligne n’en résout qu’une. Les confondre est la raison habituelle pour laquelle un changement semble sans effet.

Lisez la configuration commentée fournie avec la version installée, car les valeurs par défaut et la syntaxe acceptée évoluent d’une version à l’autre. La configuration d’exemple du projet documente chaque directive à côté des autres. Comparez ce fichier avec celui du disque, pas avec un guide écrit pour une autre distribution.

Réglez l’écouteur et la source sortante indépendamment

Prenez un hôte dont l’adresse LAN est 192.168.50.10 et l’adresse de tunnel 10.90.0.3. Si les clients du LAN doivent atteindre le proxy tandis que leurs requêtes sortent par le tunnel, ce sont deux décisions indépendantes et toutes deux doivent être écrites. Le fragment ci-dessous exprime exactement cela et rien d’autre.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Ce n’est pas une configuration complète, conservez donc le port approuvé, l’authentification, les contrôles d’accès des clients et les restrictions de destination. Les deux adresses doivent appartenir à cet hôte dans l’espace de noms réseau de Tinyproxy, car une valeur Bind que le processus ne peut pas posséder échoue à la connexion, pas au démarrage. BindSame yes décrit une autre politique, où l’adresse locale de la connexion acceptée devient la source sortante. Dans les versions actuelles, cette branche prime sur la liste Bind, et c’est ainsi qu’une source configurée disparaît sans erreur.

Vérifiez la route que la source implique

Choisir une adresse source ne crée pas de chemin, demandez donc au noyau ce qu’il ferait avec cette source et cette destination. Une recherche qui nomme l’interface du tunnel est la preuve minimale, et une qui nomme l’interface du LAN signifie que la source ne peut pas fonctionner telle qu’écrite. La recherche est contextuelle : elle évalue les règles de politique et la table en vigueur pour cet espace de noms. Ce n’est pas une connexion, et elle ne dit rien de ce qu’un NAT en aval présentera au service.

ip -4 route get 203.0.113.25 from 10.90.0.3

Utilisez une adresse de documentation dans l’exemple et remplacez-la par le service que vous êtes autorisé à tester. Exécutez la recherche dans l’espace de noms du proxy lorsque le proxy tourne dans un conteneur, car les règles de l’hôte ne sont pas celles que voit le processus. Si la route de tunnel prévue manque, faites-la corriger par le propriétaire du réseau plutôt que d’ajouter des règles propres à la destination sur l’hôte du proxy. Ne videz pas les routes de l’hôte et ne désactivez pas les routes poussées par le serveur pour faire réussir une recherche, même si un guide plus ancien le faisait, car ces changements déplacent tout le comportement VPN approuvé de l’hôte pour réparer un seul chemin du proxy.

Confirmez la source à la destination

Lisez la source là où la requête arrive, pas là où elle part. Le journal applicatif de la destination, ou l’équipement de bord placé devant elle, note l’adresse qu’il a réellement vue, alors que le proxy ne peut vous dire que ce qu’il avait l’intention de faire. Lancez une nouvelle requête via l’écouteur prévu après le changement, car une connexion en cache ne prouve rien sur la nouvelle liaison. Comparez ensuite cette adresse enregistrée avec celle que vous avez configurée.

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

curl n’est que le générateur de trafic ; l’adresse qui mérite vérification est celle qu’a journalisée le côté distant, pas le pair auquel curl s’est connecté par hasard. Si les deux diffèrent, déterminez si l’écart vient du choix de source ou d’une traduction plus loin sur le chemin, car cela se corrige à des endroits différents. Planifiez ensemble les changements d’adresse et les redémarrages du proxy, car lier une adresse que le tunnel ne détient plus échoue silencieusement après une reconnexion. Définissez aussi le comportement DNS et IPv6 séparément, car le fragment IPv4 ci-dessus ne prouve rien pour l’un ni pour l’autre.