Kun je twee VPN's op dezelfde thuisserver gebruiken zonder routeringsconflicten?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

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

Ja, twee VPN's kunnen één thuisserver delen wanneer hun adressen, routes, standaarden, firewallregels en retourpaden expliciet gescheiden zijn.

Problemen ontstaan wanneer beide tunnels hetzelfde privé-subnet claimen, concurrerende standaardroutes installeren, dubbele interface- of tabelidentificaties gebruiken, DNS globaal herschrijven of antwoorden via een andere tunnel sturen dan het verzoek. Een veilige opzet wijst eerst elke VPN een duidelijk doel toe—zoals externe toegang en commerciële uitgaande verbinding—en test vervolgens eerst één tunnel alleen, daarna de andere alleen, en daarna beide samen terwijl de actieve route voor elke taak wordt vastgelegd.

Definieer de Taak van Elke VPN Voordat je Beide Start

Schrijf op welke clients, bestemmingen, protocollen en applicaties bij VPN A en VPN B horen. Veelvoorkomende ontwerpen omvatten één inkomende WireGuard-server voor externe NAS-toegang en één uitgaande commerciële VPN voor geselecteerde containers.

De OpenVPN-community stelt dat meerdere tunnels gelijktijdig kunnen draaien, maar elke instantie heeft een aparte virtuele adapter, poort en uniek niet-overlappend subnet nodig.

Als beide tunnels al het serververkeer moeten dragen, bepaal dan welke primair is en welke als backup of genest fungeert. Twee onafhankelijke “alles verzenden”-beleid kunnen niet beide dezelfde pakketten controleren zonder expliciete volgorde.

Houd Tunnel- en Externe LAN-Subnets Uniek

Vergelijk beide tunneladrespools, elk geadverteerd extern LAN, het thuis-LAN, containernetwerken en veelvoorkomende externe clientnetwerken. Geen enkele bestemming mag in dezelfde routeringscontext naar twee verschillende plaatsen verwijzen.

De OpenVPN HOWTO legt uit dat overlappende privé-netwerken routeringsambiguïteit veroorzaken omdat het systeem niet kan weten welke site een gedupliceerd adres vertegenwoordigt. Onderscheidende prefixen verwijderen de ambiguïteit van overlappende adressen voordat route-metrics worden overwogen.

Hernummer één tunnel of LAN indien mogelijk. Als overlap onvermijdelijk is, gebruik dan gecontroleerde NAT-vertaling, aparte netwerk-namespaces, VRF's of beleids-tabellen in plaats van te vertrouwen op welke tunnel als laatste start.

Voorkom dat Beide VPN's de Standaardroute Vervangen

Inspecteer de routetabel zonder VPN, met alleen VPN A, alleen VPN B en met beide actief. Noteer standaardroutes, gesplitste standaardroutes zoals 0.0.0.0/1 en 128.0.0.0/1, metrics en hostroutes naar beide VPN-servers.

Een OpenVPN-ticket merkt op dat het omleiden van de standaardgateway via meerdere gelijktijdige VPN's niet nuttig is tenzij de beheerder concurrerende standaardroutes instelt.

Schakel automatische installatie van de standaardroute uit op de tunnel die alleen geselecteerde subnets moet bedienen. Behoud een route naar elk VPN-provider-eindpunt via de onderliggende WAN zodat het opzetten van de tweede tunnel de controleverbinding niet via de eerste stuurt.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Gebruik Beleidsroutering voor Bron- of Applicatiespecifiek Verkeer

Maak aparte routeringstabellen voor verkeer dat via elke VPN moet vertrekken en selecteer deze op bron-subnet, containeradres, firewallmarkering, gebruiker of interface. Houd de hoofdtabel voor gewoon thuisserververkeer.

Een Unix- en Linux-voorbeeld van meerdere VPN-verbindingen raadt regels aan zodat verkeer van elke interface zijn eigen routeringstabel gebruikt en terugkeert via het juiste modem of tunnel.

Voeg regels toe in een gedocumenteerde volgorde en test de route-opzoeking voor representatieve bron- en bestemmingsparen. Een beleidstabel zonder het verbonden LAN en retourroutes kan de geselecteerde applicatie isoleren van de rest van het thuisnetwerk.

Stem NAT, Firewall, DNS en Retourpaden op Elkaar af

Documenteer voor elke VPN welke interface verkeer doorstuurt, welke bronadressen gemaskeerd worden, welke inkomende subnets zijn toegestaan en welke DNS-resolver clients ontvangen. Pas NAT alleen toe waar de externe zijde geen route terug heeft.

Een Server Fault-geval waarbij WireGuard-clients via een OpenVPN-verbinding worden gerouteerd legt uit dat verkeer mogelijk gemaskeerd moet worden omdat de externe VPN alleen het OpenVPN-clientadres kent, niet het externe WireGuard-clientsubnet.

Controleer dat antwoorden via de tunnel vertrekken die de sessie ontving of initieerde. Asymmetrische antwoorden kunnen een VPN verbonden laten lijken terwijl TCP-, DNS- of SMB-verkeer stilletjes faalt.

Test Fouten en Herstartvolgorde Voor Gebruik in Productie

Start VPN A, daarna B; draai de volgorde om; herstart elke dienst onafhankelijk; en herstart de server. Noteer routes, regels, DNS, firewallstatus en of bestaande externe beheer-toegang blijft werken.

De ZimaSpace-gids voor het repareren van één ontbrekende VPN-route biedt de herstelvolgorde wanneer één tunnel per ongeluk het verkeer van de andere opvangt.

De configuratie is alleen veilig wanneer beide tunnels in elke ondersteunde volgorde opnieuw verbinden, elke taak zijn bedoelde pad volgt, DNS voorspelbaar blijft en het uitschakelen van één VPN het beheer-verkeer niet blokkeert. Houd een lokale console of niet-VPN herstelpad beschikbaar voordat je beide diensten automatisch bij het opstarten laat starten.