Twee VPN-clients op één desktop: wat botst en wat werkt

Uw tweede client maakt verbinding, de bronnen van de eerste lossen niet meer op, en het ticket zegt dat de werk-VPN de persoonlijke heeft kapotgemaakt. Niets is kapot in de zin van een storing: beide clients deden waarvoor ze zijn ontworpen, en de machine heeft maar één routetabel. De botsing gaat over vier bronnen die elke client als zijn eigendom beschouwt. Werk ze op volgorde af, en de oplossing wordt meestal een ontwerpkeuze in plaats van een reparatie.

Stap 1: zoek uit welke client de uitgang bezit

Lees de huidige uitgangsbeslissing voordat u iets wijzigt. De routeopzoeking voor een openbaar adres vertelt u welke interface en welke volgende hop een pakket nu zou gebruiken, en dat is het antwoord op wie heeft gewonnen. Vergelijk dat met de interfacenamen die de clients hebben aangemaakt, die meestal de product- of protocolnaam dragen. Als de opzoeking naar de tunnel wijst die u niet verwachtte, hebt u de botsing al gevonden.

ip route get 1.1.1.1
ip route show default
route print

Sommige clients vervangen de standaardroute helemaal niet; ze voegen twee helften toe, één voor de onderste helft van de adresruimte en één voor de bovenste, die samen alles dekken. Dat laat de oorspronkelijke standaardroute zichtbaar en laat een handmatige reparatie correct lijken terwijl het verkeer nog steeds via de tunnel vertrekt. Lees de metriek en de prefixlengte, niet alleen de aanwezigheid van een standaardvermelding.

Stop als beide clients dezelfde prefix met dezelfde metriek opeisen. De kernel kiest er één, en de andere lijkt verbonden terwijl hij niets vervoert.

Stap 2: controleer de resolver en de overlappende prefixen

DNS is de tweede botsing, en die geeft een kenmerkend symptoom: namen falen terwijl adressen werken. Elke client dringt zijn eigen resolver door, en de laatste schrijver wint voor de volgende queries. Vraag de resolverdienst wat hij per verbinding gebruikt in plaats van de instellingenpagina van de client te lezen.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Vergelijk daarna de privéprefixen die de twee netwerken gebruiken. Als beide kanten uit dezelfde reeks toewijzen, lost geen enkele clientzijdige regeling dat op, omdat de machine niet kan zeggen welk 10.0.0.0/8-doel bij welke tunnel hoort. Eén kant moet opnieuw worden genummerd of vertaald, en dat is een gesprek met de netwerkeigenaren, geen configuratiewijziging. Overlap is de enige botsing waarbij het eerlijke antwoord is dat het ontwerp moet veranderen.

Stop hier als de prefixen overlappen. Alles verder in deze lijst gaat ervan uit dat ze dat niet doen.

Stap 3: kies een scheidingspatroon dat standhoudt

De betrouwbare patronen vermijden twee clients tegen dezelfde routetabel. Eén client met een split-tunnelbeleid dat beide privénetwerken bereikt is het eenvoudigst, mits de bestemmingen niet overlappen en de eigenaar van het beleid instemt. Een virtuele machine of een netwerknaamruimte is de volgende stap, omdat elk zijn eigen tabel en zijn eigen resolver krijgt.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Een naamruimte geeft dezelfde scheiding als een virtuele machine zonder het tweede besturingssysteem, maar heeft ruwe randen: het tunnelapparaat moet erin worden verplaatst, en de toepassing moet erbinnen worden gestart. Een apart fysiek apparaat is vaak de minst verrassende optie voor een persoonlijke VPN naast een beheerde werkclient. Eén tunnel in een andere stapelen is geen scheidingspatroon; het binnenste eindpunt moet bereikbaar blijven via de buitenste tunnel, en de opstelling voegt daar MTU- en latentieproblemen aan toe.

Kies één patroon en schrijf op waarom. Een naamruimte voor één toepassing mengen met een split-tunnel voor de rest herschept de oorspronkelijke botsing in een moeilijker te debuggen vorm.

Stap 4: verifieer beide netwerken vanuit dezelfde sessie

Test één bron op elk privénetwerk vanuit de omgeving waar de toepassing echt draait, niet vanuit uw shell als de app in een naamruimte draait. Controleer de uitgangsinterface, het opgeloste adres en de responscode samen, omdat een succes in één van de drie een fout in de andere kan verbergen. Herhaal na een herstart, omdat de volgorde waarin clients starten bepaalt wie wint. Juist die volgorde vergeten mensen vast te leggen.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Noteer de clientversies, de interfaces, de toestand van de resolver en de prefixen voor elk netwerk. Wanneer een client wordt bijgewerkt en zijn routegedrag verandert, is die registratie het verschil tussen een reparatie van vijf minuten en een herbouw. De volgende persoon deelt niet uw geheugen over welke tunnel het eerst omhoogkwam.

De lijst is compleet wanneer u de interface kunt noemen die de standaardroute bezit, de resolver die elke naam gebruikt, het patroon dat de tweede tunnel scheidt en het resultaat van één verzoek per netwerk na een herstart. Alles minder is een configuratie die vandaag toevallig werkt.