Två VPN-klienter på en dator: vad som krockar och vad som fungerar

Din andra klient ansluter, den förstas resurser slutar lösas och ärendet säger att arbets-VPN:en förstörde den personliga. Inget är trasigt i betydelsen fel: båda klienterna gjorde det de är byggda för, och maskinen har bara en routingtabell. Krocken gäller fyra resurser som varje klient antar att den äger. Gå igenom dem i ordning, och åtgärden blir vanligen ett designval i stället för en reparation.

Steg 1: ta reda på vilken klient som äger utgången

Läs det aktuella utgångsbeslutet innan du ändrar något. Vägsökningen för en offentlig adress berättar vilket gränssnitt och vilket nästa hopp ett paket skulle använda just nu, och det är svaret på vem som vann. Jämför det med gränssnittsnamnen som klienterna skapat, som vanligen bär produkt- eller protokollnamnet. Om sökningen pekar mot tunneln du inte förväntade dig har du redan hittat krocken.

ip route get 1.1.1.1
ip route show default
route print

Vissa klienter ersätter inte standardrutten alls; de lägger till två halvor, en för den nedre halvan av adressutrymmet och en för den övre, som tillsammans täcker allt. Det låter den ursprungliga standardrutten synas och får en manuell reparation att se korrekt ut medan trafiken fortfarande går ut genom tunneln. Läs metrik och prefixlängd, inte bara förekomsten av en standardpost.

Stanna om båda klienterna gör anspråk på samma prefix med samma metrik. Kärnan väljer en, och den andra kommer att se ansluten ut utan att bära något.

Steg 2: kontrollera resolvern och de överlappande prefixen

DNS är den andra krocken och ger ett säreget symptom: namn misslyckas medan adresser fungerar. Varje klient trycker igenom sin egen resolver, och den sista skrivaren vinner för de följande frågorna. Fråga resolvertjänsten vad den använder per länk i stället för att läsa klientens inställningssida.

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

Jämför sedan de privata prefix som de två näten använder. Om båda sidor tilldelar från samma område löser ingen klient-sidig åtgärd det, eftersom maskinen inte kan säga vilken 10.0.0.0/8-destination som hör till vilken tunnel. En sida måste numreras om eller översättas, och det är ett samtal med nätägarna snarare än en konfigurationsändring. Överlapp är den enda krocken där det ärliga svaret är att designen måste ändras.

Stanna här om prefixen överlappar. Allt senare i denna checklista förutsätter att de inte gör det.

Steg 3: välj ett separationsmönster som håller

De pålitliga mönstren undviker att köra två klienter mot samma routingtabell. En klient med en split-tunnel-policy som når båda de privata näten är det enklaste, förutsatt att destinationerna inte överlappar och att policyägaren samtycker. En virtuell maskin eller ett nätverksnamnrum är nästa steg, eftersom var och en får sin egen tabell och sin egen resolver.

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

Ett namnrum ger samma separation som en virtuell maskin utan det andra operativsystemet, men det har skarpa kanter: tunnelenheten måste flyttas in i det, och programmet måste startas inuti det. En separat fysisk enhet är ofta det minst överraskande valet för en personlig VPN vid sidan av en hanterad arbetsklient. Att stapla en tunnel inuti en annan är inte ett separationsmönster; den inre ändpunkten måste förbli nåbar genom den yttre tunneln, och arrangemanget lägger dessutom till MTU- och latensproblem.

Välj ett mönster och skriv ned varför. Att blanda ett namnrum för ett program med en split-tunnel för resten återskapar den ursprungliga krocken i en svårare felsökt form.

Steg 4: verifiera båda näten från samma session

Testa en resurs på varje privat nät från miljön där programmet faktiskt körs, inte från ditt skal om appen körs inne i ett namnrum. Kontrollera utgångsgränssnittet, den upplösta adressen och svarskoden tillsammans, eftersom en framgång i en av de tre kan dölja ett fel i de andra. Upprepa efter en omstart, eftersom ordningen klienterna startar i avgör vem som vinner. Det är den ordningen folk glömmer att anteckna.

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

Anteckna klientversionerna, gränssnitten, resolverstatusen och prefixen för varje nät. När en klient uppdateras och ändrar sitt routingbeteende är den anteckningen skillnaden mellan en femminutersrättelse och en ombyggnad. Nästa person delar inte ditt minne av vilken tunnel som kom upp först.

Checklistan är komplett när du kan namnge gränssnittet som äger standardrutten, resolvern varje namn använder, mönstret som separerar den andra tunneln och resultatet av en begäran per nät efter en omstart. Allt mindre är en konfiguration som råkar fungera i dag.