Ett N2N-overlay är inte en proxy: rita båda anslutningarna

Firefox pekar på 127.0.0.1:8000, N2N-kanten är uppe, peeren svarar på en ping på sin overlay-adress, och webbläsaren rapporterar fortfarande att proxyn nekade anslutningen. Inget i den kedjan är motsägelsefullt. Ett overlay ger en värd en nåbar adress på ett privat nätverk; det skapar inte en process som talar proxyprotokollet. Webbläsaren ber inte om en väg till en peer. Den ber om en lokal lyssnare.

Här förväxlas två anslutningar, och att rita dem separat reder ut det mesta av förvirringen på en minut.

Två anslutningar, inte en

Den första anslutningen går från webbläsaren till det som lyssnar på loopback-porten. Det är en lokal socket, och om ingenting äger den avvisas anslutningen innan ett enda paket når N2N. Den andra går från proxyprocessen till det ursprung den hämtar. Den vägen väljs av proxyvärdens routingtabell, och det kan vara den vanliga upplänken, en annan tunnel eller en policyväg som inte har något med overlayet att göra.

Att pinga peeren bevisar att overlayet kan leverera paket mellan kantadresser. Det bevisar ingenting om en lyssnare på port 8000, och ingenting om huruvida den värden kan nå ursprunget. Separata fel, separata åtgärder.

Var lyssnaren måste bo

En proxy bunden till 127.0.0.1 är medvetet lokal: den accepterar bara anslutningar från maskinen den kör på. Det är rätt standard för en personlig proxy och fel form för att dela den över ett overlay. Att betjäna overlay-peers kräver antingen en bind-adress på overlay-gränssnittet eller en vidarebefordringskomponent som avslutar loopback-anslutningen och skickar vidare den. Oavsett vilket bör en uttrycklig policy avgöra vilka overlay-källor som får använda tjänsten, eftersom en öppen proxy på ett delat nätverk är en inbjudan.

Kontrollera den faktiska binden med en socket-lista i stället för konfigurationsfilen. En daemon som startade innan overlayet kom upp kan fortfarande vara bunden till en adress som inte längre finns.

localhost är inte peeren

I webbläsarens proxyfält pekar localhost på webbläsarens egen maskin. Det är inte kanten, inte supernode-n och inte värden i den bortre änden av tunneln. Om proxyn körs på en annan peer, sätt den peerens nåbara overlay-adress och port i fältet och bekräfta sedan att lyssnaren accepterar anslutningar från din kantadress.

Supernoder hjälper kanter att hitta varandra; de är inte en proxytjänst. Att behandla en supernode-adress som en proxyändpunkt ger samma avslag med ett extra steg av förvirring.

En väg kan inte utföra en handskakning

Även med rätt adress är routing inte proxying. En HTTP-proxyanslutning börjar med en CONNECT-begäran eller en begäransrad i absolut form, och en SOCKS-proxy börjar med förhandling om version och metod. En router eller ett overlay vidarebefordrar byte; den tolkar inte dessa meddelanden och öppnar inte nästa anslutning åt dig. Det är därför en väg som fungerar för ping och SSH ändå kan misslyckas för en webbläsarproxy: webbläsaren behöver en samarbetande process, inte bara nåbarhet.

Om målet bara är att nå en tjänst på peeren, ta bort proxyinställningen och använd tjänstens overlay-adress direkt.

Testa gränserna i ordning

Bekräfta att overlay-adressen svarar, bekräfta sedan att det finns en lyssnare på den konfigurerade porten och anteckna dess bind-adress. Gör en kontrollerad begäran och läs proxyns logg, så att du vet om felet ligger hos lyssnaren eller vid den vidare hämtningen. Kontrollera slutligen proxyvärdens väg och DNS-policyn för ursprunget.

N2N-projektet dokumenterar kanter och supernoder som overlay-komponenter. Det gör inte en kant till en applikationsproxy, och ingen routingkonfiguration lägger till en protokollhanterare som ingen har startat.