Overlay N2N není proxy: nakreslete obě spojení

Firefox míří na 127.0.0.1:8000, hrana N2N je aktivní, peer odpovídá na ping na své overlay adrese a prohlížeč stále hlásí, že proxy odmítla spojení. V tom řetězu není nic protichůdného. Overlay dává hostiteli dosažitelnou adresu v privátní síti; nevytváří proces, který mluví protokolem proxy. Prohlížeč nežádá trasu k peerovi. Žádá lokální listener.

Zde se pletou dvě spojení a jejich samostatné nakreslení vyjasní většinu zmatku během minuty.

Dvě spojení, ne jedno

První spojení vede z prohlížeče k čemukoli, co naslouchá na loopback portu. To je lokální socket, a pokud ho nic nevlastní, spojení je odmítnuto dřív, než jediný paket dorazí do N2N. Druhé vede z procesu proxy k originu, který stahuje. Tu cestu vybírá směrovací tabulka hostitele proxy a může to být běžný uplink, jiný tunel nebo policy route, která s overlay nemá nic společného.

Ping na peera dokazuje, že overlay umí doručovat pakety mezi adresami hran. Nedokazuje nic o listeneru na portu 8000 ani o tom, zda se tento hostitel dostane k originu. Oddělené poruchy, oddělené opravy.

Kde musí listener žít

Proxy navázaná na 127.0.0.1 je záměrně lokální: přijímá spojení jen ze stroje, na kterém běží. To je správný výchozí stav pro osobní proxy a špatný tvar pro sdílení přes overlay. Obsluha peerů overlaye vyžaduje buď bind adresu na rozhraní overlaye, nebo forwardovací komponentu, která ukončí loopback spojení a přepošle ho. Ať tak či onak, explicitní politika by měla rozhodnout, které zdroje overlaye smějí službu používat, protože otevřená proxy ve sdílené síti je pozvánka.

Skutečný bind zkontrolujte výpisem socketů, ne konfiguračním souborem. Démon spuštěný před náběhem overlaye může být stále navázán na adresu, která už neexistuje.

localhost není peer

V poli proxy v prohlížeči localhost ukazuje na stroj samotného prohlížeče. Není to hrana, není to supernode a není to hostitel na vzdáleném konci tunelu. Pokud proxy běží na jiném peerovi, vložte do pole dosažitelnou overlay adresu a port tohoto peera a poté ověřte, že listener přijímá spojení z adresy vaší hrany.

Supernody pomáhají hranám najít se navzájem; nejsou to proxy služba. Zacházení s adresou supernody jako s koncovým bodem proxy dává stejné odmítnutí s dalším skokem zmatku.

Ruta nemůže provést handshake

I se správnou adresou není směrování proxying. Spojení HTTP proxy začíná požadavkem CONNECT nebo řádkem požadavku v absolutním tvaru a proxy SOCKS začíná vyjednáváním verze a metody. Router nebo overlay přeposílá bajty; neparsuje ty zprávy ani za vás neotevře navazující spojení. Proto ruta, která funguje pro ping a SSH, může u proxy v prohlížeči selhat: prohlížeč potřebuje spolupracující proces, ne jen dosažitelnost.

Pokud je cílem jen dosáhnout služby na peerovi, odstraňte nastavení proxy a použijte overlay adresu služby přímo.

Testujte hranice popořadě

Ověřte, že overlay adresa odpovídá, potom ověřte, že na nakonfigurovaném portu existuje listener, a poznamenejte jeho bind adresu. Udělejte jeden řízený požadavek a přečtěte log proxy, abyste věděli, zda je porucha v listeneru, nebo v následném stahování. Nakonec zkontrolujte trasu hostitele proxy a politiku DNS pro origin.

Projekt N2N dokumentuje hrany a supernody jako komponenty overlaye. Nepřevádí hranu na aplikační proxy a žádná konfigurace směrování nepřidává obsluhu protokolu, kterou nikdo nespustil.