Que tráfego de aplicações um encaminhamento SSH transporta de facto?

Uma shell, um encaminhamento local, SOCKS e o modo de dispositivo de túnel expõem interfaces diferentes. Nomeie a que a sua aplicação pode usar antes de a comparar com uma VPN encaminhada.

O terminal liga-se, a linha de comandos aparece e todos concordam que o acesso SSH funciona. Depois, um cliente de base de dados no portátil continua sem conseguir alcançar o anfitrião privado, e a culpa recai na sessão. O que foi construído foi uma shell, e é uma das quatro interfaces bastante diferentes que o SSH pode oferecer. Nomeie primeiro a interface e depois teste se a aplicação a usa realmente. A ordem importa, porque cada interface falha à sua maneira.

Nomeie a interface antes de comparar seja o que for

O manual do cliente OpenSSH distingue quatro mecanismos que é fácil confundir. Uma shell ou um comando remoto é executado no anfitrião SSH. Um encaminhamento local abre um socket à escuta no cliente e faz a ligação seguinte a partir do lado remoto. Um encaminhamento remoto faz o contrário, escutando no lado do servidor. O encaminhamento dinâmico expõe um ponto final SOCKS a programas que sabem usá-lo.

  • Shell: o programa é executado na máquina remota, nada escuta localmente.
  • Encaminhamento local: o seu portátil tem uma porta, o anfitrião remoto faz a ligação de saída.
  • Encaminhamento remoto: o lado remoto tem uma porta, o tráfego regressa até si.
  • Dinâmico: um proxy SOCKS no cliente, usado apenas por aplicações que o compreendem.

Nenhum destes instala uma rota. Um programa que ignora as definições de proxy, ou fala UDP, ou resolve nomes sozinho, não é afetado por uma sessão SSH ativa. Isso não é um defeito do SSH; é o alcance da interface que escolheu.

Os encaminhamentos local, remoto e dinâmico diferem em quem escuta

A distinção que decide a maioria dos casos é quem possui o socket à escuta. Num encaminhamento local, o cliente escuta e a extremidade remota marca o destino, e por isso o endereço de destino é resolvido do ponto de vista do servidor. Num encaminhamento remoto, o servidor escuta e a ligação é transportada de volta para o seu lado, e é assim que expõe um serviço local sem o publicar diretamente.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

O primeiro comando associa a porta 5432 no portátil e encaminha-a para a base de dados tal como é vista a partir do bastião. O segundo cria um proxy SOCKS na porta 1080. O terceiro comando confirma que processos estão realmente à escuta, e é a única prova de que o encaminhamento existe em vez de ter falhado em silêncio por um conflito de portas.

O encaminhamento dinâmico merece o seu próprio aviso: só abrange aplicações que respeitam SOCKS. Um navegador pode ser apontado para ele, a uma ferramenta de linha de comandos pode dizer-se que o use, mas um controlador de base de dados com a sua própria pilha de ligação normalmente não consegue. Assumir que todos os programas da máquina passam agora pelo túnel é o erro mais comum em toda esta área.

O modo de dispositivo de túnel é a única exceção de rede real

O OpenSSH também suporta o encaminhamento de dispositivo de túnel -w, que passa uma interface ponto a ponto em vez de um ouvinte TCP. É um túnel de rede genuíno, e é configurado deliberadamente, não é um efeito secundário de abrir uma shell.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Exige os números de interface correspondentes disponíveis nas duas extremidades, a configuração correta no servidor e privilégios suficientes no cliente para criar o dispositivo. Exige também um plano de endereçamento e encaminhamento, porque uma interface nua não transporta qualquer política sobre que destinos devem usá-la.

Mesmo assim, o túnel termina no anfitrião remoto. Qualquer proteção fornecida pelo transporte SSH acaba ali, e a ligação seguinte é um salto separado. Um gateway VPN tem a mesma forma de fronteira, e é por isso que a comparação deve ser sobre alcance e terminação e não sobre qual ferramenta é mais forte. Nomear essa fronteira em voz alta também resolve a discussão sobre se um túnel «cifra tudo», porque claramente não cifra.

Teste que a sua aplicação usa a interface que construiu

A verificação é por aplicação, não por sessão. Um encaminhamento a funcionar prova que a porta está associada e que a extremidade remota pode marcar; não prova que o programa que lhe importa se ligou através dele.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

O primeiro comando envia um pedido através do ponto final SOCKS com o nome do anfitrião resolvido remotamente, e o segundo exercita a porta de base de dados encaminhada com TLS ainda exigido. Execute os mesmos testes com o encaminhamento parado para confirmar que falham, porque um teste que passa das duas maneiras nunca usava o túnel.

Depois compare com uma VPN encaminhada apenas nas dimensões que importam: que destinos estão cobertos, que protocolos funcionam, onde acaba a proteção e quem tem de aprovar o acesso. Um encaminhamento de um só serviço pode ser a resposta mais estreita e melhor, enquanto uma VPN é a forma correta quando muitas aplicações precisam do mesmo caminho de rede. Nenhuma das duas concede tudo o que é alcançável a partir do seu extremo remoto.

Artigos relacionados