Un overlay N2N non è un proxy: disegna entrambe le connessioni

Firefox punta a 127.0.0.1:8000, l’edge N2N è attivo, il peer risponde a un ping sul suo indirizzo overlay, e il browser continua a segnalare che il proxy ha rifiutato la connessione. Niente in questa catena è contraddittorio. Un overlay dà a un host un indirizzo raggiungibile su una rete privata; non crea un processo che parli il protocollo del proxy. Il browser non chiede una rotta verso un peer. Chiede un listener locale.

Qui vengono confuse due connessioni, e disegnarle separatamente chiarisce la maggior parte della confusione in un minuto.

Due connessioni, non una

La prima connessione va dal browser a ciò che ascolta sulla porta loopback. È un socket locale, e se nulla lo possiede, la connessione viene rifiutata prima che un solo pacchetto raggiunga N2N. La seconda va dal processo proxy all’origine che sta recuperando. Quel percorso è scelto dalla tabella di routing dell’host proxy, e può essere l’uplink ordinario, un altro tunnel o una rotta di policy che non ha nulla a che vedere con l’overlay.

Fare ping al peer dimostra che l’overlay può consegnare pacchetti tra indirizzi di edge. Non dimostra nulla su un listener sulla porta 8000, né sul fatto che quell’host possa raggiungere l’origine. Guasti separati, correzioni separate.

Dove deve vivere il listener

Un proxy legato a 127.0.0.1 è deliberatamente locale: accetta connessioni solo dalla macchina su cui gira. È il default giusto per un proxy personale e la forma sbagliata per condividerlo su un overlay. Servire peer dell’overlay richiede o un indirizzo di bind sull’interfaccia overlay o un componente di inoltro che termini la connessione loopback e la rilancia. In ogni caso, una policy esplicita dovrebbe decidere quali sorgenti overlay possono usare il servizio, perché un proxy aperto su una rete condivisa è un invito.

Controlla il bind reale con un elenco di socket invece del file di configurazione. Un daemon avviato prima che l’overlay salisse può essere ancora legato a un indirizzo che non esiste più.

localhost non è il peer

Nel campo proxy del browser, localhost punta alla macchina del browser stesso. Non è l’edge, non è il supernode e non è l’host all’estremità remota del tunnel. Se il proxy gira su un altro peer, inserisci nel campo l’indirizzo overlay raggiungibile e la porta di quel peer, poi conferma che il listener accetta connessioni dall’indirizzo del tuo edge.

I supernode aiutano gli edge a trovarsi; non sono un servizio proxy. Trattare un indirizzo di supernode come endpoint proxy produce lo stesso rifiuto con un salto di confusione in più.

Una rotta non può eseguire un handshake

Anche con l’indirizzo giusto, il routing non è proxying. Una connessione proxy HTTP inizia con una richiesta CONNECT o una riga di richiesta in forma assoluta, e un proxy SOCKS inizia con una negoziazione di versione e metodo. Un router o un overlay inoltra byte; non analizza quei messaggi né apre la connessione successiva al posto tuo. Ecco perché una rotta che funziona per ping e SSH può comunque fallire per un proxy del browser: il browser ha bisogno di un processo cooperativo, non solo della raggiungibilità.

Se l’obiettivo è solo raggiungere un servizio sul peer, rimuovi l’impostazione del proxy e usa direttamente l’indirizzo overlay del servizio.

Prova i confini in ordine

Verifica che l’indirizzo overlay risponda, poi verifica che esista un listener sulla porta configurata e annota il suo indirizzo di bind. Fai una richiesta controllata e leggi il log del proxy, per sapere se il guasto è nel listener o nel recupero successivo. Infine, controlla la rotta dell’host proxy e la policy DNS per l’origine.

Il progetto N2N documenta edge e supernode come componenti overlay. Non trasforma un edge in un proxy applicativo, e nessuna configurazione di routing aggiunge un gestore di protocollo che nessuno ha avviato.