Listen, Bind e BindSame no Tinyproxy: que endereço ganha

O proxy responde, o pedido é concluído e, mesmo assim, o destino continua registrando o endereço da LAN. Nada no log do proxy parece errado, e a linha que você alterou é justamente a que a documentação mandou alterar. Em um host com endereço de LAN e endereço de túnel, três diretivas decidem qual endereço aparece onde, e só uma delas trata do lado de saída. Lê-las na ordem errada leva você à tabela de rotas sem motivo.

O sintoma: o destino vê o endereço da LAN

Um cliente se conecta ao proxy no endereço da LAN, e o proxy abre a própria conexão até o destino. Essa segunda conexão escolhe um endereço de origem pelas regras do kernel e, por padrão, é o que a consulta de rota seleciona. Por isso o destino registra o endereço primário do host mesmo que cada byte tenha passado pelo proxy. Em termos de encaminhamento não há nada quebrado, e é por isso que o log do proxy não tem nada a dizer.

A imagem espelhada dessa falha é mais fácil de ver: fixe a origem de saída no endereço do túnel e os clientes da LAN deixam de alcançar o ouvinte por completo. Essa versão se anuncia sozinha, enquanto a primeira se esconde atrás de um pedido que funciona. Ambas vêm de tratar uma diretiva como se ela respondesse às duas perguntas.

Três diretivas, três endereços diferentes

Listen nomeia o endereço local que aceita clientes do proxy. Bind fornece um endereço de origem para as conexões que o proxy faz para fora, e BindSame manda reutilizar o endereço local da conexão que acabou de ser aceita. São três perguntas separadas, e uma única linha responde apenas a uma. Confundi-las é o motivo habitual de uma alteração parecer não fazer nada.

Leia a configuração comentada que acompanha a versão instalada, porque os padrões e a sintaxe aceita mudam entre versões. A configuração de exemplo do projeto documenta cada diretiva ao lado das outras. Compare esse arquivo com o do disco, não com um guia escrito para outra distribuição.

Defina o ouvinte e a origem de saída de forma independente

Pegue um host cujo endereço de LAN seja 192.168.50.10 e cujo endereço de túnel seja 10.90.0.3. Se os clientes da LAN precisam alcançar o proxy enquanto seus pedidos saem pelo túnel, são duas decisões independentes e ambas precisam ser escritas. O trecho abaixo expressa exatamente isso e nada mais.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Isto não é uma configuração completa, então mantenha a porta aprovada, a autenticação, os controles de acesso de clientes e as restrições de destino. Os dois endereços precisam pertencer a este host dentro do espaço de nomes de rede do Tinyproxy, porque um valor de Bind que o processo não pode possuir falha ao conectar, não ao iniciar. BindSame yes descreve outra política, em que o endereço local da conexão aceita se torna a origem de saída. Nas versões atuais esse ramo tem precedência sobre a lista Bind, e é assim que uma origem configurada desaparece sem erro.

Verifique a rota que a origem implica

Escolher um endereço de origem não cria um caminho, então pergunte ao kernel o que ele faria com essa origem e esse destino. Uma consulta que nomeia a interface do túnel é a evidência mínima, e uma que nomeia a interface da LAN significa que a origem não pode funcionar como está escrita. A consulta é contextual: avalia as regras de política e a tabela em vigor para esse espaço de nomes. Não é uma conexão e não diz nada sobre o que um NAT adiante apresentará ao serviço.

ip -4 route get 203.0.113.25 from 10.90.0.3

Use um endereço de documentação no exemplo e substitua pelo serviço que você tem autorização para testar. Execute a consulta dentro do espaço de nomes do proxy quando o proxy roda em contêiner, porque as regras do host não são as regras que o processo vê. Quando faltar a rota de túnel pretendida, faça o dono da rede corrigi-la em vez de acrescentar regras específicas de destino no host do proxy. Não limpe rotas do host nem desative as rotas empurradas pelo servidor para fazer uma consulta funcionar, mesmo que um guia antigo fizesse isso, porque essas mudanças deslocam todo o comportamento de VPN aprovado do host para consertar um único caminho do proxy.

Confirme a origem no destino

Leia a origem onde o pedido chega, não onde ele sai. O log da aplicação no destino, ou o equipamento de borda à frente dele, registra o endereço que realmente viu, enquanto o proxy só pode dizer o que pretendia. Faça um novo pedido pelo ouvinte pretendido após a alteração, porque uma conexão em cache não prova nada sobre a nova vinculação. Depois compare o endereço registrado com o que você configurou.

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

O curl é apenas o gerador de tráfego; o endereço que merece verificação é o que o lado remoto registrou, não o par ao qual o curl se conectou por acaso. Se os dois não coincidirem, determine se a diferença vem da escolha de origem ou de uma tradução mais adiante, porque isso se corrige em lugares diferentes. Planeje as mudanças de endereço e as reinicializações do proxy juntas, porque vincular um endereço que o túnel não tem mais falha em silêncio após uma reconexão. Defina também o comportamento de DNS e IPv6 separadamente, porque o trecho IPv4 acima não prova nada sobre nenhum dos dois.