Dê a um Pi remoto um proxy SOCKS através do seu cliente SSH

Um encaminhamento dinâmico remoto coloca o ouvinte SOCKS no Pi e faz a ligação seguinte a partir do caminho VPN aprovado do seu portátil. Sem segundo servidor SSH.

Assume que um proxy SOCKS tem de correr onde o acesso à rede já existe. O OpenSSH pode colocar o ouvinte num local completamente diferente. Um encaminhamento dinâmico remoto abre a porta SOCKS num anfitrião remoto e origina cada ligação a partir do seu cliente SSH local, que transporta o caminho VPN aprovado do seu portátil. O Pi fica com um proxy limitado; não herda o seu túnel nem os seus privilégios.

O ouvinte e o lado de onde nasce a ligação podem ser diferentes

Um ssh -D 1080 normal executa o ouvinte na sua própria máquina e envia as ligações a partir daí. Um encaminhamento dinâmico remoto inverte isso: o ouvinte aparece no anfitrião remoto e cada ligação que aceita é aberta do lado local. O manual do cliente OpenSSH documenta -R sem destino fixo exatamente como esta disposição SOCKS4/5.

Um comando suportado a partir do portátil tem este aspeto, com a conta, os anfitriões e a porta tratados como marcadores:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

Três detalhes fazem ali trabalho útil. -S none mantém a sessão longe de um master de controlo partilhado, ExitOnForwardFailure falha depressa em vez de o deixar com uma sessão meio aberta, e PermitRemoteOpen limita até onde pode chegar o ouvinte remoto. Use uma conta Pi autorizada e verifique a chave do anfitrião antes de acrescentar qualquer parte disto.

O que o ouvinte remoto expõe realmente

Verifique a política de encaminhamento do servidor antes de confiar no ouvinte. Com GatewayPorts no o encaminhamento remoto fica ligado ao loopback, e é essa a exposição que pretende. Um servidor configurado para forçar encaminhamento universal publica a mesma porta em todas as interfaces, o que transforma um proxy pessoal em algo que a rede local consegue alcançar.

O loopback também não é uma fronteira por utilizador. Outro processo no Pi pode ligar-se a 127.0.0.1:1080 se souber a porta, pelo que as contas locais do Pi e tudo o que nele corre fazem parte do seu desenho de acesso. É uma razão para manter a lista de destinos estreita, não uma razão para saltar a verificação da política.

Mantenha o destino permitido específico para a aplicação que está a tentar alcançar. Substituí-lo por encaminhamento sem restrições para que um programa alheio funcione alarga o caminho muito para além do problema com que começou. A lista de destinos também regista para que servia a sessão, o que ajuda quem a auditar mais tarde. Anote-a ao lado da conta que utilizou.

Envie uma aplicação através do proxy

Um cliente no Pi que entende de proxy pode então fazer o pedido. O prefixo socks5h entrega o nome do destino ao proxy, pelo que a consulta e a ligação acontecem ambas do lado do portátil, e coincide com o destino nomeado em PermitRemoteOpen:

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

Mantenha a validação normal de certificados e a autenticação própria da aplicação. O proxy muda onde a ligação TCP é estabelecida; não torna segura um serviço não autenticado nem transforma um ponto final autoassinado num de confiança.

O portátil continua a precisar da sua própria rota e de acesso ao resolvedor tanto ao servidor SSH como à aplicação. O tráfego do seu cliente SSH tem de ser selecionado pela política VPN aprovada, e uma exclusão de túnel dividido pode enviar esse tráfego por um caminho diferente do que testou.

Prove o caminho e feche-o

Confirme que o ouvinte existe onde o espera e que só o destino previsto responde:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure pode provar que o encaminhamento foi estabelecido, e continua a não poder certificar que o início de sessão na aplicação tem sucesso a jusante. Teste a aplicação, não apenas a porta. Um ouvinte que aceita e depois falha todos os pedidos significa normalmente que o nome do destino ou a rota do portátil estão errados, não que o túnel falhou.

Esta disposição transporta apenas TCP. UDP, ICMP e programas que ignoram as definições de proxy ficam de fora, e o encaminhamento termina no momento em que a sessão SSH termina. Pare essa sessão quando terminar e remova a definição de proxy que acrescentou à aplicação.

Para acesso permanente, use em vez disso a inscrição suportada pelo proprietário da rede ou um gateway gerido. Um proxy inverso é a ferramenta errada para contornar as restrições de dispositivo ou de recursos de uma VPN; usado dentro delas, é simplesmente um caminho de aplicação autorizado com limites explícitos.

Artigos relacionados