Mantenha o SSH local quando o host usa uma VPN de saída

Um pequeno servidor Linux usa uma VPN de saída para a aplicação que hospeda, e o administrador ainda quer alcançá-lo por SSH a partir da mesa ao lado. É um requisito razoável, e normalmente não exige nem redirecionamento de portas, nem endereço do provedor, nem um buraco no túnel. O que ele exige é um caminho de administração projetado de propósito em vez de herdado do que o cliente VPN fez com a tabela de rotas.

Os passos abaixo assumem que o administrador está na mesma LAN.A administração remota é outro problema com outra resposta.

Vincule o SSH ao endereço que os administradores usam

Comece pelo listener.ss -ltnp | grep :22 mostra a que o sshd está vinculado, e um listener em 0.0.0.0 aceita conexões de todas as interfaces, incluindo o túnel. Vincular ao endereço da LAN é mais estreito e torna a intenção visível:ListenAddress 192.168.10.20 em sshd_config, seguido de um teste de configuração e uma recarga. Um erro de digitação nesse endereço é mais visível que um curinga, porque o sshd se recusa a iniciar quando o endereço não existe.

Mantenha a verificação de chave de host e a autenticação por usuário exatamente como estão. «É só a rede local» não é um método de autenticação, e um canal de administração que pula a verificação de chave porque a rota é curta é um canal de administração à espera de abuso. Uma reserva DHCP ou um endereço estático torna o alvo previsível sem transformá-lo na identidade pública do servidor.

Mantenha a rota da LAN fora do túnel

Um host com um endereço em 192.168.10.0/24 tem uma rota conectada para esse prefixo, e uma rota mais específica vence a padrão da VPN dentro da mesma tabela. Por isso o SSH local muitas vezes continua funcionando sozinho quando o túnel sobe. Verifique em vez de presumir:ip route get 192.168.10.50 nomeia a interface e o endereço de origem que o kernel usaria, e a resposta deveria ser o dispositivo da LAN, não o túnel. Repita a verificação também a partir da máquina do administrador, porque é a tabela dela que decide se os pacotes chegam. Dois hosts no mesmo cabo podem discordar sobre qual direção é alcançável.

A premissa quebra em dois lugares. Uma regra de roteamento por política pode enviar tráfego para uma tabela cuja rota padrão aponta para o túnel antes de a tabela principal ser consultada. Um cliente VPN com função de bloqueio ou kill-switch também pode bloquear tráfego que não entra no túnel, independentemente do que diga a tabela de rotas.

As VLAN de gestão roteadas são o outro caso. Se o administrador está em 192.168.50.0/24 atrás do roteador local, o servidor precisa de uma rota explícita para esse prefixo através de 192.168.10.1, e essa rota tem de sobreviver a uma reconexão. Mantenha a exceção específica para o prefixo de gestão; uma exceção ampla para faixas privadas anula o propósito do túnel.

Faça a exceção do firewall tão estreita quanto a regra

Se o host executa um firewall, permita SSH apenas a partir da origem de gestão e apenas na interface da LAN. Uma regra que permite a porta 22 de qualquer lugar é mais ampla que o requisito e mais difícil de justificar numa revisão. Numa máquina nftables a regra fica na cadeia de entrada com a interface e a origem correspondidas; numa máquina iptables o equivalente é um par de correspondências em -i e -s. Comente a regra com o grupo de administradores a que serve, para que a próxima auditoria não tenha de adivinhar porque a porta 22 está aberta.

Verifique também o filtro do próprio cliente VPN. Alguns clientes instalam regras que descartam tráfego local por desenho, e uma regra de firewall correta por cima de um descarte ao nível do cliente não muda nada. Leia a configuração do cliente antes de editar o firewall do host, porque dois filtros em série produzem uma falha que não se parece com nenhum dos dois.

Teste os dois estados

Execute o teste duas vezes: uma com o túnel conectado e outra com o túnel desligado. Em cada estado, confirme o listener, a rota e um login SSH real a partir da máquina do administrador. Um caminho que só funciona enquanto o túnel está de pé não é um caminho de gestão local; é uma coincidência.

Depois reinicie o túnel com uma sessão SSH aberta. Uma sessão que sobrevive prova que o roteamento é estável; uma sessão que cai diz-lhe que o cliente reescreve rotas ou filtros na reconexão, o que vale a pena saber antes de um incidente e não durante.

Anote o endereço de origem a partir do qual testou, porque uma regra escrita para 192.168.10.50 falha em silêncio quando o portátil do administrador passa para outra sub-rede.

Escreva o caminho de recuperação no runbook

Decida agora o que acontece se a VPN de saída quebrar o caminho local. O acesso por consola, um segundo endereço de gestão ou um procedimento documentado para parar o cliente são todas respostas legítimas, e qualquer uma delas é melhor do que descobrir o problema no momento em que precisa de iniciar sessão. Se o servidor for remoto, o caminho local não existe, e o desenho correto é uma rota de acesso remoto aprovada e separada ou um bastião em vez de uma porta pública exposta.

Mantenha as duas funções separadas na documentação: o SSH local para o administrador que está perto, e o túnel de saída para o tráfego da aplicação. Quando essas funções estão escritas, uma alteração futura a qualquer uma delas tem um lugar óbvio onde ser verificada, e a pessoa seguinte não tem de redescobrir porque um servidor com uma VPN ainda responde no seu endereço de LAN.