In N2N-oerlaach is gjin proxy: teken beide ferbiningen

Firefox wiist nei 127.0.0.1:8000, de N2N-râne is oan, de peer antwurdet op in ping op syn oerlaachadres, en de browser meldt noch altyd dat de proxy de ferbining wegere hat. Neat yn dy keatling is tsjinstridich. In oerlaach jout in host in berikber adres op in priveenetwurk; it makket gjin proses dat it proxyprotokol sprekt. De browser freget net om in rûte nei in peer. Hy freget om in lokale listener.

Hjir wurde twa ferbiningen trochinoar helle, en se apart tekenje makket it measte fan 'e betizing yn in minút dúdlik.

Twa ferbiningen, net ien

De earste ferbining rint fan de browser nei wat op de loopback-poarte harket. Dat is in lokale socket, en as neat it hat, wurdt de ferbining wegere foardat ien pakket N2N berikt. De twadde rint fan it proxyproses nei de oarsprong dy't it hellet. Dy wei wurdt keazen troch de routingtabel fan 'e proxyhost, en it kin de gewoane uplink wêze, in oare tunnel, of in beliedsrûte dy't neat mei it oerlaach te krijen hat.

Pingje nei de peer bewiist dat it oerlaach pakketten tusken râne-adressen leverje kin. It bewiist neat oer in listener op poarte 8000, en neat oer oft dy host de oarsprong berikke kin. Aparte flaters, aparte oplossings.

Wêr't de listener wenje moat

In proxy fêstbûn oan 127.0.0.1 is bewust lokaal: it akseptearret ferbiningen allinnich fan 'e masine dêr't it op rint. Dat is de juste standert foar in persoanlike proxy en de ferkearde foarm om ien oer in oerlaach te dielen. Om oerlaach-peers te betsjinjen is itsij in bindadres op 'e oerlaach-ynterface nedich, itsij in troerstjoerkomponint dat de loopback-ferbining beëiniget en troerstjoert. Hoe dan ek, in eksplisyt belied moat beslute hokker oerlaachboarnen de tsjinst brûke meie, want in iepen proxy op in dield netwurk is in útnûging.

Kontrolearje de wiere bind mei in socketlist ynstee fan it konfiguraasjebestân. In daemon dy't starte foardat it oerlaach omheech kaam, kin noch bûn wêze oan in adres dat net mear bestiet.

localhost is net de peer

Yn it proxyfjild fan 'e browser wiist localhost nei de masine fan 'e browser sels. It is net de râne, net de supernode, en net de host oan 'e fierste ein fan 'e tunnel. As de proxy op in oare peer rint, set dan it berikbere oerlaachadres en de poarte fan dy peer yn it fjild, en befêstigje dan dat de listener ferbiningen fan jo râne-adres akseptearret.

Supernodes helpe rânen om inoar te finen; se binne gjin proxystsjinst. In supernode-adres as proxy-einpunt behannelje jout deselde wegering mei in ekstra hop betizing.

In rûte kin gjin handshake dwaan

Sels mei it juste adres is routing gjin proxying. In HTTP-proxyferbining begjint mei in CONNECT-fersyk of in fersyklien yn absolute foarm, en in SOCKS-proxy begjint mei in oerlis oer ferzje en metoade. In router of in oerlaach stjoert bytes troch; it parset dy berjochten net en iepenet de folgjende ferbining net foar jo. Dêrom kin in rûte dy't foar ping en SSH wurket, noch mislearje foar in browserproxy: de browser hat in gearwurkjend proses nedich, net allinnich berikberens.

As it doel gewoan is in tsjinst op 'e peer te berikken, ferwiderje dan de proxy-ynstelling en brûk it oerlaachadres fan 'e tsjinst direkt.

Test de grinzen yn folchoarder

Befêstigje dat it oerlaachadres antwurdet, befêstigje dan dat der in listener op 'e konfigurearre poarte is en notearje syn bindadres. Doch ien kontrolearre fersyk en lês it proxylog, sadat jo witte oft de flater by de listener of by it fierdere heljen sit. Kontrolearje ta beslút de rûte fan 'e proxyhost en it DNS-belied foar de oarsprong.

It N2N-projekt dokumintearret rânen en supernodes as oerlaachkomponinten. It makket fan in râne gjin applikaasjeproxy, en gjin routeringskonfiguraasje foeget in protokolbehanneler ta dy't nimmen start hat.