Encaminhamento dinâmico SSH como proxy SOCKS sobre a sua VPN

Uma aplicação que só fala SOCKS não tem com quem falar numa VPN comum, porque o túnel transporta pacotes e a aplicação quer um ponto final de proxy. O OpenSSH pode fornecer esse ponto final quando o proprietário do acesso o permite, já que o encaminhamento dinâmico transforma uma sessão SSH num proxy local. Depois há dois saltos que é preciso manter separados: o túnel que chega ao servidor SSH e a ligação que esse servidor abre a seguir. Separá-los explica tanto por que razão a disposição funciona como aquilo que ela nunca fará.

No que se torna o ouvinte SSH e no que não se torna

O encaminhamento dinâmico faz o cliente SSH escutar localmente e falar SOCKS4 ou SOCKS5 com tudo o que se ligue. Cada pedido nomeia um destino e o servidor SSH abre a ligação seguinte, e é por isso que a resolução do destino pode acontecer do outro lado. Isto é encaminhamento TCP ao nível da aplicação, não uma VPN para todo o dispositivo. Não transporta qualquer associação UDP, nem ICMP, nem nada para aplicações que ignoram por completo as definições de proxy. O salto do servidor SSH até à aplicação também não está dentro do seu túnel, o que conta quando o destino só aceita tráfego de redes conhecidas.

Os pré-requisitos são reais: uma rota até ao servidor SSH, uma conta autorizada, uma chave de servidor verificada e autorização para encaminhar. Nenhum deles é criado pelo proxy, e o último é normalmente o primeiro a faltar. Confirme os quatro antes de depurar qualquer outra coisa, porque do lado do cliente a falha parece igual, falte o que faltar.

Inicie-o no loopback com uma porta explícita

Escolha uma porta local não usada e ligue-a explicitamente ao loopback em vez de deixar o endereço de fora. As três opções abaixo existem cada uma por um motivo.

ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  [email protected]

-N salta o comando remoto e -T salta o pseudo-terminal, pelo que a sessão só existe para encaminhar. ExitOnForwardFailure faz o cliente sair quando o ouvinte não pode ser criado, em vez de correr sem o encaminhamento que pediu. ControlPath=none mantém a sessão fora de uma ligação multiplexada existente que poderia acrescentar os seus próprios encaminhamentos. O loopback mantém o ouvinte fora da LAN, mas numa máquina partilhada não é uma fronteira de autorização, porque outros processos locais também lhe podem chegar. A referência do cliente OpenSSH documenta todas estas opções, e o aviso sobre o loopback decorre daquilo que é um socket à escuta.

Envie os nomes através do proxy, não à volta dele

Um cliente SOCKS5 pode resolver o destino sozinho ou pedir ao proxy que o faça, e essa escolha decide que resolvedor responde. Com socks5h, o curl envia o nome do servidor através do proxy, pelo que a consulta acontece no servidor SSH. Com socks5 simples, o portátil resolve primeiro e só a ligação viaja, o que anula em silêncio o objetivo quando o nome é interno. O pedido abaixo também esvazia a lista de sem-proxy, para que um valor NO_PROXY herdado não o possa levar à volta do proxy.

curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/health

A validação do certificado e o início de sessão próprio da aplicação continuam a aplicar-se, porque o proxy não substitui nenhum dos dois. Restam duas resoluções: o portátil tem de chegar ao servidor SSH pelo caminho de VPN e DNS permitido, e o servidor SSH tem de resolver sozinho o nome da aplicação. A segunda pode ser testada isoladamente antes de qualquer tráfego passar pelo proxy.

ssh [email protected] getent hosts app.corp.example

Prove um destino permitido e depois feche a sessão

Teste um destino que a política permite e outro que deveria recusar, porque um encaminhamento a funcionar só prova que o ouvinte funciona e nada mais. A aplicação vê o endereço de origem que o servidor SSH escolhe, e esse não é o endereço do túnel do seu portátil. Onde o extremo remoto registe ligações por origem, essa diferença é a primeira coisa a verificar quando um pedido é recusado.

Pare a sessão através do processo que a possui em vez de matar uma shell não relacionada. Depois confirme que o ouvinte desapareceu, porque uma porta que ainda responde é uma sessão que não fechou de verdade. Retire apenas a definição de proxy que este exercício introduziu, e deixe o resto da configuração da aplicação em paz. Um terminal sem supervisão que mantém uma regra de encaminhamento não é um serviço, e um proxy permanente precisa de um ciclo de vida aprovado, não de uma janela esquecida.

ss -ltn | grep 1080

Falhas que esta disposição não consegue corrigir

Alguns sintomas apontam diretamente para os limites acima, e reconhecê-los cedo poupa uma tarde de depuração do proxy. A tabela relaciona o que vê com o que isso costuma significar. Tudo na última coluna é uma questão de conceção, não um erro de configuração.

As três primeiras linhas são as que as pessoas diagnosticam mal, porque cada uma produz uma tentativa de ligação em vez de um erro sobre o próprio proxy. Um nome que se resolve no portátil não diz nada sobre o resolvedor do servidor, e a falha é lida antes como um problema de certificado ou de tempo limite. As aplicações só UDP ficam fora da conceção, não quebradas dentro dela, e nenhuma opção ssh adicional o muda. A linha do navegador é o lembrete habitual de que as definições de proxy são por aplicação. A última linha é a razão pela qual existe a verificação de fecho: uma porta que ainda escuta significa que agora é outra coisa a possuí-la.