Una superposició N2N no és un proxy: dibuixa les dues connexions

Firefox apunta a 127.0.0.1:8000, la vora de N2N està activa, el parell respon a un ping a la seva adreça de superposició, i el navegador encara informa que el proxy ha refusat la connexió. Res d’aquesta cadena no és contradictori. Una superposició dóna a un amfitrió una adreça abastable en una xarxa privada; no crea un procés que parli el protocol del proxy. El navegador no demana una ruta cap a un parell. Demana un oient local.

Aquí es confonen dues connexions, i dibuixar-les per separat aclareix la major part de la confusió en un minut.

Dues connexions, no una

La primera connexió va del navegador al que escolta al port de loopback. És un sòcol local, i si res no en és propietari, la connexió es refusa abans que un sol paquet arribi a N2N. La segona va del procés del proxy a l’origen que obté. Aquest camí el tria la taula d’encaminament de l’amfitrió del proxy, i pot ser l’enllaç ascendent habitual, un altre túnel o una ruta de política que no té res a veure amb la superposició.

Fer ping al parell demostra que la superposició pot lliurar paquets entre adreces de vora. No demostra res sobre un oient al port 8000, ni sobre si aquest amfitrió pot arribar a l’origen. Fallades separades, correccions separades.

On ha de viure l’oient

Un proxy lligat a 127.0.0.1 és deliberadament local: només accepta connexions de la màquina on s’executa. És el valor per defecte correcte per a un proxy personal i la forma incorrecta de compartir-lo per una superposició. Servir parells de la superposició requereix o bé una adreça d’enllaç a la interfície de superposició o bé un component de reenviament que acabi la connexió de loopback i la retransmeti. En qualsevol cas, una política explícita hauria de decidir quines fonts de superposició poden usar el servei, perquè un proxy obert en una xarxa compartida és una invitació.

Comproveu l’enllaçament real amb un llistat de sòcols en lloc del fitxer de configuració. Un dimoni iniciat abans que la superposició pugés encara pot estar lligat a una adreça que ja no existeix.

localhost no és el parell

Al camp de proxy del navegador, localhost apunta a la màquina del propi navegador. No és la vora, ni el supernode, ni l’amfitrió de l’extrem llunyà del túnel. Si el proxy s’executa en un altre parell, poseu al camp l’adreça de superposició abastable i el port d’aquell parell, i després confirmeu que l’oient accepta connexions des de l’adreça de la vostra vora.

Els supernodes ajuden les vores a trobar-se; no són un servei de proxy. Tractar una adreça de supernode com a punt final de proxy produeix la mateixa negativa amb un salt extra de confusió.

Una ruta no pot fer un handshake

Fins i tot amb l’adreça correcta, l’encaminament no és fer de proxy. Una connexió de proxy HTTP comença amb una sol·licitud CONNECT o una línia de sol·licitud en forma absoluta, i un proxy SOCKS comença amb una negociació de versió i mètode. Un encaminador o una superposició reenvia octets; no analitza aquests missatges ni obre la connexió següent per vosaltres. És per això que una ruta que funciona per a ping i SSH encara pot fallar per a un proxy del navegador: el navegador necessita un procés col·laborador, no només abastabilitat.

Si l’objectiu és només arribar a un servei del parell, traieu la configuració de proxy i useu directament l’adreça de superposició del servei.

Proveu les fronteres per ordre

Confirmeu que l’adreça de superposició respon, després confirmeu que existeix un oient al port configurat i anoteu la seva adreça d’enllaç. Feu una sol·licitud controlada i llegiu el registre del proxy, per saber si la fallada és a l’oient o a l’obtenció posterior. Finalment, comproveu la ruta de l’amfitrió del proxy i la política de DNS per a l’origen.

El projecte N2N documenta vores i supernodes com a components de superposició. No converteix una vora en un proxy d’aplicacions, i cap configuració d’encaminament afegeix un gestor de protocol que ningú no ha iniciat.