É possível usar dois VPNs no mesmo servidor doméstico sem conflitos de rota?

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Can You Use Two VPNs on the Same Home Server Without Route Conflicts? - Zima Store Online

Sim, dois VPNs podem partilhar um servidor doméstico quando os seus endereços, rotas, padrões, regras de firewall e caminhos de retorno estão explicitamente separados.

Os problemas começam quando ambos os túneis reclamam a mesma sub-rede privada, instalam rotas padrão concorrentes, usam identificadores duplicados de interface ou tabela, reescrevem o DNS globalmente ou enviam respostas por um túnel diferente daquele que recebeu o pedido. Um design seguro atribui primeiro a cada VPN um propósito distinto — como acesso remoto e saída comercial — e depois testa um túnel sozinho, o outro sozinho e ambos juntos, registando a rota ativa para cada carga de trabalho.

Defina a Função de Cada VPN Antes de Iniciar Ambas

Registe quais clientes, destinos, protocolos e aplicações pertencem à VPN A e à VPN B. Designs comuns incluem um servidor WireGuard de entrada para acesso remoto ao NAS e um VPN comercial de saída para contentores selecionados.

A comunidade OpenVPN afirma que múltiplos túneis podem funcionar simultaneamente, mas cada instância necessita de um adaptador virtual separado, porta e sub-rede única e não sobreposta.

Se ambos os túneis destinam-se a transportar todo o tráfego do servidor, decida qual é primário e qual é de reserva ou aninhado. Duas políticas independentes de “enviar tudo” não podem controlar os mesmos pacotes sem uma ordem explícita.

Mantenha as Sub-redes do Túnel e da LAN Remota Únicas

Compare ambos os pools de endereços dos túneis, cada LAN remota anunciada, a LAN doméstica, redes de contentores e redes comuns de clientes remotos. Nenhum destino deve referir-se a dois locais diferentes no mesmo contexto de roteamento.

O HOWTO do OpenVPN explica que redes privadas sobrepostas criam ambiguidade de roteamento porque o sistema não consegue saber qual site um endereço duplicado representa. Prefixos distintos eliminam a ambiguidade de endereços sobrepostos antes de considerar métricas de rota.

Renumerar um túnel ou LAN quando possível. Se a sobreposição for inevitável, use tradução NAT controlada, namespaces de rede separados, VRFs ou tabelas de políticas em vez de depender do túnel que iniciar por último.

Evite que Ambos os VPNs Substituam a Rota Padrão

Inspecione a tabela de rotas sem VPN, apenas VPN A, apenas VPN B e ambos ativos. Registe rotas padrão, rotas padrão divididas como 0.0.0.0/1 e 128.0.0.0/1, métricas e rotas de host para ambos os servidores VPN.

Um ticket do OpenVPN nota que redirecionar o gateway padrão através de múltiplos VPNs simultâneos não é útil a menos que o administrador decida rotas padrão concorrentes.

Desative a instalação automática da rota padrão no túnel que deve servir apenas sub-redes selecionadas. Preserve uma rota para cada ponto final do fornecedor VPN através da WAN subjacente para que ativar o segundo túnel não envie a sua ligação de controlo para o primeiro.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

Use Roteamento por Política para Tráfego Específico de Origem ou Aplicação

Crie tabelas de roteamento separadas para o tráfego que deve sair por cada VPN, depois selecione-as por sub-rede de origem, endereço do contentor, marca de firewall, utilizador ou interface. Mantenha a tabela principal para o tráfego normal do servidor doméstico.

Um exemplo Unix e Linux de múltiplas ligações VPN recomenda regras para que o tráfego de cada interface use a sua própria tabela de roteamento e regresse pelo modem ou túnel correto.

Adicione regras numa ordem documentada e teste a pesquisa de rotas para pares representativos de origem e destino. Uma tabela de políticas sem a LAN ligada e rotas de retorno pode isolar a aplicação selecionada do resto da rede doméstica.

Alinhe NAT, Firewall, DNS e Caminhos de Retorno

Para cada VPN, documente qual interface encaminha o tráfego, quais endereços de origem são mascarados, quais sub-redes de entrada são permitidas e qual resolvedor DNS os clientes recebem. Aplique NAT apenas onde o lado remoto não tem uma rota de retorno.

Um caso do Server Fault que encaminha clientes WireGuard através de uma ligação OpenVPN explica que o tráfego pode precisar de mascaramento porque o VPN remoto conhece apenas o endereço do cliente OpenVPN, não a sub-rede remota do cliente WireGuard.

Verifique se as respostas saem pelo túnel que recebeu ou originou a sessão. Respostas assimétricas podem fazer um VPN parecer ligado enquanto o tráfego TCP, DNS ou SMB falha silenciosamente.

Teste Falhas e Ordem de Reinício Antes do Uso em Produção

Inicie a VPN A, depois a B; inverta a ordem; reinicie cada serviço independentemente; e reinicie o servidor. Registe rotas, regras, DNS, estado do firewall e se o acesso remoto de gestão existente sobrevive.

O guia ZimaSpace para corrigir uma rota VPN em falta fornece a sequência de recuperação quando um túnel captura acidentalmente o tráfego do outro.

A configuração é segura apenas quando ambos os túneis se reconectam em qualquer ordem suportada, cada carga de trabalho segue o seu caminho pretendido, o DNS permanece previsível e desativar um VPN não deixa o tráfego de gestão isolado. Mantenha uma consola local ou caminho de recuperação sem VPN antes de automatizar ambos os serviços na inicialização.