’n N2N-overlay is nie ’n proxy nie: teken albei verbindings

Firefox wys na 127.0.0.1:8000, die N2N-rand is aan, die eweknie antwoord op ’n ping op sy overlay-adres, en die blaaier meld steeds dat die proxy die verbinding geweier het. Niks in daardie ketting is teenstrydig nie. ’n Overlay gee ’n gasheer ’n bereikbare adres op ’n private netwerk; dit skep nie ’n proses wat die proxy-protokol praat nie. Die blaaier vra nie na ’n roete na ’n eweknie nie. Dit vra na ’n plaaslike luisteraar.

Twee verbindings word hier verwar, en om hulle apart te teken verduidelik die meeste van die verwarring binne ’n minuut.

Twee verbindings, nie een nie

Die eerste verbinding loop van die blaaier na wat ook al op die loopback-poort luister. Dit is ’n plaaslike sokkel, en as niks dit besit nie, word die verbinding geweier voordat ’n enkele pakkie N2N bereik. Die tweede loop van die proxy-proses na die oorsprong wat dit haal. Daardie pad word deur die proxy-gasheer se roetertabel gekies, en dit kan die gewone opstroom wees, ’n ander tonnel, of ’n beleidsroete wat niks met die overlay te doen het nie.

Om die eweknie te ping bewys dat die overlay pakkies tussen randadresse kan aflewer. Dit bewys niks oor ’n luisteraar op poort 8000 nie, en niks oor of daardie gasheer die oorsprong kan bereik nie. Aparte foute, aparte regstellings.

Waar die luisteraar moet woon

’n Proxy wat aan 127.0.0.1 gebind is, is doelbewus plaaslik: dit aanvaar verbindings net van die masjien waar dit loop. Dit is die regte verstek vir ’n persoonlike proxy en die verkeerde vorm om een oor ’n overlay te deel. Om overlay-eweknieë te bedien, het ’n mens óf ’n bindadres op die overlay-koppelvlak óf ’n deurvoerkomponent nodig wat die loopback-verbinding beëindig en dit deurgee. Hoe dit ook al sy, ’n eksplisiete beleid moet besluit watter overlay-bronne die diens mag gebruik, want ’n oop proxy op ’n gedeelde netwerk is ’n uitnodiging.

Kontroleer die werklike binding met ’n sokkellys eerder as die konfigurasielêer. ’n Daemon wat begin het voordat die overlay opgekom het, kan steeds aan ’n adres gebind wees wat nie meer bestaan nie.

localhost is nie die eweknie nie

In die blaaier se proxy-veld wys localhost na die blaaier se eie masjien. Dit is nie die rand nie, nie die supernode nie, en nie die gasheer aan die verre kant van die tonnel nie. As die proxy op ’n ander eweknie loop, sit daardie eweknie se bereikbare overlay-adres en poort in die veld, en bevestig dan dat die luisteraar verbindings van jou randadres aanvaar.

Supernodes help rande om mekaar te vind; hulle is nie ’n proxy-diens nie. Om ’n supernode-adres as ’n proxy-eindpunt te behandel, lewer dieselfde weiering met ’n ekstra sprong van verwarring.

’n Roete kan nie ’n handdruk uitvoer nie

Selfs met die adres reg is roetering nie proxy nie. ’n HTTP-proxyverbinding begin met ’n CONNECT-versoek of ’n versoekreël in absolute vorm, en ’n SOCKS-proxy begin met ’n weergawe- en metode-onderhandeling. ’n Roeteerder of ’n overlay stuur grepe aan; dit ontleed nie daardie boodskappe nie en maak nie die verder verbinding vir jou oop nie. Daarom kan ’n roete wat vir ping en SSH werk, steeds vir ’n blaaier-proxy misluk: die blaaier het ’n samewerkende proses nodig, nie bloot bereikbaarheid nie.

As die doel net is om ’n diens op die eweknie te bereik, verwyder die proxy-instelling en gebruik die diens se overlay-adres direk.

Toets die grense in volgorde

Bevestig dat die overlay-adres antwoord, bevestig dan dat ’n luisteraar op die gekonfigureerde poort bestaan en let op sy bindadres. Maak een beheerde versoek en lees die proxy se log, sodat jy weet of die fout by die luisteraar of by die verdere ophaal sit. Kyk laastens na die proxy-gasheer se roete en DNS-beleid vir die oorsprong.

Die N2N-projek dokumenteer rande en supernodes as overlay-komponente. Dit verander nie ’n rand in ’n toepassingproxy nie, en geen roeteringskonfigurasie voeg ’n protokolhanteerder by wat niemand begin het nie.