Një overlay N2N nuk është proxy: vizato të dyja lidhjet

Firefox tregon drejt 127.0.0.1:8000, skaji N2N është aktiv, partneri përgjigjet ndaj një ping në adresën e tij të overlay-it, dhe shfletuesi vazhdon të raportojë se proxy-i e refuzoi lidhjen. Asgjë në atë zinxhir nuk është kontradiktore. Një overlay i jep një hosti një adresë të arritshme në një rrjet privat; ai nuk krijon një proces që flet protokollin e proxy-it. Shfletuesi nuk po kërkon një rrugë drejt një partneri. Po kërkon një dëgjues lokal.

Këtu ngatërrohen dy lidhje, dhe vizatimi i tyre veçmas sqaron pjesën më të madhe të konfuzionit në një minutë.

Dy lidhje, jo një

Lidhja e parë shkon nga shfletuesi te çdo gjë që dëgjon në portën loopback. Ky është një socket lokal, dhe nëse asgjë nuk e zotëron, lidhja refuzohet para se edhe një paketë të arrijë N2N. E dyta shkon nga procesi i proxy-it te origjina që po merr. Atë rrugë e zgjedh tabela e rrugëtimit e hostit të proxy-it, dhe mund të jetë uplink-u i zakonshëm, një tunel tjetër ose një rrugë politike që nuk ka asnjë lidhje me overlay-in.

Ping-u drejt partnerit provon që overlay-i mund të dorëzojë paketa midis adresave të skajit. Nuk provon asgjë për një dëgjues në portën 8000, dhe as nëse ai host mund të arrijë origjinën. Dështime të ndara, rregullime të ndara.

Ku duhet të jetojë dëgjuesi

Një proxy i lidhur me 127.0.0.1 është qëllimisht lokal: pranon lidhje vetëm nga makina ku ekzekutohet. Ky është parazgjedhja e saktë për një proxy personal dhe forma e gabuar për ta ndarë përmes një overlay-i. Shërbimi i partnerëve të overlay-it kërkon ose një adresë bind në ndërfaqen e overlay-it ose një komponent përcjellës që përfundon lidhjen loopback dhe e përcjell atë. Në çdo rast, një politikë e qartë duhet të vendosë cilat burime të overlay-it mund të përdorin shërbimin, sepse një proxy i hapur në një rrjet të përbashkët është ftesë.

Kontrolloni bind-in aktual me një listë socket-esh dhe jo me skedarin e konfigurimit. Një daemon i nisur përpara se overlay-i të ngrihej mund të jetë ende i lidhur me një adresë që nuk ekziston më.

localhost nuk është partneri

Në fushën e proxy-it të shfletuesit, localhost tregon makinën e vetë shfletuesit. Nuk është skaji, nuk është supernode-i dhe nuk është hosti në skajin e largët të tunelit. Nëse proxy-i ekzekutohet në një partner tjetër, vendosni në fushë adresën e arritshme të overlay-it dhe portën e atij partneri, pastaj konfirmoni që dëgjuesi pranon lidhje nga adresa e skajit tuaj.

Supernode-t ndihmojnë skajet të gjejnë njëri-tjetrin; ata nuk janë shërbim proxy. Trajtimi i një adrese supernode si pikë fundore proxy prodhon të njëjtin refuzim me një hap shtesë konfuzioni.

Një rrugë nuk mund të kryejë handshake

Edhe me adresën e saktë, rrugëtimi nuk është proxying. Një lidhje proxy HTTP fillon me një kërkesë CONNECT ose një rresht kërkese në formë absolute, dhe një proxy SOCKS fillon me një negocim versioni dhe metode. Një router ose një overlay përcjell bajt; ai nuk i analizon ato mesazhe dhe nuk e hap lidhjen pasardhëse në vendin tuaj. Kjo është arsyeja pse një rrugë që funksionon për ping dhe SSH mund të dështojë për një proxy shfletuesi: shfletuesi ka nevojë për një proces bashkëpunues, jo vetëm për arritshmëri.

Nëse qëllimi është vetëm të arrihet një shërbim te partneri, hiqni cilësimin e proxy-it dhe përdorni drejtpërdrejt adresën e overlay-it të shërbimit.

Testoni kufijtë sipas radhës

Konfirmoni që adresa e overlay-it përgjigjet, pastaj konfirmoni që ekziston një dëgjues në portën e konfiguruar dhe shënoni adresën e tij bind. Bëni një kërkesë të kontrolluar dhe lexoni regjistrin e proxy-it, që të dini nëse dështimi është te dëgjuesi apo te marrja pasardhëse. Së fundi, kontrolloni rrugën e hostit të proxy-it dhe politikën DNS për origjinën.

Projekti N2N dokumenton skajet dhe supernode-t si komponentë të overlay-it. Ai nuk e kthen një skaj në proxy aplikacioni, dhe asnjë konfigurim rrugëtimi nuk shton një trajtues protokolli që askush nuk e ka nisur.