Un overlay N2N nu este un proxy: desenează ambele conexiuni

Firefox indică spre 127.0.0.1:8000, marginea N2N este activă, peer-ul răspunde la un ping pe adresa sa de overlay, iar browserul raportează în continuare că proxy-ul a refuzat conexiunea. Nimic din acel lanț nu este contradictoriu. Un overlay oferă unui host o adresă accesibilă într-o rețea privată; nu creează un proces care vorbește protocolul proxy. Browserul nu cere o rută către un peer. Cere un listener local.

Aici sunt confundate două conexiuni, iar desenarea lor separat clarifică cea mai mare parte a confuziei într-un minut.

Două conexiuni, nu una

Prima conexiune merge de la browser la ceea ce ascultă pe portul loopback. Este un socket local, iar dacă nimic nu îl deține, conexiunea este refuzată înainte ca un singur pachet să ajungă la N2N. A doua merge de la procesul proxy la originea pe care o aduce. Acea cale este aleasă de tabela de rutare a hostului proxy și poate fi uplink-ul obișnuit, un alt tunel sau o rută de politică fără nicio legătură cu overlay-ul.

A face ping către peer dovedește că overlay-ul poate livra pachete între adresele marginii. Nu dovedește nimic despre un listener pe portul 8000 și nici despre faptul că acel host poate ajunge la origine. Defecțiuni separate, remedieri separate.

Unde trebuie să locuiască listener-ul

Un proxy legat de 127.0.0.1 este în mod deliberat local: acceptă conexiuni doar de pe mașina pe care rulează. Acesta este implicitul corect pentru un proxy personal și forma greșită de a-l partaja printr-un overlay. Deservirea peer-ilor din overlay necesită fie o adresă de bind pe interfața overlay, fie o componentă de redirecționare care încheie conexiunea loopback și o retransmite. În orice caz, o politică explicită ar trebui să decidă ce surse de overlay pot folosi serviciul, pentru că un proxy deschis într-o rețea partajată este o invitație.

Verificați bind-ul real cu o listă de socket-uri, nu cu fișierul de configurare. Un daemon pornit înainte ca overlay-ul să urce poate fi încă legat de o adresă care nu mai există.

localhost nu este peer-ul

În câmpul de proxy al browserului, localhost indică mașina browserului însuși. Nu este marginea, nu este supernode-ul și nu este hostul de la capătul îndepărtat al tunelului. Dacă proxy-ul rulează pe alt peer, puneți în câmp adresa de overlay accesibilă și portul acelui peer, apoi confirmați că listener-ul acceptă conexiuni de la adresa marginii dvs.

Supernode-urile ajută marginile să se găsească reciproc; ele nu sunt un serviciu proxy. Tratarea unei adrese de supernode ca punct final de proxy produce același refuz cu un pas suplimentar de confuzie.

O rută nu poate efectua un handshake

Chiar și cu adresa corectă, rutarea nu este proxying. O conexiune proxy HTTP începe cu o cerere CONNECT sau cu o linie de cerere în formă absolută, iar un proxy SOCKS începe cu o negociere a versiunii și a metodei. Un router sau un overlay transmite octeți; nu analizează acele mesaje și nu deschide următoarea conexiune în locul dvs. De aceea o rută care funcționează pentru ping și SSH poate eșua totuși pentru un proxy de browser: browserul are nevoie de un proces cooperant, nu doar de accesibilitate.

Dacă scopul este doar să ajungeți la un serviciu pe peer, eliminați setarea de proxy și folosiți direct adresa de overlay a serviciului.

Testați limitele în ordine

Confirmați că adresa de overlay răspunde, apoi confirmați că există un listener pe portul configurat și notați adresa lui de bind. Faceți o cerere controlată și citiți jurnalul proxy-ului, ca să știți dacă defecțiunea este la listener sau la preluarea ulterioară. În final, verificați ruta hostului proxy și politica DNS pentru origine.

Proiectul N2N documentează marginile și supernode-urile ca componente de overlay. Nu transformă o margine într-un proxy de aplicație și nicio configurație de rutare nu adaugă un handler de protocol pe care nimeni nu l-a pornit.