È possibile utilizzare due VPN sullo stesso server domestico senza conflitti di routing?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

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

Sì, due VPN possono condividere un server domestico quando i loro indirizzi, rotte, impostazioni predefinite, regole del firewall e percorsi di ritorno sono esplicitamente separati.

I problemi iniziano quando entrambi i tunnel rivendicano la stessa subnet privata, installano rotte predefinite concorrenti, usano identificatori duplicati per interfacce o tabelle, riscrivono il DNS globalmente o inviano risposte attraverso un tunnel diverso da quello della richiesta. Un design sicuro assegna prima a ogni VPN uno scopo distinto—come accesso remoto e uscita commerciale—poi testa un tunnel da solo, l’altro da solo e entrambi insieme registrando la rotta attiva per ogni carico di lavoro.

Definire il Ruolo di Ogni VPN Prima di Avviare Entrambe

Annota quali client, destinazioni, protocolli e applicazioni appartengono a VPN A e VPN B. I design comuni includono un server WireGuard in ingresso per l’accesso remoto al NAS e una VPN commerciale in uscita per container selezionati.

La community OpenVPN afferma che più tunnel possono funzionare simultaneamente, ma ogni istanza necessita di un adattatore virtuale separato, una porta e una subnet unica e non sovrapposta.

Se entrambi i tunnel devono trasportare tutto il traffico del server, decidi quale è primario e quale è di backup o annidato. Due politiche indipendenti “invia tutto” non possono controllare gli stessi pacchetti senza un ordinamento esplicito.

Mantenere Uniche le Subnet del Tunnel e della LAN Remota

Confronta entrambi i pool di indirizzi dei tunnel, ogni LAN remota pubblicizzata, la LAN domestica, le reti dei container e le reti comuni dei client remoti. Nessuna destinazione dovrebbe riferirsi a due posti diversi nello stesso contesto di routing.

Il HOWTO di OpenVPN spiega che le reti private sovrapposte creano ambiguità di routing perché il sistema non può sapere quale sito rappresenta un indirizzo duplicato. Prefissi distinti eliminano l’ambiguità degli indirizzi sovrapposti prima che vengano considerati i metriche di rotta.

Rinumerare un tunnel o una LAN quando possibile. Se la sovrapposizione è inevitabile, usa traduzione NAT controllata, namespace di rete separati, VRF o tabelle di policy invece di affidarti a quale tunnel si avvia per ultimo.

Impedire che Entrambe le VPN Sostituiscano la Rotta Predefinita

Ispeziona la tabella di routing senza VPN, con solo VPN A, solo VPN B e con entrambe attive. Registra le rotte predefinite, le rotte predefinite divise come 0.0.0.0/1 e 128.0.0.0/1, le metriche e le rotte host verso entrambi i server VPN.

Un ticket OpenVPN nota che reindirizzare il gateway predefinito attraverso più VPN simultanee non è utile a meno che l’amministratore non decida rotte predefinite concorrenti.

Disabilita l’installazione automatica della rotta predefinita sul tunnel che deve servire solo subnet selezionate. Conserva una rotta verso ogni endpoint del provider VPN attraverso la WAN sottostante così da evitare che l’attivazione del secondo tunnel invii la sua connessione di controllo nel primo.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Usa il Routing di Policy per il Traffico Specifico di Sorgente o Applicazione

Crea tabelle di routing separate per il traffico che deve uscire attraverso ciascuna VPN, poi selezionale per subnet di origine, indirizzo container, marca del firewall, utente o interfaccia. Mantieni la tabella principale per il traffico ordinario del server domestico.

Un esempio Unix e Linux di connessioni VPN multiple raccomanda regole affinché il traffico da ogni interfaccia usi la propria tabella di routing e ritorni attraverso il modem o tunnel corretto.

Aggiungi regole in un ordine documentato e testa la ricerca della rotta per coppie rappresentative di sorgente e destinazione. Una tabella di policy senza la LAN connessa e le rotte di ritorno può isolare l’applicazione selezionata dal resto della rete domestica.

Allinea NAT, Firewall, DNS e Percorsi di Ritorno

Per ogni VPN, documenta quale interfaccia inoltra il traffico, quali indirizzi di origine sono mascherati, quali subnet in ingresso sono consentite e quale resolver DNS ricevono i client. Applica NAT solo dove il lato remoto non ha una rotta di ritorno.

Un caso Server Fault che instrada client WireGuard attraverso una connessione OpenVPN spiega che il traffico può necessitare di mascheramento perché la VPN remota conosce solo l’indirizzo client OpenVPN, non la subnet client WireGuard remota.

Verifica che le risposte escano attraverso il tunnel che ha ricevuto o originato la sessione. Risposte asimmetriche possono far sembrare una VPN connessa mentre il traffico TCP, DNS o SMB fallisce silenziosamente.

Testa il Fallimento e l’Ordine di Riavvio Prima dell’Uso in Produzione

Avvia VPN A, poi B; inverti l’ordine; riavvia ogni servizio indipendentemente; e riavvia il server. Registra rotte, regole, DNS, stato del firewall e se l’accesso remoto alla gestione esiste ancora.

La guida ZimaSpace per riparare una rotta VPN mancante fornisce la sequenza di recupero quando un tunnel cattura accidentalmente il traffico dell’altro.

La configurazione è sicura solo quando entrambi i tunnel si ricollegano in qualsiasi ordine supportato, ogni carico di lavoro segue il percorso previsto, il DNS rimane prevedibile e disabilitare una VPN non blocca il traffico di gestione. Mantieni una console locale o un percorso di recupero non VPN prima di automatizzare entrambi i servizi all’avvio.