Kvifor øydelegg ein andre VPN-tunnel den første?

Å installere ein andre VPN-klient for å nå eitt kundenettverk er den vanlege måten dette byrjar på, og den første tunnelen blir mørk medan begge klientane rapporterer suksess. Kvar klient installerte ei standardrute, den andre var meir spesifikk, og kjernen følgjer henne no for alt bortsett frå den første tunnelen si eiga ytre tilknyting. Ingenting krasja, og ingen profil er feil. Éi rute erstatta ei anna, og løysinga er å avgjere kva tunnel som skal eige standardruta.

Symtomet: den andre klienten vinn stille

OpenVPN: valet redirect-gateway def1 overskriv ikkje 0.0.0.0/0. Det legg til 0.0.0.0/1 og 128.0.0.0/1: saman dekkjer dei kvar IPv4-adresse, og kvart prefiks slår ei vanleg standardrute på lengd. Den opphavlege standardruta blir i tabellen og blir ikkje lenger brukt til vanleg trafikk, og ei vertsrute til VPN-tenaren hindrar tunnelen i å fange eigne ytre pakkar. Begge klientane gjer dette, og den andre installerer berre paret sitt seinare.

Difor ser den første tunnelen død ut i staden for fråkopla. Grensesnittet er oppe, kontrollkanalen er levande, og ingen applikasjonstrafikk når han lenger. Den motsette klaga har same manglande push: ein telefon som koplar til men ikkje sender noko, snakkar vanlegvis med ein tenar som aldri annonserte redirect-gateway, så eininga held på si eiga standardrute og når berre bassenget.

Ta eit rutebilete før og etter at den andre klienten koplar til. Dei to halve rutene som dukkar opp i tabellen, er heile endringa, og dei forklarar begge klagene. Ingenting anna i tabellen treng å flytte seg for at symtomet skal oppstå. Difor gjenopprettar fjerninga av den andre klienten den første med det same.

Les kva tunnel som faktisk vinn

Ikkje utleid vinnaren av rekkjefølgja klientane starta i eller av ikonet i systemkurven. Spør kjernen kva rute han ville brukt for ein destinasjon utanfor begge dei private netta, og les grensesnittet som kjem tilbake.

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

Dei to første er Linux-svaret og dei to siste Windows-ekvivalenten. Køyr dei medan begge tunnelane er oppe, kopl deretter frå éin og køyr dei igjen. Skilnaden mellom dei to utdata er det faktumet du treng før du vel ei løysing, og det tek kortare tid enn å lese loggen til ein av klientane.

Skriv ned resultatet, inkludert grensesnittnamnet og prefikset som samsvarte. Ei sak som seier at den andre VPN-en øydela den første, er ei skildring av symtomet, ikkje ei ruteuttale nokon kan handle på. Oppslaget gjer det til eit faktum den neste ingeniøren kan gjenskape med éin kommando.

Windows: hindre at éin profil eig standardruta

Windows lagrar profilar, og den innebygde klienten lèt éin avhenge av ein annan, slik at den første kjem opp automatisk når den andre ringer. Profilen som kopla til sist, har ein tendens til å halde standardruta, så den praktiske eigaren er den siste oppkoplinga og ikkje den første. Gi kvar profil eigne push-ruter og slå på split tunneling for den som ikkje skal eige standardruta.

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

Split tunneling endrar dette: berre prefiks tenaren pushar, landar i tabellen, noko som lèt den første tunnelen halde standardruta. Designet feilar framleis om begge tenarane pushar ei standardrute, for då vinn den siste tilknytinga, og ingen innstilling på klientsida endrar det. Retta opp pushen på tenarsida eller godta éin eigar.

App-utløyste profilar er ein annan funksjon og verdt å kjenne: ein Windows-profil kan starte når ei namngitt køyrbar fil startar, med trafikkfilter som avgjer kva han ber. Det er ei profilinnstilling og ikkje ein brannmurregel, og det løyser eit anna problem enn konflikten om standardruta.

Linux: hald den andre tunnelen utanfor hovudtabellen

Å køyre to openvpn --config-instansar på éi maskin set begge klientane i same tabell, og tre alternativ skil dei med aukande isolasjon. Den lettaste er å hindre den andre klienten i å redigere tabellen i det heile, med route-nopull og eksplisitte ruter, eller eit route-up-skript som berre installerer det du har tenkt. Då ber den andre tunnelen nøyaktig prefiksa du namngir og ingenting anna. Då avgjer du kva prefiks som går kvar, i staden for å oppdage det etterpå.

Policy-ruting er mellomalternativet. Ei regel vel ein eigen tabell for éi kjeldeadresse eller brannmurmarkering, og den tabellen ber rutene for den andre tunnelen. Reversert sti-filtrering er fella her, fordi eit svar som kjem på eit anna grensesnitt enn det tabellen ville velje, blir forkasta, så sjekk innstillinga rp_filter før du konkluderer med at tunnelen er øydelagd.

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

Nettverksnamnerom er det tyngste og reinaste alternativet. Start den andre klienten inne i ip netns, gi han eit veth-par, og gå inn i det namnerommet for å bruke det. Forstyrringar forsvinn fordi kvart namnerom eig eigne tabellar i staden for å dele éin, noko som er verdt den ekstra oppsetjinga når begge tunnelane må stå oppe i veker.

Per applikasjon, og kjedling som eit eige problem

Nokre gonger bør berre eitt program bruke den andre tunnelen. På Linux oppnår policy-ruting etter brukar, cgroup eller port det resultatet, og éin destinasjon kan festast til eit grensesnitt utan å røre standardruta i det heile. Eit program som festar sokkelen sin til eitt grensesnitt, konsulterer ikkje rutetabellen i det heile, så ein oppstartar kan halde fram med å bruke den fysiske adapteren til ei adresse blir vald i eigne innstillingar.

Kjedling er ei anna operasjon enn å køyre to tunnelar side om side. Å kjedje A over B betyr at adressa til den indre tenaren må vere nåbar frå innsida av den ytre tunnelen. Den ytre klienten må heller ikkje forveksle dei krypterte pakkane til den indre klienten med ei lekkasje. Éin klient i ein virtuell maskin er den grove, men pålitelege versjonen; begge på éin vert krev rutearbeidet ovanfor pluss ein ytre veg mot den indre tenaren som aldri går inn i den indre tunnelen.

Skriv ned eigaren av standardruta, prefikslista kvar tunnel ber, og DNS-vegen. Dei tre fakta gjer den neste hendinga til eit oppslag i staden for ei undersøking.