Uma sobreposição N2N não é um proxy: desenhe as duas conexões

O Firefox aponta para 127.0.0.1:8000, a borda N2N está ativa, o par responde a um ping no seu endereço de sobreposição, e o navegador ainda relata que o proxy recusou a conexão. Nada nessa cadeia é contraditório. Uma sobreposição dá a um host um endereço alcançável numa rede privada; não cria um processo que fale o protocolo do proxy. O navegador não está a pedir uma rota para um par. Está a pedir um ouvinte local.

Duas conexões estão a ser confundidas aqui, e desenhá-las separadamente esclarece a maior parte da confusão num minuto.

Duas conexões, não uma

A primeira conexão vai do navegador até ao que escuta na porta loopback. É um socket local, e se nada o possuir, a conexão é recusada antes de um único pacote chegar ao N2N. A segunda vai do processo proxy até à origem que está a obter. Esse caminho é escolhido pela tabela de roteamento do host proxy, e pode ser o uplink normal, outro túnel ou uma rota de política que nada tem a ver com a sobreposição.

Fazer ping ao par prova que a sobreposição consegue entregar pacotes entre endereços de borda. Não prova nada sobre um ouvinte na porta 8000, nem sobre se esse host consegue alcançar a origem. Falhas separadas, correções separadas.

Onde o ouvinte tem de viver

Um proxy ligado a 127.0.0.1 é deliberadamente local: só aceita conexões da máquina onde corre. É o padrão certo para um proxy pessoal e a forma errada de o partilhar por uma sobreposição. Servir pares da sobreposição exige ou um endereço de bind na interface de sobreposição ou um componente de encaminhamento que termine a conexão loopback e a reencaminhe. De qualquer forma, uma política explícita deve decidir que fontes de sobreposição podem usar o serviço, porque um proxy aberto numa rede partilhada é um convite.

Verifique o bind real com uma listagem de sockets em vez do ficheiro de configuração. Um daemon iniciado antes de a sobreposição subir pode continuar ligado a um endereço que já não existe.

localhost não é o par

No campo de proxy do navegador, localhost aponta para a máquina do próprio navegador. Não é a borda, nem o supernodo, nem o host no extremo distante do túnel. Se o proxy corre noutro par, coloque no campo o endereço de sobreposição alcançável e a porta desse par, e depois confirme que o ouvinte aceita conexões do endereço da sua borda.

Os supernodos ajudam as bordas a encontrar-se; não são um serviço de proxy. Tratar um endereço de supernodo como ponto final de proxy produz a mesma recusa com um salto extra de confusão.

Uma rota não pode realizar um handshake

Mesmo com o endereço certo, o roteamento não é proxying. Uma conexão de proxy HTTP começa com um pedido CONNECT ou uma linha de pedido em forma absoluta, e um proxy SOCKS começa com uma negociação de versão e método. Um router ou uma sobreposição encaminha bytes; não analisa essas mensagens nem abre a conexão seguinte por si. É por isso que uma rota que funciona para ping e SSH ainda pode falhar para um proxy do navegador: o navegador precisa de um processo cooperativo, não apenas de alcançabilidade.

Se o objetivo é apenas alcançar um serviço no par, remova a definição de proxy e use o endereço de sobreposição do serviço diretamente.

Teste as fronteiras por ordem

Confirme que o endereço de sobreposição responde, depois confirme que existe um ouvinte na porta configurada e anote o seu endereço de bind. Faça um pedido controlado e leia o registo do proxy, para saber se a falha está no ouvinte ou na obtenção seguinte. Por fim, verifique a rota do host proxy e a política de DNS para a origem.

O projeto N2N documenta bordas e supernodos como componentes de sobreposição. Não transforma uma borda num proxy de aplicações, e nenhuma configuração de roteamento acrescenta um manipulador de protocolo que ninguém iniciou.