Toda VPS recém-criada tem, por padrão, três coisas escutando em portas públicas: SSH, geralmente o painel do provedor, e qualquer banco de dados que você tenha instalado sem pensar duas vezes sobre a porta. Cada uma dessas portas é testada por scanners automatizados minutos depois de a VPS entrar no ar — não é uma questão de "se", é uma questão de "quando" alguém vai tentar.

A resposta mais comum é reforçar a senha, trocar a porta padrão ou adicionar um segundo fator. Isso ajuda, mas mantém o problema central: o serviço continua respondendo publicamente, para qualquer IP do planeta.

O modelo: recolher, não reforçar

Em vez de fortalecer um serviço exposto, uma VPN self-hosted — rodando na sua própria infraestrutura, sem depender de um provedor terceiro de VPN comercial — cria uma rede privada entre quem precisa operar a VPS e os serviços críticos dela. SSH, banco de dados e painel de administração passam a escutar apenas dentro dessa rede privada. Do lado de fora, essas portas simplesmente não existem.

  • SSH: acessível apenas por quem está conectado à VPN, com chave própria e log de conexão.
  • Banco de dados: a porta de conexão não escuta em nenhuma interface pública — só na rede interna e na VPN.
  • Painel de administração: mesma lógica — some da internet aberta, continua acessível para quem tem motivo de estar lá.

Por que self-hosted, e não um serviço de VPN comercial

Um provedor de VPN comercial ainda coloca um terceiro no meio do seu acesso mais sensível — se o provedor tiver um incidente, seus acessos críticos são afetados junto. Uma VPN self-hosted roda na sua própria VPS (ou numa instância dedicada só para isso), sob seu controle direto, sem esse ponto adicional de confiança.

Não é sobre confiança em pessoas

Recolher esses acessos para uma rede privada não é sobre desconfiar do time. É sobre reduzir a superfície que precisa ser defendida — de "qualquer IP na internet pode tentar" para "só quem está na rede privada consegue nem tentar".

O que muda no dia a dia de quem opera

A objeção mais comum antes de implantar é: "isso não vai atrapalhar quando eu precisar entrar rápido?". Na prática, o fluxo muda pouco — cada pessoa se conecta à VPN com seu próprio perfil (geralmente automático, junto do cliente que já usa no laptop) e, a partir daí, acessa SSH e painel normalmente, como se estivesse na mesma rede.

  1. Conectar à VPN com o perfil individual.
  2. Acessar SSH, banco ou painel normalmente — a única diferença é que agora esses serviços não respondem para fora da rede privada.
  3. Desconectar ao final; a sessão fica registrada com identidade, não apenas IP.

O que entra no runbook de implantação

Além de configurar a VPN em si, a implantação cobre três pontos que costumam ser esquecidos:

  • Fechar as portas públicas dos serviços recolhidos no firewall da VPS, não só confiar que "ninguém vai achar".
  • Definir um procedimento de acesso de emergência, para o caso raro de a VPN ficar indisponível.
  • Documentar como adicionar e remover perfis de acesso conforme o time muda.

Esse é, normalmente, o segundo passo de uma implantação — depois do WAF no perímetro público, antes de configurar as chaves físicas FIDO2 como reforço final dos acessos mais críticos.