Hvorfor ødelegger en andre VPN-tunnel den første?

Å installere en andre VPN-klient for å nå ett kundenettverk er den vanlige måten dette begynner på, og den første tunnelen blir mørk mens begge klientene rapporterer suksess. Hver klient installerte en standardrute, den andre var mer spesifikk, og kjernen følger den nå for alt bortsett fra den første tunnelens egen ytre forbindelse. Ingenting krasjet, og ingen profil er feil. Én rute erstattet en annen, og løsningen er å bestemme hvilken tunnel som skal eie standardruten.

Symptomet: den andre klienten vinner stille

OpenVPN: alternativet redirect-gateway def1 overskriver ikke 0.0.0.0/0. Det legger til 0.0.0.0/1 og 128.0.0.0/1: sammen dekker de hver IPv4-adresse, og hvert prefiks slår en vanlig standardrute på lengde. Den opprinnelige standardruten blir i tabellen og brukes ikke lenger for vanlig trafikk, og en vertsrute til VPN-serveren hindrer tunnelen i å fange egne ytre pakker. Begge klientene gjør dette, og den andre installerer bare paret sitt senere.

Derfor ser den første tunnelen død ut i stedet for frakoblet. Grensesnittet er oppe, kontrollkanalen er levende, og ingen applikasjonstrafikk når den lenger. Den motsatte klagen har samme manglende push: en telefon som kobler til men ikke sender noe, snakker vanligvis med en server som aldri annonserte redirect-gateway, så enheten beholder sin egen standardrute og når bare bassenget.

Ta et rutebilde før og etter at den andre klienten kobler til. De to halve rutene som dukker opp i tabellen, er hele endringen, og de forklarer begge klagene. Ingenting annet i tabellen trenger å flytte seg for at symptomet skal oppstå. Derfor gjenoppretter fjerningen av den andre klienten den første umiddelbart.

Les hvilken tunnel som faktisk vinner

Ikke utled vinneren av rekkefølgen klientene startet i eller av ikonet i systemkurven. Spør kjernen hvilken rute den ville brukt for en destinasjon utenfor begge de private nettene, og les grensesnittet som kommer tilbake.

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 siste Windows-ekvivalenten. Kjør dem mens begge tunnelene er oppe, koble deretter fra én og kjør dem igjen. Forskjellen mellom de to utdataene er det faktum du trenger før du velger en løsning, og det tar kortere tid enn å lese loggen til en av klientene.

Skriv ned resultatet, inkludert grensesnittnavnet og prefikset som samsvarte. En sak som sier at den andre VPN-en ødela den første, er en beskrivelse av symptomet, ikke en ruteuttalelse noen kan handle på. Oppslaget gjør det til et faktum den neste ingeniøren kan gjenskape med én kommando.

Windows: hindre at én profil eier standardruten

Windows lagrer profiler, og den innebygde klienten lar én avhenge av en annen, slik at den første kommer opp automatisk når den andre ringer. Profilen som koblet til sist, har en tendens til å beholde standardruten, så den praktiske eieren er den siste oppkoblingen og ikke den første. Gi hver profil egne push-ruter og slå på split tunneling for den som ikke skal eie standardruten.

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

Split tunneling endrer dette: bare prefikser serveren pusher, lander i tabellen, noe som lar den første tunnelen beholde standardruten. Designet feiler fortsatt hvis begge serverne pusher en standardrute, for da vinner den siste forbindelsen, og ingen innstilling på klientsiden endrer det. Rett opp pushen på serversiden eller godta én eier.

App-utløste profiler er en annen funksjon og verdt å kjenne: en Windows-profil kan starte når en navngitt kjørbar fil startes, med trafikkfiltre som bestemmer hva den bærer. Det er en profilinnstilling og ikke en brannmurregel, og det løser et annet problem enn konflikten om standardruten.

Linux: hold den andre tunnelen utenfor hovedtabellen

Å kjøre to openvpn --config-instanser på én maskin setter begge klientene i samme tabell, og tre alternativer skiller dem med økende isolasjon. Den letteste er å hindre den andre klienten i å redigere tabellen i det hele tatt, med route-nopull og eksplisitte ruter, eller et route-up-skript som bare installerer det du har tenkt. Da bærer den andre tunnelen nøyaktig prefiksene du navngir og ingenting annet. Da bestemmer du hvilke prefikser som går hvor, i stedet for å oppdage det etterpå.

Policy-ruting er mellomalternativet. En regel velger en egen tabell for én kildeadresse eller brannmurmarkering, og den tabellen bærer rutene for den andre tunnelen. Reversert sti-filtrering er fellen her, fordi et svar som ankommer på et annet grensesnitt enn det tabellen ville velge, blir forkastet, så sjekk innstillingen rp_filter før du konkluderer med 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

Nettverksnavnerom er det tyngste og reneste alternativet. Start den andre klienten inne i ip netns, gi den et veth-par, og gå inn i det navnerommet for å bruke det. Forstyrrelser forsvinner fordi hvert navnerom eier egne tabeller i stedet for å dele én, noe som er verdt den ekstra oppsettet når begge tunnelene må stå oppe i uker.

Per applikasjon, og kjedling som et eget problem

Noen ganger bør bare ett program bruke den andre tunnelen. På Linux oppnår policy-ruting etter bruker, cgroup eller port det resultatet, og én destinasjon kan festes til et grensesnitt uten å røre standardruten i det hele tatt. Et program som fester sokkelen sin til ett grensesnitt, konsulterer ikke rutetabellen i det hele tatt, så en oppstarter kan fortsette å bruke den fysiske adapteren til en adresse velges i egne innstillinger.

Kjedling er en annen operasjon enn å kjøre to tunneler side om side. Å kjede A over B betyr at adressen til den indre serveren må være nåbar fra innsiden av den ytre tunnelen. Den ytre klienten må heller ikke forveksle den indre klientens krypterte pakker med en lekkasje. Én klient i en virtuell maskin er den grove, men pålitelige versjonen; begge på én vert krever rutearbeidet ovenfor pluss en ytre vei mot den indre serveren som aldri går inn i den indre tunnelen.

Skriv ned eieren av standardruten, prefikslisten hver tunnel bærer, og DNS-veien. De tre faktaene gjør den neste hendelsen til et oppslag i stedet for en undersøkelse.