Melhor VPN para Raspberry Pi: quando o problema não estava no Pi

O Raspberry Pi estava a menos de dois metros de mim.

Mesmo assim, o portátil insistia que ele não existia.

Eu tinha acabado de atualizar um Raspberry Pi 5 que usava como pequeno servidor doméstico. Lá estavam uma pasta de trabalho, alguns backups e um serviço de desenvolvimento que normalmente abria pelo browser. Precisava de copiar um ficheiro do Pi, verificá-lo e enviá-lo para um cliente.

Abri o terminal.

ssh pi-servidor.local

Nada.

Tentei pelo endereço IP.

Timeout.

A primeira coisa que culpei foi a atualização do Raspberry Pi OS. Afinal, eu tinha acabado de passar para Trixie, lançado em 2025, e uma atualização recente parecia um suspeito bastante razoável. (Raspberry Pi)

Reiniciei o Pi.

Continuava inacessível.

Depois desliguei a VPN do portátil.

O terminal ligou imediatamente.

Liguei novamente a VPN.

O Pi desapareceu.

Foi aí que “melhor VPN para Raspberry Pi” passou a significar uma coisa muito diferente.

Eu não precisava necessariamente de instalar outra VPN no Raspberry Pi.

Precisava de uma VPN que não me fizesse perder o Raspberry Pi quando a ligava.

Eu tinha culpado a máquina errada

O Pi estava a fazer o trabalho dele.

SSH, partilhas de ficheiros e outros serviços locais fazem parte da utilização normal de um Raspberry Pi numa rede doméstica. (Raspberry Pi Documentation) O problema começava antes de qualquer pedido chegar ao servidor.

Quando a VPN estava desligada, eu conseguia entrar.

Quando a ligava, deixava de conseguir.

Depois de repetir a sequência duas ou três vezes, parei de reiniciar o Raspberry Pi e passei a olhar para o portátil.

A VPN estava a alterar o caminho do tráfego.

Essa conclusão trouxe uma pergunta mais útil: por que razão proteger a minha ligação à internet tinha de cortar também o acesso a um computador dentro da minha própria casa?

A VPN grande estava a proteger mais do que eu precisava

Eu usava um fornecedor conhecido.

A escolha fazia sentido. Tinha anos de historial, muitos servidores e uma documentação bastante completa.

Comecei a procurar nas definições.

Kill switch.

Protocolos.

Opções de rede.

Exceções.

A lógica era compreensível: uma VPN pode aplicar regras rígidas para evitar que tráfego saia acidentalmente fora do túnel.

Só que, no meu caso, essa rigidez tinha uma consequência muito concreta.

O Raspberry Pi local deixava de responder.

Outros utilizadores já encontraram o mesmo tipo de situação: ativam a VPN e perdem ping ou SSH para o Pi, recuperando o acesso depois de permitir explicitamente a rede local. (Raspberry Pi Forums)

Era exatamente o padrão que eu tinha à frente.

E agora que sabia onde estava o problema, podia resolvê-lo de duas maneiras.

A primeira solução era transformar-me no administrador da rota

Eu podia criar a exceção manualmente.

Descobrir a subnet local.

Adicionar a rota.

Rever a firewall.

Garantir que endereços privados continuavam pela interface normal enquanto o resto seguia pela VPN.

O NetworkManager permite construir precisamente esse tipo de configuração. (NetworkManager)

Comecei.

Adicionei uma exceção para o IP do Raspberry Pi.

Funcionou.

Depois reparei que pi-servidor.local ainda não se comportava da mesma maneira.

Mais uma alteração.

Mais um teste.

Reconectei a VPN.

Verifiquei novamente.

Ao fim de alguns minutos, tinha várias janelas abertas para chegar a um computador que conseguia ver da minha cadeira.

A configuração era possível.

Mas essa deixou de ser a pergunta.

A pergunta passou a ser: por que razão estou a escrever as exceções à mão se aquilo que quero fazer é perfeitamente normal?

Foi nesse ponto que a quantidade de opções deixou de parecer uma vantagem.

A atualização para Trixie tornou a manutenção ainda menos apelativa

Havia outra razão para eu não querer transformar aquilo numa configuração artesanal.

O Raspberry Pi OS continua a evoluir.

Trixie tornou-se a versão atual em 2025, e discussões posteriores entre utilizadores mostram que procedimentos de rede e importação de perfis nem sempre se comportam exatamente como em instalações anteriores. (Raspberry Pi)

Isso não me preocupava enquanto administrava o próprio Pi.

Fazia parte do hobby.

Mas eu não queria acrescentar à lista de manutenção uma coleção de regras na VPN do portátil apenas para conseguir abrir um servidor local.

Quanto mais mexia na configuração, mais claro ficava que estava a resolver a situação na camada errada.

Em vez de modificar o Raspberry Pi, decidi mudar a forma como a VPN do portátil tratava a rede local.

