Eit N2N-overlay er ikkje ein proxy: teikn begge sambanda

Firefox peikar på 127.0.0.1:8000, N2N-kanten er oppe, peeren svarar på ein ping på overlay-adressa si, og nettlesaren rapporterer framleis at proxyen avviste sambandet. Ingenting i den kjeda er sjølvmotseiande. Eit overlay gjev ein vert ei tilgjengeleg adresse på eit privat nettverk; det opprettar ikkje ein prosess som snakkar proxyprotokollen. Nettlesaren ber ikkje om ei rute til ein peer. Han ber om ein lokal lyttar.

Her blir to samband forveksla, og å teikne dei kvar for seg fjernar det meste av forvirringa på eitt minutt.

To samband, ikkje eitt

Det første sambandet går frå nettlesaren til det som lyttar på loopback-porten. Det er ein lokal socket, og viss ingenting eig han, blir sambandet avvist før ein einaste pakke når N2N. Det andre går frå proxyprosessen til opphavet han hentar. Den vegen blir vald av rutetabellen til proxyverten, og han kan vere den vanlege oppstraumslinja, ein annan tunnel eller ei policy-rute som ikkje har noko med overlayet å gjere.

Å pinge peeren beviser at overlayet kan levere pakkar mellom kantadresser. Det beviser ingenting om ein lyttar på port 8000, og ingenting om korvidt den verten kan nå opphavet. Skilde feil, skilde rettingar.

Kvar lyttaren må bu

Ein proxy bunden til 127.0.0.1 er med vilje lokal: han godtek berre samband frå maskina han køyrer på. Det er rett standard for ein personleg proxy og feil form for å dele han over eit overlay. Å tene overlay-peers krev anten ei bind-adresse på overlay-grensesnittet eller ein videresendingskomponent som avsluttar loopback-sambandet og sender det vidare. Uansett bør ein eksplisitt policy avgjere kva overlay-kjelder som kan bruke tenesta, fordi ein open proxy på eit delt nettverk er ein invitasjon.

Kontroller den faktiske binden med ei socket-liste i staden for konfigurasjonsfila. Ein daemon som starta før overlayet kom opp, kan framleis vere bunden til ei adresse som ikkje finst lenger.

localhost er ikkje peeren

I proxyfeltet til nettlesaren peikar localhost på maskina til nettlesaren sjølv. Det er ikkje kanten, ikkje supernoden og ikkje verten i den andre enden av tunnelen. Viss proxyen køyrer på ein annan peer, set den peeren si tilgjengelege overlay-adresse og port i feltet, og stadfest deretter at lyttaren godtek samband frå kantadressa di.

Supernodar hjelper kantar med å finne kvarandre; dei er ikkje ei proxytjeneste. Å behandle ei supernode-adresse som eit proxy-endepunkt gjev same avvising med eit ekstra steg med forvirring.

Ei rute kan ikkje utføre eit handtrykk

Sjølv med rett adresse er ruting ikkje proxying. Ein HTTP-proxyforbindelse byrjar med ein CONNECT-førespurnad eller ei førespurnadslinje i absolutt form, og ein SOCKS-proxy byrjar med forhandling om versjon og metode. Ein ruter eller eit overlay sender byte vidare; han parsar ikkje desse meldingane og opnar ikkje det vidare sambandet for deg. Difor kan ei rute som verkar for ping og SSH framleis feile for ein nettlesarproxy: nettlesaren treng ein samarbeidande prosess, ikkje berre tilgjenge.

Viss målet berre er å nå ei teneste på peeren, fjern proxyinnstillinga og bruk overlay-adressa til tenesta direkte.

Test grensene i rekkjefølgje

Stadfest at overlay-adressa svarar, stadfest deretter at det finst ein lyttar på den konfigurerte porten og noter bind-adressa hans. Gjer éin kontrollert førespurnad og les proxy-loggen, slik at du veit om feilen ligg hos lyttaren eller ved den vidare hentinga. Til slutt, kontroller ruta til proxyverten og DNS-policyen for opphavet.

N2N-prosjektet dokumenterer kantar og supernodar som overlay-komponentar. Det gjer ikkje ein kant til ein applikasjonsproxy, og ingen rutekonfigurasjon legg til ein protokollhandterar som ingen har starta.