Et N2N-overlay er ikke en proxy: tegn begge forbindelsene

Firefox peker på 127.0.0.1:8000, N2N-kanten er oppe, peeren svarer på en ping på sin overlay-adresse, og nettleseren rapporterer fortsatt at proxyen avviste forbindelsen. Ingenting i den kjeden er selvmotsigende. Et overlay gir en vert en tilgjengelig adresse på et privat nettverk; det oppretter ikke en prosess som snakker proxyprotokollen. Nettleseren ber ikke om en rute til en peer. Den ber om en lokal listener.

To forbindelser forveksles her, og å tegne dem hver for seg fjerner det meste av forvirringen på et minutt.

To forbindelser, ikke én

Den første forbindelsen går fra nettleseren til det som lytter på loopback-porten. Det er en lokal socket, og hvis ingenting eier den, avvises forbindelsen før en eneste pakke når N2N. Den andre går fra proxyprosessen til opphavet den henter. Den veien velges av rutetabellen til proxyverten, og den kan være den vanlige oppstrømsforbindelsen, en annen tunnel eller en policy-rute som ikke har noe med overlayet å gjøre.

Å pinge peeren beviser at overlayet kan levere pakker mellom kantadresser. Det beviser ingenting om en listener på port 8000, og ingenting om hvorvidt den verten kan nå opphavet. Separate feil, separate rettelser.

Hvor listeneren må bo

En proxy bundet til 127.0.0.1 er bevisst lokal: den godtar bare forbindelser fra maskinen den kjører på. Det er riktig standard for en personlig proxy og feil form for å dele den over et overlay. Å betjene overlay-peere krever enten en bind-adresse på overlay-grensesnittet eller en videresendingskomponent som avslutter loopback-forbindelsen og videresender den. Uansett bør en eksplisitt policy avgjøre hvilke overlay-kilder som kan bruke tjenesten, fordi en åpen proxy på et delt nettverk er en invitasjon.

Kontroller den faktiske binden med en socket-liste i stedet for konfigurasjonsfilen. En daemon som startet før overlayet kom opp, kan fortsatt være bundet til en adresse som ikke lenger finnes.

localhost er ikke peeren

I nettleserens proxyfelt peker localhost på nettleserens egen maskin. Det er ikke kanten, ikke supernoden og ikke verten i den andre enden av tunnelen. Hvis proxyen kjører på en annen peer, sett den peerens tilgjengelige overlay-adresse og port i feltet, og bekreft deretter at listeneren godtar forbindelser fra kantadressen din.

Supernoder hjelper kanter med å finne hverandre; de er ikke en proxytjeneste. Å behandle en supernode-adresse som et proxy-endepunkt gir samme avvisning med et ekstra skritt med forvirring.

En rute kan ikke utføre et håndtrykk

Selv med riktig adresse er ruting ikke proxying. En HTTP-proxyforbindelse begynner med en CONNECT-forespørsel eller en forespørselslinje i absolutt form, og en SOCKS-proxy begynner med forhandling om versjon og metode. En ruter eller et overlay videresender bytes; den parser ikke disse meldingene og åpner ikke den videre forbindelsen for deg. Derfor kan en rute som virker for ping og SSH fortsatt feile for en nettleserproxy: nettleseren trenger en samarbeidende prosess, ikke bare tilgjengelighet.

Hvis målet bare er å nå en tjeneste på peeren, fjern proxyinnstillingen og bruk overlay-adressen til tjenesten direkte.

Test grensene i rekkefølge

Bekreft at overlay-adressen svarer, og bekreft deretter at det finnes en listener på den konfigurerte porten, og noter bind-adressen dens. Gjør én kontrollert forespørsel og les proxyens logg, slik at du vet om feilen ligger hos listeneren eller ved den videre hentingen. Til slutt, kontroller ruten til proxyverten og DNS-policyen for opphavet.

N2N-prosjektet dokumenterer kanter og supernoder som overlay-komponenter. Det gjør ikke en kant til en applikasjonsproxy, og ingen rutekonfigurasjon legger til en protokollbehandler som ingen har startet.