Un overlay N2N n’est pas un proxy : dessinez les deux connexions

Firefox pointe vers 127.0.0.1:8000, l’edge N2N est actif, le pair répond à un ping sur son adresse overlay, et le navigateur signale toujours que le proxy a refusé la connexion. Rien dans cette chaîne n’est contradictoire. Un overlay donne à un hôte une adresse joignable sur un réseau privé ; il ne crée pas de processus qui parle le protocole du proxy. Le navigateur ne demande pas une route vers un pair. Il demande un listener local.

Deux connexions sont confondues ici, et les dessiner séparément dissipe l’essentiel de la confusion en une minute.

Deux connexions, pas une

La première connexion va du navigateur à ce qui écoute sur le port loopback. C’est un socket local, et si rien ne le possède, la connexion est refusée avant qu’un seul paquet n’atteigne N2N. La seconde va du processus proxy à l’origine qu’il récupère. Ce chemin est choisi par la table de routage de l’hôte proxy, et il peut être l’uplink ordinaire, un autre tunnel ou une route de politique qui n’a rien à voir avec l’overlay.

Pinger le pair prouve que l’overlay peut livrer des paquets entre adresses d’edge. Cela ne prouve rien sur un listener au port 8000, ni sur la capacité de cet hôte à joindre l’origine. Défaillances distinctes, correctifs distincts.

Où le listener doit vivre

Un proxy lié à 127.0.0.1 est délibérément local : il n’accepte des connexions que depuis la machine où il tourne. C’est le bon défaut pour un proxy personnel et la mauvaise forme pour le partager sur un overlay. Servir des pairs de l’overlay exige soit une adresse de bind sur l’interface overlay, soit un composant de transfert qui termine la connexion loopback et la relaie. Dans tous les cas, une politique explicite devrait décider quelles sources overlay peuvent utiliser le service, car un proxy ouvert sur un réseau partagé est une invitation.

Vérifiez le bind réel avec une liste de sockets plutôt qu’avec le fichier de configuration. Un démon démarré avant la montée de l’overlay peut encore être lié à une adresse qui n’existe plus.

localhost n’est pas le pair

Dans le champ proxy du navigateur, localhost pointe vers la machine du navigateur lui-même. Ce n’est pas l’edge, ni le supernode, ni l’hôte à l’autre bout du tunnel. Si le proxy tourne sur un autre pair, mettez dans le champ l’adresse overlay joignable et le port de ce pair, puis confirmez que le listener accepte les connexions depuis l’adresse de votre edge.

Les supernodes aident les edges à se trouver ; ce ne sont pas un service proxy. Traiter une adresse de supernode comme un point de terminaison proxy produit le même refus avec un saut de confusion supplémentaire.

Une route ne peut pas faire de handshake

Même avec la bonne adresse, le routage n’est pas le proxying. Une connexion proxy HTTP commence par une requête CONNECT ou une ligne de requête de forme absolue, et un proxy SOCKS commence par une négociation de version et de méthode. Un routeur ou un overlay transmet des octets ; il n’analyse pas ces messages et n’ouvre pas la connexion suivante à votre place. C’est pourquoi une route qui fonctionne pour ping et SSH peut encore échouer pour un proxy de navigateur : le navigateur a besoin d’un processus coopératif, pas seulement d’une joignabilité.

Si le but est simplement d’atteindre un service sur le pair, retirez le réglage de proxy et utilisez directement l’adresse overlay du service.

Testez les frontières dans l’ordre

Confirmez que l’adresse overlay répond, puis confirmez qu’un listener existe sur le port configuré et notez son adresse de bind. Faites une requête contrôlée et lisez le journal du proxy, pour savoir si la panne se situe au listener ou à la récupération suivante. Enfin, vérifiez la route de l’hôte proxy et la politique DNS pour l’origine.

Le projet N2N documente les edges et les supernodes comme composants d’overlay. Il ne transforme pas un edge en proxy applicatif, et aucune configuration de routage n’ajoute de gestionnaire de protocole que personne n’a démarré.