Bastion SSH ou acesso VPN direto: qual política se aplica?

Se os usuários de VPN podem chegar aos servidores sem cruzar um host de salto é uma questão de política vestida de rede. Se o bastion executa um controle obrigatório, entrar na VPN deve levar até ele e não contorná-lo. Se o host de salto apenas ligava um segmento antes inalcançável, um caminho direto estreito pode ser a substituição honesta. Faça as verificações abaixo em ordem e pare na primeira que falhar, porque essa resposta decide o resto.

Verifique o que o bastion realmente controla

Comece por evidências sobre o presente, não por um diagrama do documento de projeto. Olhe a configuração SSH e o filtro de pacotes do destino: se a porta 22 de entrada só é aceita a partir do endereço do bastion, o host de salto é um controle imposto. Se a mesma porta aceita conexões de todo o pool de VPN, o bastion era uma comodidade e a aplicação vive num lugar completamente outro. O histórico de chamados costuma confirmar qual dos dois existiu primeiro.

Enuncie o achado numa frase que nomeie o controle que o bastion fornece: restrição de destino, uma segunda etapa de autenticação, gravação de sessão ou visibilidade operacional durante um incidente. É essa frase que a política substituta tem de preservar.

Verifique se o destino distingue os caminhos

As regras de endereço de origem só funcionam enquanto os dois caminhos chegam com endereços de origem diferentes. Um gateway VPN que mascara o tráfego para a sub-rede dos servidores apaga essa diferença, e então toda conexão à porta 22 parece vir do gateway. A verificação é local no destino e leva um instante: liste as sessões SSH estabelecidas e leia o endereço do par de cada uma.

Quando os dois caminhos colapsam num só endereço, a distinção tem de ser feita antes, pelos destinos que a VPN pode empurrar e pelos filtros do próprio gateway. Acrescentar uma regra no destino nessa situação cria a ilusão de uma fronteira sem mudar o que chega.

Verifique o que cada registro guarda de fato

Três registros diferentes descrevem três eventos diferentes, e nenhum substitui o outro. O registro de conexão da VPN mostra que uma identidade entrou no âmbito da rede. O registro de encaminhamento do bastion mostra um canal TCP que o deixa em direção a um destino e uma porta. O log de autenticação do destino mostra que uma conta entrou por SSH. É lê-los juntos que produz uma linha do tempo; ler um só produz uma conjectura.

Nenhum desses registros contém o que aconteceu dentro da sessão cifrada entre cliente e destino. Se a revisão ao nível do comando é um requisito, ela precisa de um mecanismo de gravação implantado de propósito, com regras próprias de tratamento de dados. Esperar isso dos registros do host de salto é como uma lacuna de auditoria fica escondida até importar.

Verifique onde a política é realmente aplicada

Um ajuste de cliente como ProxyJump é um pedido, não uma restrição. O OpenSSH abrirá de bom grado uma conexão direta quando o destino for alcançável, portanto os arquivos de configuração nos portáteis descrevem a intenção enquanto os firewalls decidem o resultado. A aplicação pertence aos destinos permitidos do gateway VPN e às regras de acesso do próprio destino, e o usuário não pode editar nenhum dos dois. Audite ao mesmo tempo os caminhos alternativos: uma segunda interface, um ouvinte público, uma camada mesh ou um túnel antigo entre sites podem cada um restaurar o atalho que você acabou de fechar.

Configure ProxyJump assim mesmo, porque torna a rota aprovada a mais fácil e impede que o trabalho rotineiro gere exceções. Confirme o que o cliente realmente resolve antes de confiar nele.

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

Verifique com uma tentativa direta deliberada

Uma política nunca testada é uma esperança. De um cliente ligado à VPN, tente o caminho que agora deveria ser recusado, depois tente o aprovado, e guarde os dois resultados. A tentativa recusada é a prova de que a mudança entrou em vigor.

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

Um resultado limpo parece uma conexão direta recusada ou esgotada por tempo para o endereço do destino, seguida de um login bem-sucedido no host de salto e de um registro de autenticação do lado do destino nomeando a origem suportada. Qualquer outra coisa significa que a fronteira continua porosa, diga o que disser a documentação. Anote a data, a regra alterada e os dois resultados, e depois dê ao caminho de recuperação um responsável e uma data de expiração para que o acesso de emergência não se torne silenciosamente a rota cotidiana.