Een N2N-overlay is geen proxy: teken beide verbindingen

Firefox wijst naar 127.0.0.1:8000, de N2N-edge is actief, de peer antwoordt op een ping op zijn overlay-adres, en de browser meldt nog steeds dat de proxy de verbinding heeft geweigerd. Niets in die keten is tegenstrijdig. Een overlay geeft een host een bereikbaar adres op een privénetwerk; hij maakt geen proces dat het proxyprotocol spreekt. De browser vraagt niet om een route naar een peer. Hij vraagt om een lokale listener.

Hier worden twee verbindingen verward, en ze apart tekenen lost het grootste deel van de verwarring in een minuut op.

Twee verbindingen, niet één

De eerste verbinding loopt van de browser naar wat er op de loopback-poort luistert. Dat is een lokale socket, en als niets hem bezit, wordt de verbinding geweigerd voordat er één pakket N2N bereikt. De tweede loopt van het proxyproces naar de origin die het ophaalt. Dat pad wordt gekozen door de routingtabel van de proxyhost, en het kan de gewone uplink zijn, een andere tunnel of een policy-route die niets met de overlay te maken heeft.

De peer pingen bewijst dat de overlay pakketten tussen edge-adressen kan afleveren. Het bewijst niets over een listener op poort 8000, en niets over of die host de origin kan bereiken. Aparte fouten, aparte oplossingen.

Waar de listener moet wonen

Een proxy die aan 127.0.0.1 is gebonden, is bewust lokaal: hij accepteert alleen verbindingen van de machine waarop hij draait. Dat is de juiste standaard voor een persoonlijke proxy en de verkeerde vorm om er een over een overlay te delen. Om overlay-peers te bedienen is ofwel een bindadres op de overlay-interface nodig, ofwel een doorstuurcomponent die de loopback-verbinding beëindigt en doorgeeft. Hoe dan ook, een expliciet beleid moet beslissen welke overlay-bronnen de dienst mogen gebruiken, want een open proxy op een gedeeld netwerk is een uitnodiging.

Controleer de werkelijke bind met een socketlijst in plaats van het configuratiebestand. Een daemon die startte voordat de overlay omhoogkwam, kan nog steeds gebonden zijn aan een adres dat niet meer bestaat.

localhost is niet de peer

In het proxyveld van de browser wijst localhost naar de machine van de browser zelf. Het is niet de edge, niet de supernode en niet de host aan het verre uiteinde van de tunnel. Als de proxy op een andere peer draait, zet dan het bereikbare overlay-adres en de poort van die peer in het veld en bevestig vervolgens dat de listener verbindingen van jouw edge-adres accepteert.

Supernodes helpen edges elkaar te vinden; ze zijn geen proxydienst. Een supernode-adres als proxy-eindpunt behandelen levert dezelfde weigering op met een extra stap verwarring.

Een route kan geen handshake uitvoeren

Zelfs met het juiste adres is routing geen proxying. Een HTTP-proxyverbinding begint met een CONNECT-verzoek of een verzoekregel in absolute vorm, en een SOCKS-proxy begint met onderhandeling over versie en methode. Een router of een overlay stuurt bytes door; hij parseert die berichten niet en opent de vervolgverbinding niet voor je. Daarom kan een route die werkt voor ping en SSH nog steeds falen voor een browserproxy: de browser heeft een samenwerkend proces nodig, niet alleen bereikbaarheid.

Als het doel alleen is om een dienst op de peer te bereiken, verwijder dan de proxyinstelling en gebruik het overlay-adres van de dienst rechtstreeks.

Test de grenzen in volgorde

Bevestig dat het overlay-adres antwoordt, bevestig dan dat er een listener op de geconfigureerde poort is en noteer het bindadres. Doe één gecontroleerd verzoek en lees de proxylog, zodat je weet of de fout bij de listener of bij het verdere ophalen zit. Controleer tot slot de route van de proxyhost en het DNS-beleid voor de origin.

Het N2N-project documenteert edges en supernodes als overlay-componenten. Het maakt van een edge geen applicatieproxy, en geen enkele routeringsconfiguratie voegt een protocolhandler toe die niemand heeft gestart.