Unha superposición N2N non é un proxy: debuxa as dúas conexións

Firefox apunta a 127.0.0.1:8000, o bordo N2N está activo, o par responde a un ping no seu enderezo de superposición, e o navegador segue informando de que o proxy rexeitou a conexión. Nada nesa cadea é contradictorio. Unha superposición dálle a unha máquina un enderezo alcanzable nunha rede privada; non crea un proceso que fale o protocolo do proxy. O navegador non pide unha ruta cara a un par. Pide un oínte local.

Aquí confúndense dúas conexións, e debuxalas por separado aclara a maior parte da confusión nun minuto.

Dúas conexións, non unha

A primeira conexión vai do navegador ao que escoita no porto de loopback. É un socket local, e se nada o posúe, a conexión rexéitase antes de que un só paquete chegue a N2N. A segunda vai do proceso do proxy á orixe que obtén. Ese camiño elíxeo a táboa de encamiñamento do host do proxy, e pode ser a conexión ascendente habitual, outro túnel ou unha ruta de política que non ten nada que ver coa superposición.

Facer ping ao par demostra que a superposición pode entregar paquetes entre enderezos de bordo. Non demostra nada sobre un oínte no porto 8000, nin sobre se ese host pode chegar á orixe. Fallos separados, correccións separadas.

Onde ten que vivir o oínte

Un proxy ligado a 127.0.0.1 é deliberadamente local: só acepta conexións da máquina onde se executa. É o valor predeterminado correcto para un proxy persoal e a forma incorrecta de compartilo por unha superposición. Servir pares da superposición require ou ben un enderezo de vinculación na interface de superposición ou ben un compoñente de reenvío que remate a conexión de loopback e a retransmita. En calquera caso, unha política explícita debería decidir que fontes de superposición poden usar o servizo, porque un proxy aberto nunha rede compartida é unha invitación.

Comprobe a vinculación real cunha listaxe de sockets en lugar do ficheiro de configuración. Un daemon iniciado antes de que a superposición subise pode seguir ligado a un enderezo que xa non existe.

localhost non é o par

No campo de proxy do navegador, localhost apunta á máquina do propio navegador. Non é o bordo, nin o supernodo, nin o host do extremo afastado do túnel. Se o proxy se executa noutro par, poña no campo o enderezo de superposición alcanzable e o porto dese par, e despois confirme que o oínte acepta conexións desde o enderezo do seu bordo.

Os supernodos axudan aos bordos a atoparse; non son un servizo de proxy. Tratar un enderezo de supernodo como punto final de proxy produce o mesmo rexeitamento cun salto extra de confusión.

Unha ruta non pode realizar un handshake

Mesmo co enderezo correcto, o encamiñamento non é facer de proxy. Unha conexión de proxy HTTP comeza cunha solicitude CONNECT ou unha liña de solicitude en forma absoluta, e un proxy SOCKS comeza cunha negociación de versión e método. Un encamiñador ou unha superposición reenvía bytes; non analiza esas mensaxes nin abre a conexión seguinte por vostede. Por iso unha ruta que funciona para ping e SSH pode fallar para un proxy do navegador: o navegador necesita un proceso cooperativo, non só alcanzabilidade.

Se o obxectivo é só chegar a un servizo no par, quite a configuración de proxy e use directamente o enderezo de superposición do servizo.

Probe os límites por orde

Confirme que o enderezo de superposición responde, despois confirme que existe un oínte no porto configurado e anote o seu enderezo de vinculación. Faga unha solicitude controlada e lea o rexistro do proxy, para saber se o fallo está no oínte ou na obtención posterior. Por último, comprobe a ruta do host do proxy e a política de DNS para a orixe.

O proxecto N2N documenta bordos e supernodos como compoñentes de superposición. Non converte un bordo nun proxy de aplicacións, e ningunha configuración de encamiñamento engade un xestor de protocolo que ninguén iniciou.