Foi aí que a opção mais simples fez mais sentido

Abri o OnlydogVPN^↗.

O que me interessava aqui não era uma lista maior de países. Era a possibilidade de usar uma configuração pensada para uma rede local confiável: manter NAS, impressoras ou um Raspberry Pi acessíveis diretamente enquanto o tráfego público continua pela VPN.

Escolhi esse cenário.

Liguei.

E, antes de verificar qualquer IP público, voltei ao terminal.

ssh pi-servidor.local

Apareceu o pedido de autenticação.

Entrei.

Saí e tentei pelo endereço IP.

Também funcionou.

Abri o pequeno serviço web alojado no Pi.

Carregou.

Depois fui à pasta partilhada.

Estava lá.

Só então verifiquei a ligação externa.

O tráfego para a internet continuava pela VPN.

Era exatamente a configuração que eu tinha começado a construir manualmente — mas sem transformar a minha tarde numa aula prática de routing.

O ficheiro finalmente saiu do Pi

Agora podia voltar àquilo que tinha tentado fazer desde o início.

Copiei o ficheiro para o portátil.

Verifiquei-o.

Abri o serviço do cliente e comecei o upload.

Durante a transferência, mantive uma sessão SSH aberta para acompanhar o Raspberry Pi.

Nada desapareceu.

Não desliguei a VPN para entrar no Pi.

Não desliguei a VPN para enviar o ficheiro.

Pela primeira vez, as duas coisas deixaram de competir.

Essa foi a diferença decisiva.

Eu tinha começado a pesquisar como melhorar a VPN para um Raspberry Pi.

Terminei sem instalar absolutamente nada novo no Raspberry Pi.

A explicação técnica acabou por ser bastante curta

O princípio é simples: tráfego destinado à rede privada não precisa de seguir o mesmo caminho que o tráfego destinado à internet.

O Linux e o NetworkManager conseguem separar essas rotas. (NetworkManager) A diferença está em quanto trabalho o utilizador precisa de fazer para chegar ao comportamento desejado.

Não consigo observar a regra interna exata do primeiro cliente VPN que estava a impedir o acesso local.

Mas o resultado no ecrã era inequívoco.

Com ele, ligar a VPN fazia o Raspberry Pi desaparecer.

Com a segunda configuração, a VPN continuava ligada e o Pi continuava ao meu lado — tanto fisicamente como na rede.

Para mim, isso resolveu a questão técnica inteira.

Foi aí que “tudo pelo túnel” deixou de parecer automaticamente melhor

Eu tinha associado uma configuração mais rígida a uma configuração mais segura.

Se todo o tráfego passasse pela VPN, parecia lógico pensar que estava mais protegido.

Só que “todo” incluía um computador dentro da minha própria rede.

O Raspberry Pi não era um site público a milhares de quilómetros.

Era um equipamento local.

Eu queria duas coisas ao mesmo tempo: proteger o tráfego que saía para a internet e continuar a comunicar normalmente com os dispositivos privados em que confiava.

Não eram objetivos incompatíveis.

A configuração certa simplesmente os tratava como coisas diferentes.

E essa distinção foi mais útil do que acrescentar outro servidor ou outro protocolo à lista.

A VPN maior continuava a oferecer mais — mas eu já não precisava de mais

O fornecedor grande continuava a ter vantagens reais.

Mais localizações.

Mais historial.

Mais documentação.

Mais formas de ajustar manualmente a ligação.

Se eu precisasse de uma cidade muito específica ou quisesse controlar cada detalhe da rede, essa profundidade continuaria a ser atraente.

Mas nenhum servidor adicional faria o meu Raspberry Pi reaparecer.

O problema acontecia dentro da rede local.

Por isso, a solução mais convincente não foi dar-me mais formas de editar rotas.

Foi evitar que eu precisasse de as editar para fazer uma tarefa normal.

“Melhor VPN para Raspberry Pi” afinal era uma pergunta sobre o portátil

Há muitos casos em que instalar uma VPN diretamente num Raspberry Pi faz sentido.

O Pi pode funcionar como gateway, servidor VPN ou até como hotspot de viagem para outros dispositivos. A própria Raspberry Pi documenta cenários desse tipo. (Raspberry Pi)

Mas não era isso que eu precisava.

O meu Raspberry Pi já estava exatamente onde devia estar: dentro da rede local, a servir ficheiros e aplicações.

O problema era a fronteira criada pela VPN no outro dispositivo.

Assim que essa fronteira passou a separar corretamente internet pública e rede privada, o Pi deixou de exigir qualquer tratamento especial.

A VPN maior dava-me mais ferramentas para corrigir a exceção.

A menor fez com que a exceção deixasse de ser um projeto.

Para aquele Raspberry Pi na minha secretária, a melhor VPN não foi a que consegui instalar nele — foi a que me deixou continuar a encontrá-lo enquanto permanecia ligada.