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

Firefox peger på 127.0.0.1:8000, N2N-kanten er oppe, peer'en svarer på en ping på sin overlay-adresse, og browseren rapporterer stadig, at proxyen afviste forbindelsen. Intet i den kæde er modstridende. Et overlay giver en vært en tilgængelig adresse på et privat netværk; det opretter ikke en proces, der taler proxyprotokollen. Browseren beder ikke om en rute til en peer. Den beder om en lokal listener.

To forbindelser bliver forvekslet her, og at tegne dem hver for sig fjerner det meste af forvirringen på et minut.

To forbindelser, ikke én

Den første forbindelse løber fra browseren til det, der lytter på loopback-porten. Det er en lokal socket, og hvis intet ejer den, afvises forbindelsen, før en enkelt pakke når N2N. Den anden løber fra proxyprocessen til det origin, den henter. Den vej vælges af proxyværtens routingtabel, og den kan være det almindelige uplink, en anden tunnel eller en policy-rute, der intet har med overlayet at gøre.

At pinge peer'en beviser, at overlayet kan levere pakker mellem kantadresser. Det beviser intet om en listener på port 8000 og intet om, hvorvidt den vært kan nå origin. Adskilte fejl, adskilte rettelser.

Hvor listeneren skal bo

En proxy bundet til 127.0.0.1 er med vilje lokal: den accepterer kun forbindelser fra den maskine, den kører på. Det er den rigtige standard for en personlig proxy og den forkerte form til at dele den over et overlay. Betjening af overlay-peers kræver enten en bind-adresse på overlay-interfacet eller en videresendelseskomponent, der afslutter loopback-forbindelsen og videresender den. Under alle omstændigheder bør en eksplicit politik afgøre, hvilke overlay-kilder der må bruge tjenesten, fordi en åben proxy på et delt netværk er en invitation.

Kontrollér den faktiske bind med en socket-liste i stedet for konfigurationsfilen. En daemon, der startede, før overlayet kom op, kan stadig være bundet til en adresse, der ikke længere findes.

localhost er ikke peer'en

I browserens proxyfelt peger localhost på browserens egen maskine. Det er ikke kanten, ikke supernoden og ikke værten i den fjerne ende af tunnelen. Hvis proxyen kører på en anden peer, skal du sætte den peers tilgængelige overlay-adresse og port i feltet og derefter bekræfte, at listeneren accepterer forbindelser fra din kantadresse.

Supernoder hjælper kanter med at finde hinanden; de er ikke en proxytjeneste. At behandle en supernode-adresse som et proxy-endepunkt giver samme afvisning med et ekstra skridt forvirring.

En rute kan ikke udføre et håndtryk

Selv med den rigtige adresse er routing ikke proxying. En HTTP-proxyforbindelse begynder med en CONNECT-anmodning eller en anmodningslinje i absolut form, og en SOCKS-proxy begynder med en version- og metodeforhandling. En router eller et overlay videresender bytes; den parser ikke de meddelelser og åbner ikke den videre forbindelse for dig. Derfor kan en rute, der virker til ping og SSH, stadig fejle for en browser-proxy: browseren har brug for en samarbejdende proces, ikke blot tilgængelighed.

Hvis målet blot er at nå en tjeneste på peer'en, skal du fjerne proxyindstillingen og bruge tjenestens overlay-adresse direkte.

Test grænserne i rækkefølge

Bekræft, at overlay-adressen svarer, og bekræft derefter, at der findes en listener på den konfigurerede port, og notér dens bind-adresse. Lav én kontrolleret anmodning og læs proxyens log, så du ved, om fejlen ligger hos listeneren eller ved den videre hentning. Kontrollér til sidst proxyværtens rute og DNS-politik for origin.

N2N-projektet dokumenterer kanter og supernoder som overlay-komponenter. Det gør ikke en kant til en applikationsproxy, og ingen routingkonfiguration tilføjer en protokolhandler, som ingen har startet.