To VPN-klienter på én skrivebordsmaskin: hva som kolliderer, og hva som virker

Den andre klienten din kobler til, ressursene til den første slutter å løses opp, og saken sier at arbeids-VPN-en ødela den personlige. Ingenting er ødelagt i betydningen feil: begge klientene gjorde det de er laget for, og maskinen har bare én rutetabell. Kollisjonen gjelder fire ressurser som hver klient antar at den eier. Gå gjennom dem i rekkefølge, og rettelsen blir vanligvis et designvalg i stedet for en reparasjon.

Trinn 1: finn ut hvilken klient som eier utgangen

Les den gjeldende utgangsbeslutningen før du endrer noe. Ruteoppslaget for en offentlig adresse forteller deg hvilket grensesnitt og hvilket neste hopp en pakke ville brukt akkurat nå, og det er svaret på hvem som vant. Sammenlign det med grensesnittnavnene klientene har opprettet, som vanligvis bærer produkt- eller protokollnavnet. Hvis oppslaget peker på tunnelen du ikke forventet, har du allerede funnet kollisjonen.

ip route get 1.1.1.1
ip route show default
route print

Noen klienter erstatter ikke standardruten i det hele tatt; de legger til to halvdeler, én for den nedre halvdelen av adresserommet og én for den øvre, som til sammen dekker alt. Det lar den opprinnelige standardruten være synlig og får en manuell reparasjon til å se riktig ut mens trafikken fortsatt går ut gjennom tunnelen. Les metrikken og prefikslengden, ikke bare om det finnes en standardoppføring.

Stopp hvis begge klientene krever samme prefiks med samme metrikk. Kjernen velger én, og den andre vil se tilkoblet ut mens den ikke bærer noe.

Trinn 2: kontroller resolveren og de overlappende prefiksene

DNS er den andre kollisjonen, og den gir et særegent symptom: navn feiler mens adresser virker. Hver klient skyver sin egen resolver gjennom, og den siste som skriver vinner for spørringene som følger. Spør resolvertjenesten hva den bruker per lenke i stedet for å lese innstillingssiden til klienten.

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

Sammenlign deretter de private prefiksene de to nettverkene bruker. Hvis begge sider tildeler fra samme område, vil ingen klient-side ordning rette det, fordi maskinen ikke kan si hvilken 10.0.0.0/8-destinasjon som hører til hvilken tunnel. Én side må omnummereres eller oversettes, og det er en samtale med nettverkseierne i stedet for en konfigurasjonsendring. Overlapp er den ene kollisjonen der det ærlige svaret er at designet må endres.

Stopp her hvis prefiksene overlapper. Alt senere i denne sjekklisten forutsetter at de ikke gjør det.

Trinn 3: velg et separasjonsmønster som holder

De pålitelige mønstrene unngår å kjøre to klienter mot samme rutetabell. Én klient med en split-tunnel-policy som når begge de private nettverkene er det enkleste, forutsatt at destinasjonene ikke overlapper og eieren av policyen er enig. En virtuell maskin eller et nettverksnavnerom er neste trinn, fordi hver får sin egen tabell og 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/

Et navnerom gir samme separasjon som en virtuell maskin uten det andre operativsystemet, men det har skarpe kanter: tunnel-enheten må flyttes inn i det, og programmet må startes inni det. En egen fysisk enhet er ofte det minst overraskende valget for en personlig VPN ved siden av en administrert arbeidsklient. Å stable én tunnel inni en annen er ikke et separasjonsmønster; det indre endepunktet må forbli tilgjengelig gjennom den ytre tunnelen, og ordningen legger på MTU- og latenstidsproblemer i tillegg.

Velg ett mønster og skriv ned hvorfor. Å blande et navnerom for ett program med en split-tunnel for resten gjenoppretter den opprinnelige kollisjonen i en vanskeligere feilsøkbar form.

Trinn 4: verifiser begge nettverkene fra samme økt

Test én ressurs på hvert private nettverk fra miljøet der programmet faktisk kjører, ikke fra skallet ditt hvis appen kjører inne i et navnerom. Kontroller utgangsgrensesnittet, den oppløste adressen og svarkoden sammen, fordi en suksess i én av de tre kan skjule en feil i de andre. Gjenta etter en omstart, siden rekkefølgen klientene starter i avgjør hvem som vinner. Nettopp den rekkefølgen glemmer folk å notere.

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

Noter klientversjonene, grensesnittene, resolverens tilstand og prefiksene for hvert nettverk. Når en klient oppdateres og endrer ruteatferden sin, er den registreringen forskjellen mellom en fem minutters rettelse og en gjenoppbygging. Den neste personen deler ikke din hukommelse om hvilken tunnel som kom opp først.

Sjekklisten er komplett når du kan navngi grensesnittet som eier standardruten, resolveren hvert navn bruker, mønsteret som skiller den andre tunnelen, og resultatet av én forespørsel per nettverk etter en omstart. Alt mindre er en konfigurasjon som tilfeldigvis virker i dag.