Ein N2N-Overlay ist kein Proxy: Zeichne beide Verbindungen

Firefox zeigt auf 127.0.0.1:8000, der N2N-Edge läuft, der Peer antwortet auf einen Ping an seiner Overlay-Adresse, und der Browser meldet weiterhin, dass der Proxy die Verbindung verweigert habe. Nichts in dieser Kette ist widersprüchlich. Ein Overlay gibt einem Host eine erreichbare Adresse in einem privaten Netz; es erzeugt keinen Prozess, der das Proxy-Protokoll spricht. Der Browser fragt nicht nach einer Route zu einem Peer. Er fragt nach einem lokalen Listener.

Hier werden zwei Verbindungen verwechselt, und sie getrennt zu zeichnen beseitigt den größten Teil der Verwirrung in einer Minute.

Zwei Verbindungen, nicht eine

Die erste Verbindung läuft vom Browser zu dem, was am Loopback-Port lauscht. Das ist ein lokaler Socket, und wenn nichts ihn besitzt, wird die Verbindung abgelehnt, bevor auch nur ein Paket N2N erreicht. Die zweite läuft vom Proxy-Prozess zu dem Origin, den er abruft. Diesen Pfad wählt die Routing-Tabelle des Proxy-Hosts, und es kann der gewöhnliche Uplink, ein anderer Tunnel oder eine Policy-Route sein, die mit dem Overlay nichts zu tun hat.

Den Peer anzupingen beweist, dass das Overlay Pakete zwischen Edge-Adressen zustellen kann. Es beweist nichts über einen Listener auf Port 8000 und nichts darüber, ob dieser Host den Origin erreichen kann. Getrennte Fehler, getrennte Korrekturen.

Wo der Listener leben muss

Ein an 127.0.0.1 gebundener Proxy ist bewusst lokal: Er akzeptiert Verbindungen nur von der Maschine, auf der er läuft. Das ist der richtige Standard für einen persönlichen Proxy und die falsche Form, um ihn über ein Overlay zu teilen. Um Overlay-Peers zu bedienen, braucht man entweder eine Bind-Adresse auf der Overlay-Schnittstelle oder eine Weiterleitungskomponente, die die Loopback-Verbindung beendet und weiterleitet. So oder so sollte eine ausdrückliche Richtlinie entscheiden, welche Overlay-Quellen den Dienst nutzen dürfen, denn ein offener Proxy in einem gemeinsam genutzten Netz ist eine Einladung.

Prüfe das tatsächliche Bind mit einer Socket-Auflistung statt mit der Konfigurationsdatei. Ein Daemon, der gestartet wurde, bevor das Overlay hochkam, kann noch an eine Adresse gebunden sein, die es nicht mehr gibt.

localhost ist nicht der Peer

Im Proxy-Feld des Browsers zeigt localhost auf den Rechner des Browsers selbst. Es ist nicht der Edge, nicht der Supernode und nicht der Host am fernen Ende des Tunnels. Wenn der Proxy auf einem anderen Peer läuft, trage die erreichbare Overlay-Adresse und den Port dieses Peers in das Feld ein und bestätige dann, dass der Listener Verbindungen von deiner Edge-Adresse annimmt.

Supernodes helfen Edges, einander zu finden; sie sind kein Proxy-Dienst. Eine Supernode-Adresse als Proxy-Endpunkt zu behandeln erzeugt dieselbe Ablehnung mit einem zusätzlichen Verwirrungsschritt.

Eine Route kann keinen Handshake ausführen

Selbst mit richtiger Adresse ist Routing kein Proxying. Eine HTTP-Proxy-Verbindung beginnt mit einer CONNECT-Anfrage oder einer Anforderungszeile in absoluter Form, und ein SOCKS-Proxy beginnt mit einer Aushandlung von Version und Methode. Ein Router oder ein Overlay leitet Bytes weiter; es parst diese Nachrichten nicht und öffnet die weitere Verbindung nicht für dich. Deshalb kann eine Route, die für Ping und SSH funktioniert, für einen Browser-Proxy immer noch scheitern: Der Browser braucht einen kooperierenden Prozess, nicht bloß Erreichbarkeit.

Wenn das Ziel nur ist, einen Dienst auf dem Peer zu erreichen, entferne die Proxy-Einstellung und nutze die Overlay-Adresse des Dienstes direkt.

Teste die Grenzen der Reihe nach

Bestätige, dass die Overlay-Adresse antwortet, dann bestätige, dass am konfigurierten Port ein Listener existiert, und notiere seine Bind-Adresse. Stelle eine kontrollierte Anfrage und lies das Proxy-Log, damit du weißt, ob der Fehler beim Listener oder beim weiteren Abruf liegt. Prüfe schließlich die Route des Proxy-Hosts und die DNS-Richtlinie für den Origin.

Das N2N-Projekt dokumentiert Edges und Supernodes als Overlay-Komponenten. Es macht eine Edge nicht zu einem Anwendungsproxy, und keine Routing-Konfiguration fügt einen Protokoll-Handler hinzu, den niemand gestartet hat.