Firefoxek 127.0.0.1:8000 helbidera egiten du, N2N ertza martxan dago, pareak ping bati erantzuten dio bere gainjarri helbidean, eta nabigatzaileak oraindik dio proxyak konexioa ukatu duela. Kate horretan ez dago ezer kontraesankorrik. Gainjarri batek ostalariari helbide irisgarria ematen dio sare pribatu batean; ez du proxy protokoloa hitz egiten duen prozesurik sortzen. Nabigatzailea ez dago parearekiko bide bat eskatzen. Entzule lokal bat eskatzen ari da.

Hemen bi konexio nahasten dira, eta bereiz marrazteak nahasmenaren zatirik handiena argitzen du minutu batean.

Bi konexio, ez bat

Lehen konexioa nabigatzailetik loopback atakan entzuten duenera doa. Socket lokala da, eta ezerk ez badu edukitzen, konexioa ukatzen da pakete bakar bat N2N-ra iritsi aurretik. Bigarrena proxy prozesutik lortzen duen jatorrira doa. Bide hori proxy ostalariaren bideratze-taulak aukeratzen du, eta ohiko uplink-a, beste tunel bat edo gainjarriarekin zerikusirik ez duen politika-bide bat izan daiteke.

Pareari ping egiteak frogatzen du gainjarriak paketeak ertz-helbideen artean entregatu ditzakeela. Ez du ezer frogatzen 8000 atakako entzule bati buruz, ezta ostalari horrek jatorrira irits daitekeenik ere. Hutsegite bereiziak, konponketa bereiziak.

Non bizi behar duen entzuleak

127.0.0.1-ra lotutako proxy bat nahita lokala da: soilik exekutatzen den makinaren konexioak onartzen ditu. Hori da proxy pertsonal baterako lehenespen zuzena eta gainjarri baten bidez partekatzeko forma okerra. Gainjarriaren pareei zerbitzua emateko, gainjarriaren interfazean bind helbide bat edo loopback konexioa amaitzen duen eta birbidaltzen duen osagai bat behar da. Edonola ere, politika esplizitu batek erabaki beharko luke zein gainjarri iturrik erabil dezaketen zerbitzua, sare partekatu batean proxy irekia gonbidapena baita.

Egiaztatu benetako bind-a socket zerrendarekin, konfigurazio fitxategiarekin beharrean. Gainjarria altxatu aurretik abiatutako daemon bat oraindik existitzen ez den helbide batera lotuta egon daiteke.

localhost ez da parea

Nabigatzailearen proxy eremuan, localhost-ek nabigatzailearen makina propiora egiten du. Ez da ertza, ez da supernodea, eta ez da tunelaren urruneko muturreko ostalaria. Proxy-a beste pare batean exekutatzen bada, jarri eremuan pare horren gainjarri helbide irisgarria eta ataka, eta gero egiaztatu entzuleak zure ertz-helbidetik konexioak onartzen dituela.

Supernodeek ertzei elkar aurkitzen laguntzen diete; ez dira proxy zerbitzu bat. Supernode helbide bat proxy amaiera-puntu gisa tratatzeak ukapen bera ematen du, nahasmen jauzi gehigarri batekin.

Bide batek ezin du handshake bat egin

Helbidea zuzena izanik ere, bideratzea ez da proxya egitea. HTTP proxy konexio bat CONNECT eskaera batekin edo forma absolutuko eskaera-lerro batekin hasten da, eta SOCKS proxy bat bertsio eta metodo negoziazioarekin hasten da. Bideratzaile edo gainjarri batek byteak birbidaltzen ditu; ez ditu mezu horiek aztertzen ezta zuretzat hurrengo konexioa irekitzen ere. Horregatik, ping eta SSH-rako funtzionatzen duen bide batek huts egin dezake nabigatzailearen proxy baterako: nabigatzaileak lankidetzan aritzen den prozesu bat behar du, ez bakarrik irisgarritasuna.

Helburua pareko zerbitzu batera iristea bada soilik, kendu proxy ezarpena eta erabili zerbitzuaren gainjarri helbidea zuzenean.

Probatu mugak ordenan

Egiaztatu gainjarri helbideak erantzuten duela, gero egiaztatu konfiguratutako atakan entzule bat badagoela eta idatzi haren bind helbidea. Egin eskaera kontrolatu bat eta irakurri proxyaren egunkaria, hutsegitea entzulean edo hurrengo eskuratzean dagoen jakiteko. Azkenik, egiaztatu proxy ostalariaren bidea eta jatorrirako DNS politika.

N2N proiektuak ertzak eta supernodeak gainjarri osagai gisa dokumentatzen ditu. Ez du ertza aplikazio proxy bihurtzen, eta inork abiatu ez duen protokolo kudeatzailerik ez du gehitzen bideratze konfigurazioak.

Erlazionatutako artikuluak