Una superposición N2N no es un proxy: dibuja ambas conexiones

Firefox apunta a 127.0.0.1:8000, el borde N2N está activo, el par responde a un ping en su dirección de superposición y el navegador sigue informando de que el proxy rechazó la conexión. Nada en esa cadena es contradictorio. Una superposición da a un host una dirección alcanzable en una red privada; no crea un proceso que hable el protocolo del proxy. El navegador no pide una ruta hacia un par. Pide un oyente local.

Aquí se confunden dos conexiones, y dibujarlas por separado aclara la mayor parte de la confusión en un minuto.

Dos conexiones, no una

La primera conexión va del navegador a lo que escucha en el puerto de loopback. Es un socket local, y si nada lo posee, la conexión se rechaza antes de que un solo paquete llegue a N2N. La segunda va del proceso del proxy al origen que obtiene. Ese camino lo elige la tabla de enrutamiento del host del proxy, y puede ser el enlace ascendente habitual, otro túnel o una ruta de política que no tiene nada que ver con la superposición.

Hacer ping al par demuestra que la superposición puede entregar paquetes entre direcciones de borde. No demuestra nada sobre un oyente en el puerto 8000, ni sobre si ese host puede llegar al origen. Fallos separados, correcciones separadas.

Dónde tiene que vivir el oyente

Un proxy vinculado a 127.0.0.1 es deliberadamente local: solo acepta conexiones de la máquina donde se ejecuta. Es el valor predeterminado correcto para un proxy personal y la forma incorrecta de compartirlo por una superposición. Servir pares de la superposición requiere o bien una dirección de enlace en la interfaz de superposición o bien un componente de reenvío que termine la conexión de loopback y la retransmita. En cualquier caso, una política explícita debería decidir qué fuentes de superposición pueden usar el servicio, porque un proxy abierto en una red compartida es una invitación.

Compruebe el enlace real con un listado de sockets en lugar del archivo de configuración. Un demonio iniciado antes de que la superposición subiera puede seguir vinculado a una dirección que ya no existe.

localhost no es el par

En el campo de proxy del navegador, localhost apunta a la máquina del propio navegador. No es el borde, ni el supernodo, ni el host del extremo lejano del túnel. Si el proxy se ejecuta en otro par, ponga en el campo la dirección de superposición alcanzable y el puerto de ese par, y luego confirme que el oyente acepta conexiones desde la dirección de su borde.

Los supernodos ayudan a los bordes a encontrarse; no son un servicio de proxy. Tratar una dirección de supernodo como punto final de proxy produce el mismo rechazo con un salto extra de confusión.

Una ruta no puede realizar un handshake

Incluso con la dirección correcta, el enrutamiento no es proxying. Una conexión de proxy HTTP comienza con una solicitud CONNECT o una línea de solicitud en forma absoluta, y un proxy SOCKS comienza con una negociación de versión y método. Un enrutador o una superposición reenvía bytes; no analiza esos mensajes ni abre la conexión siguiente por usted. Por eso una ruta que funciona para ping y SSH puede fallar para un proxy del navegador: el navegador necesita un proceso cooperativo, no solo alcanzabilidad.

Si el objetivo es solo llegar a un servicio del par, quite la configuración de proxy y use directamente la dirección de superposición del servicio.

Pruebe los límites en orden

Confirme que la dirección de superposición responde, luego confirme que existe un oyente en el puerto configurado y anote su dirección de enlace. Haga una solicitud controlada y lea el registro del proxy, para saber si el fallo está en el oyente o en la obtención posterior. Por último, compruebe la ruta del host del proxy y la política de DNS para el origen.

El proyecto N2N documenta bordes y supernodos como componentes de superposición. No convierte un borde en un proxy de aplicaciones, y ninguna configuración de enrutamiento añade un manejador de protocolo que nadie haya iniciado.