O proxy continua no endereço antigo do túnel depois de reconectar a VPN?

Reiniciar o cliente VPN prova apenas que o túnel voltou. Não diz nada sobre o proxy que recebeu ordem para sair através dele. O Squid, o tinyproxy e a maioria dos outros encaminhadores mantêm o endereço de origem local que resolveram no arranque até algo os obrigar a recarregar. Quando uma reconexão entrega um novo endereço de túnel, o encaminhador ou falha em todas as ligações de saída, ou começa a sair pela sua rota normal.

Essa segunda falha é a perigosa: o túnel está ativo, as páginas carregam e apenas o endereço de saída está errado.

Comece pelo listener, não pelo túnel

Há três endereços em jogo, e uma reconexão só move alguns deles. O listener é onde o seu navegador aponta, normalmente 127.0.0.1 ou um endereço de LAN, e não se importa que o túnel tenha mudado. A origem local de saída é o que o encaminhador pede ao kernel para usar ao marcar o salto seguinte, e está ligada ao dispositivo do túnel. A saída pública é o que um servidor web registra, e pode ser um endereço traduzido a vários saltos de distância.

Uma pesquisa de IP público responde apenas à última pergunta. Não pode dizer-lhe a que endereço local um encaminhador se deve ligar, porque uma única saída pública pode esconder várias fontes internas. Leia o endereço de quem possui a ligação: a saída de estado do cliente, a própria interface ou o espaço de nomes onde vive o túnel. Apanhar a primeira interface cujo nome pareça um túnel dá a resposta errada assim que exista um segundo perfil.

As disposições de contentores e de espaços de nomes quebram essa suposição em silêncio. Um encaminhador num espaço de nomes de rede não pode ligar-se a um túnel que existe noutro, e nenhuma quantidade de edição de configuração resolve isso.

Quatro verificações antes de editar qualquer coisa

Percorra-as por ordem. A primeira verificação que falha é onde para, porque as seguintes assumem que as anteriores se mantêm.

1. Confirme que o túnel em uso é o perfil em torno do qual o proxy foi construído, e não um segundo perfil que se ligou sozinho.
2. Imprima o endereço que está atualmente nesse dispositivo e compare-o com o endereço na configuração em execução.
3. Pergunte ao encaminhador que origem resolveu, em vez do que o ficheiro no disco afirma.
4. Confirme que o tráfego do encaminhador está realmente sujeito à política de encaminhamento e de firewall que espera.

O endereço do dispositivo é fácil: ip -4 addr show dev tun0 imprime o atual, e ip -4 route get 1.1.1.1 mostra que interface o kernel escolheria para esse destino. Um encaminhador que liga um endereço exato falha ruidosamente quando o endereço desaparece. Um encaminhador que liga um dispositivo, ou recorre à origem predefinida, continua a funcionar e a vazar, e esse é o resultado silencioso.

Faça corresponder a documentação à versão que executa, não ao primeiro resultado de pesquisa. A diretiva de endereço de saída do Squid está documentada para v7 e anteriores, e a documentação da v8 diz claramente que a diretiva não está disponível ali, pelo que um script construído em torno dela não sobrevive a essa fronteira (ver a referência Squid tcp_outgoing_address). Valide com o analisador do próprio produto antes de recarregar seja o que for: squid -k parse relata erros e sai sem tocar no processo em execução.

Numere cada túnel e descarte trocas obsoletas

Uma reconexão é uma passagem, e as passagens precisam de uma ordem. Marque cada ligação observada com um contador ou marca temporal que aumenta em cada estabelecimento bem-sucedido, e depois leve essa marca para dentro da configuração candidata. Quando a marca de um candidato é mais antiga do que a atual, descarte o candidato em vez de o aplicar, porque uma atualização lenta escrita para o túnel anterior iria, de outro modo, sobrepor-se às definições do atual. Junte as rajadas de eventos para que uma ligação oscilante produza uma transição em vez de quinze.

Ordene o trabalho em quatro movimentos: invalide o estado de saída antigo, espere que o dono da ligação comunique a conclusão, construa apenas o fragmento gerido e, depois, valide e ative através do gestor de serviços. Regenerar todo o ficheiro a partir de dois valores de endereço é como as restrições do listener, a autenticação e a política de destino desaparecem em silêncio. Respeite também uma paragem deliberada. Um auxiliar que continua a marcar um túnel que o utilizador desligou é um erro, não uma resiliência.

Os sockets abertos não seguirão o novo endereço

Reconfigurar o encaminhador não diz nada sobre ligações já estabelecidas. Se se esvaziam ou morrem depende do produto, por isso observe o comportamento em vez de o assumir.

Um pedido servido por um socket aberto antes da troca continua a sair pelo caminho antigo, mesmo quando a nova configuração está correta. Se isso importa, decida explicitamente: permita uma janela curta de esvaziamento e pare de aceitar trabalho novo, ou termine os sockets antigos e aceite os erros. Depois teste com uma ligação nova e mantenha esse resultado separado da verificação de esvaziamento. Ligar a origem também não é uma fronteira de segurança. Quando o tráfego nunca deve tocar na rota normal, imponha-o com marcas e regras de firewall, DNS e IPv6 incluídos, para que uma recarga falhada deixe o proxy explicitamente em baixo em vez de aberto.

Prove a nova saída com um pedido novo

O que importa é um pedido aberto depois da ativação, não um ping e não uma página que já estava em cache. Peça ao proxy um URL real e leia o endereço de saída que o extremo remoto comunica, e depois compare-o com a visão que o cliente tem do túnel quando o fornecedor expõe uma.

Mantenha a análise, a recarga e o pedido como comandos separados para que uma falha aponte para um único passo. Os dois primeiros não mudam nada quando falham, e é exatamente por isso que correm antes do reinício.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Se a recarga falhar, pare o serviço e repare o fragmento; um proxy a servir com uma saída obsoleta é pior do que uma interrupção curta. Se a recarga tiver êxito mas o pedido novo continuar a sair num lugar inesperado, volte à verificação de encaminhamento em vez de editar endereços outra vez. Anote a geração do túnel contra a qual validou, para que a próxima reconexão tenha algo concreto para comparar.