Ang overlay na N2N ay hindi proxy: iguhit ang dalawang koneksyon

Itinuturo ng Firefox ang 127.0.0.1:8000, buhay ang gilid ng N2N, sumasagot ang peer sa ping sa overlay address nito, at patuloy pa ring iniuulat ng browser na tinanggihan ng proxy ang koneksyon. Walang kontradiksyon sa chain na iyon. Ang overlay ay nagbibigay sa host ng maabot na address sa pribadong network; hindi ito gumagawa ng prosesong nagsasalita ng proxy protocol. Hindi humihingi ang browser ng ruta patungo sa peer. Humihingi ito ng lokal na listener.

Dalawang koneksyon ang napagkakamalan dito, at ang pagguhit sa kanila nang hiwalay ay naglilinaw sa karamihan ng kalituhan sa isang minuto.

Dalawang koneksyon, hindi isa

Ang unang koneksyon ay mula sa browser patungo sa anumang nakikinig sa loopback port. Iyon ay lokal na socket, at kung walang nagmamay-ari nito, tinatanggihan ang koneksyon bago pa man makarating ang isang packet sa N2N. Ang pangalawa ay mula sa proxy process patungo sa origin na kinukuha nito. Ang rutang iyon ay pinipili ng routing table ng proxy host, at maaaring ito ay ordinaryong uplink, ibang tunnel, o policy route na walang kinalaman sa overlay.

Ang pag-ping sa peer ay nagpapatunay na kayang maghatid ng overlay ng mga packet sa pagitan ng edge address. Wala itong pinapatunayan tungkol sa listener sa port 8000, at wala rin tungkol sa kung maaabot ng host na iyon ang origin. Hiwalay na pagkabigo, hiwalay na pag-aayos.

Saan dapat manirahan ang listener

Ang proxy na naka-bind sa 127.0.0.1 ay sadyang lokal: tumatanggap lamang ito ng koneksyon mula sa machine kung saan ito tumatakbo. Iyon ang tamang default para sa personal na proxy at maling hugis para sa pagbabahagi nito sa overlay. Ang pagseserbisyo sa mga peer ng overlay ay nangangailangan ng alinman sa bind address sa overlay interface o forwarding component na nagtatapos sa loopback connection at nagpapasa nito. Sa alinmang paraan, dapat magpasya ang tahasang patakaran kung aling mga overlay source ang maaaring gumamit ng serbisyo, dahil ang bukas na proxy sa shared network ay isang imbitasyon.

Suriin ang aktwal na bind gamit ang listahan ng socket kaysa sa configuration file. Ang daemon na sinimulan bago umangat ang overlay ay maaaring nakabind pa sa address na wala nang umiiral.

Ang localhost ay hindi ang peer

Sa field ng proxy ng browser, itinuturo ng localhost ang machine ng browser mismo. Hindi ito ang edge, hindi ang supernode, at hindi ang host sa dulong bahagi ng tunnel. Kung tumatakbo ang proxy sa ibang peer, ilagay sa field ang maabot na overlay address at port ng peer na iyon, pagkatapos ay kumpirmahin na tinatanggap ng listener ang mga koneksyon mula sa iyong edge address.

Tinutulungan ng mga supernode ang mga edge na maghanap ng isa't isa; hindi sila serbisyo ng proxy. Ang pagtrato sa address ng supernode bilang proxy endpoint ay gumagawa ng parehong pagtanggi na may dagdag na hakbang ng kalituhan.

Hindi kayang magsagawa ng handshake ang isang ruta

Kahit tama ang address, ang routing ay hindi proxying. Nagsisimula ang koneksyon ng HTTP proxy sa isang CONNECT request o absolute-form request line, at nagsisimula ang SOCKS proxy sa negosasyon ng version at method. Ang router o overlay ay nagpapasa ng bytes; hindi nito sinusuri ang mga mensaheng iyon o binubuksan ang susunod na koneksyon para sa iyo. Iyon ang dahilan kung bakit ang rutang gumagana para sa ping at SSH ay maaari pa ring mabigo para sa proxy ng browser: kailangan ng browser ng kooperatibong proseso, hindi lamang maabot.

Kung ang layunin ay maabot lamang ang isang serbisyo sa peer, alisin ang setting ng proxy at gamitin nang direkta ang overlay address ng serbisyo.

Subukan ang mga hangganan nang sunud-sunod

Kumpirmahin na sumasagot ang overlay address, pagkatapos ay kumpirmahin na may listener sa naka-configure na port at itala ang bind address nito. Gumawa ng isang kontroladong request at basahin ang log ng proxy, upang malaman kung ang pagkabigo ay nasa listener o sa susunod na pagkuha. Sa wakas, suriin ang ruta ng proxy host at ang patakaran ng DNS para sa origin.

Idinodokumento ng proyektong N2N ang mga edge at supernode bilang mga component ng overlay. Hindi nito ginagawang application proxy ang isang edge, at walang configuration ng routing na nagdaragdag ng protocol handler na walang sinuman ang nagsimula.