To VPN-klienter på én computer: hvad kolliderer, og hvad virker

Din anden klient opretter forbindelse, den førstes ressourcer holder op med at blive opløst, og billetten siger, at arbejds-VPN'en ødelagde den personlige. Intet er ødelagt i betydningen fejl: begge klienter gjorde, hvad de var designet til, og maskinen har kun én routingtabel. Kollisionen handler om fire ressourcer, som hver klient antager, at den ejer. Gå dem igennem i rækkefølge, og rettelsen bliver normalt et designvalg frem for en reparation.

Trin 1: find ud af, hvilken klient der ejer udgangen

Læs den aktuelle udgangsbeslutning, før du ændrer noget. Ruteopslaget for en offentlig adresse fortæller dig, hvilken grænseflade og næste hop en pakke ville bruge lige nu, og det er svaret på, hvem der vandt. Sammenlign det med de grænsefladenavne, klienterne har oprettet, som normalt bærer produkt- eller protokolnavnet. Hvis opslaget peger på den tunnel, du ikke forventede, har du allerede fundet kollisionen.

ip route get 1.1.1.1
ip route show default
route print

Nogle klienter erstatter slet ikke standardruten; de tilføjer to halvdele, en til den nederste halvdel af adresseområdet og en til den øverste, som tilsammen dækker alt. Det lader den oprindelige standardrute være synlig og får en manuel rettelse til at se korrekt ud, mens trafikken stadig forlader gennem tunnelen. Læs metrikken og præfiksets længde, ikke bare tilstedeværelsen af en standardpost.

Stop, hvis begge klienter kræver det samme præfiks med samme metrik. Kernen vælger én, og den anden vil se forbundet ud, mens den ikke bærer noget.

Trin 2: kontroller resolveren og de overlappende præfikser

DNS er den anden kollision, og den giver et særpræget symptom: navne fejler, mens adresser virker. Hver klient skubber sin egen resolver igennem, og den sidste skribent vinder for de efterfølgende forespørgsler. Spørg resolvertjenesten, hvad den bruger pr. link, i stedet for at læse klientens indstillingsside.

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

Sammenlign derefter de private præfikser, som de to netværk bruger. Hvis begge sider tildeler fra samme interval, vil intet klientopsætning rette det, fordi maskinen ikke kan se, hvilken 10.0.0.0/8-destination der hører til hvilken tunnel. Den ene side skal omnummereres eller oversættes, og det er en samtale med netværksejerne frem for en konfigurationsændring. Overlap er den ene kollision, hvor det ærlige svar er, at designet skal ændres.

Stop her, hvis præfikserne overlapper. Alt senere i denne tjekliste forudsætter, at de ikke gør.

Trin 3: vælg et adskillelsesmønster, der holder

De pålidelige mønstre undgår at køre to klienter mod den samme routingtabel. Én klient med en split-tunnel-politik, der når begge private netværk er det enkleste, forudsat at destinationerne ikke overlapper, og at politikkens ejer er enig. En virtuel maskine eller et netværksnavnerum er næste trin, fordi hver får sin egen tabel 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 navnerum giver samme adskillelse som en virtuel maskine uden det andet styresystem, men det har skarpe kanter: tunnelanordningen skal flyttes ind i det, og programmet skal startes indeni. En separat fysisk enhed er ofte den mindst overraskende mulighed for en personlig VPN ved siden af en administreret arbejdsklient. At stable en tunnel ind i en anden er ikke et adskillelsesmønster; det indre endepunkt skal forblive tilgængeligt gennem den ydre tunnel, og arrangementet tilføjer MTU- og latenstidsproblemer oveni.

Vælg ét mønster, og skriv ned hvorfor. At blande et navnerum til ét program med en split-tunnel til resten genskaber den oprindelige kollision i en sværere fejlfindingsvenlig form.

Trin 4: verificer begge netværk fra samme session

Test én ressource på hvert privat netværk fra det miljø, hvor programmet faktisk kører, ikke fra din shell, hvis programmet kører inde i et navnerum. Kontroller udgangsgrænsefladen, den opløste adresse og svarkoden sammen, fordi en succes i én af de tre kan skjule en fejl i de andre. Gentag efter en genstart, da den rækkefølge, klienterne starter i, afgør, hvem der vinder. Netop den rækkefølge glemmer folk at notere.

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

Noter klientversionerne, grænsefladerne, resolverens tilstand og præfikserne for hvert netværk. Når en klient opdateres og ændrer sin ruteadfærd, er den registrering forskellen mellem en fem minutters rettelse og en genopbygning. Den næste person deler ikke din hukommelse om, hvilken tunnel der kom op først.

Tjeklisten er komplet, når du kan navngive den grænseflade, der ejer standardruten, den resolver, hvert navn bruger, det mønster, der adskiller den anden tunnel, og resultatet af én anmodning pr. netværk efter en genstart. Alt mindre er en konfiguration, der tilfældigvis virker i dag.