Hvorfor ødelægger en anden VPN-tunnel den første?

At installere en anden VPN-klient for at nå et kundenetværk er den sædvanlige måde, dette begynder på, og den første tunnel går sort, mens begge klienter rapporterer succes. Hver klient installerede en standardrute, den anden var mere specifik, og kernen følger den nu for alt undtagen den første tunnels egen ydre forbindelse. Intet styrtede ned, og ingen profil er forkert. Én rute erstattede en anden, og løsningen er at beslutte, hvilken tunnel der skal eje standardruten.

Symptomet: den anden klient vinder stille

OpenVPN: indstillingen redirect-gateway def1 overskriver ikke 0.0.0.0/0. Den tilføjer 0.0.0.0/1 og 128.0.0.0/1: sammen dækker de hver IPv4-adresse, og hvert præfiks slår en almindelig standardrute på længde. Den oprindelige standardrute bliver i tabellen og bruges ikke længere til almindelig trafik, og en værtsrute til VPN-serveren forhindrer tunnelen i at fange sine egne ydre pakker. Begge klienter gør dette, og den anden installerer blot sit par senere.

Derfor ser den første tunnel død ud i stedet for afbrudt. Dens grænseflade er oppe, dens kontrolkanal er levende, og ingen applikationstrafik når den længere. Den omvendte klage har det samme manglende push: en telefon, der forbinder men ikke sender noget, taler normalt med en server, der aldrig har annonceret redirect-gateway, så enheden beholder sin egen standardrute og når kun poolen.

Tag et rutebillede før og efter, at den anden klient forbinder. De to halve ruter, der dukker op i tabellen, er hele ændringen, og de forklarer begge klager. Intet andet i tabellen behøver at flytte sig, for at symptomet skal opstå. Derfor gendanner fjernelsen af den anden klient den første med det samme.

Læs, hvilken tunnel der faktisk vinder

Udled ikke vinderen af den rækkefølge, klienterne startede i, eller af ikonet i proceslinjen. Spørg kernen, hvilken rute den ville bruge til en destination uden for begge private netværk, og læs den grænseflade, der kommer retur.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

De to første er Linux-svaret, og de to sidste er Windows-ækvivalenten. Kør dem, mens begge tunneler er oppe, afbryd derefter én og kør dem igen. Forskellen mellem de to output er det faktum, du har brug for, før du vælger en løsning, og det tager kortere tid end at læse loggen for en af klienterne.

Skriv resultatet ned, inklusive grænsefladens navn og det præfiks, der matchede. En sag, der siger, at den anden VPN ødelagde den første, er en beskrivelse af symptomet, ikke en rutningserklæring, som nogen kan handle på. Opslaget gør det til et faktum, som den næste ingeniør kan genskabe med én kommando.

Windows: forhindr, at én profil ejer standardruten

Windows gemmer profiler, og den indbyggede klient lader én afhænge af en anden, så den første kommer op automatisk, når den anden ringer op. Den profil, der senest blev forbundet, har tendens til at beholde standardruten, så den praktiske ejer er det sidste opkald i stedet for det første. Giv hver profil sine egne push-ruter, og slå split tunneling til for den, der ikke bør eje standardruten.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Split tunneling ændrer det: kun præfikser, som serveren pusher, lander i tabellen, hvilket efterlader standardruten hos den første tunnel. Designet fejler stadig, hvis begge servere pusher en standardrute, for så vinder den sidste forbindelse, og ingen indstilling på klientsiden ændrer det. Ret pushet på serversiden, eller accepter én ejer.

App-udløste profiler er en anden funktion og værd at kende: en Windows-profil kan starte, når en navngivet eksekverbar fil starter, med trafikfiltre, der bestemmer, hvad den bærer. Det er en profilindstilling og ikke en firewallregel, og den løser et andet problem end konflikten om standardruten.

Linux: hold den anden tunnel ude af hovedtabellen

At køre to openvpn --config-instanser på én maskine sætter begge klienter i samme tabel, og tre muligheder adskiller dem med stigende isolation. Den letteste er at forhindre den anden klient i at redigere tabellen overhovedet, med route-nopull og eksplicitte ruter eller et route-up-script, der kun installerer det, du har til hensigt. Så bærer den anden tunnel præcis de præfikser, du navngiver, og intet andet. Så beslutter du, hvilke præfikser der går hvor, i stedet for at opdage det bagefter.

Policy routing er den mellemliggende mulighed. En regel vælger en separat tabel til én kildeadresse eller firewallmarkering, og den tabel bærer ruterne for den anden tunnel. Reverse-path-filtrering er fælden her, fordi et svar, der ankommer på en anden grænseflade end den, tabellen ville vælge, bliver kasseret, så tjek indstillingen rp_filter, før du konkluderer, at tunnelen er ødelagt.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Netværksnamespaces er den tungeste og reneste mulighed. Start den anden klient inde i ip netns, giv den et veth-par, og gå ind i det namespace for at bruge det. Forstyrrelser forsvinder, fordi hvert namespace ejer sine egne tabeller i stedet for at dele én, hvilket er den ekstra opsætning værd, når begge tunneler skal køre i uger.

Per applikation, og kædning som et separat problem

Nogle gange bør kun ét program bruge den anden tunnel. På Linux opnår policy routing efter bruger, cgroup eller port det resultat, og en enkelt destination kan fastgøres til en grænseflade uden at røre standardruten overhovedet. En applikation, der fastgør sin socket til én grænseflade, konsulterer slet ikke rutetabellen, så en launcher kan fortsætte med at bruge den fysiske adapter, indtil en adresse vælges i dens egne indstillinger.

Kædning er en anden operation end at køre to tunneler side om side. At kæde A over B betyder, at den indre servers adresse skal kunne nås fra inde i den ydre tunnel. Den ydre klient må heller ikke forveksle den indre klients krypterede pakker med en lækage. Én klient i en virtuel maskine er den grove, men pålidelige version; begge på én vært kræver rutearbejdet ovenfor plus en ydre vej mod den indre server, som aldrig går ind i den indre tunnel.

Skriv ejeren af standardruten ned, præfikslisten hver tunnel bærer, og DNS-vejen. De tre fakta gør den næste hændelse til et opslag i stedet for en undersøgelse.