Varför krossar en andra VPN-tunnel den första?

Att installera en andra VPN-klient för att nå ett kundnätverk är det vanliga sättet detta börjar, och den första tunneln slocknar medan båda klienterna rapporterar framgång. Varje klient installerade en standardrutt, den andra var mer specifik, och kärnan följer den nu för allt utom den första tunnelns egen yttre anslutning. Ingenting kraschade och ingen profil är fel. En rutt ersatte en annan, och lösningen är att bestämma vilken tunnel som ska äga standardrutten.

Symtomet: den andra klienten vinner tyst

OpenVPN: alternativet redirect-gateway def1 skriver inte över 0.0.0.0/0. Det lägger till 0.0.0.0/1 och 128.0.0.0/1: tillsammans täcker de varje IPv4-adress, och varje prefix slår en vanlig standardrutt på längd. Den ursprungliga standardrutten stannar i tabellen och används inte längre för vanlig trafik, och en värdrutt till VPN-servern hindrar tunneln från att fånga sina egna yttre paket. Båda klienterna gör detta, och den andra installerar bara sitt par senare.

Därför ser den första tunneln död ut i stället för frånkopplad. Dess gränssnitt är uppe, dess kontrollkanal lever, och ingen applikationstrafik når den längre. Det omvända klagomålet har samma saknade push: en telefon som ansluter men inte skickar något talar oftast med en server som aldrig annonserade redirect-gateway, så enheten behåller sin egen standardrutt och når bara poolen.

Ta en ruttögonblicksbild före och efter att den andra klienten ansluter. De två halva rutter som dyker upp i tabellen är hela förändringen, och de förklarar båda klagomålen. Inget annat i tabellen behöver flytta sig för att symtomet ska uppstå. Därför återställer borttagningen av den andra klienten den första omedelbart.

Läs vilken tunnel som faktiskt vinner

Härled inte vinnaren från ordningen klienterna startade i eller från ikonen i aktivitetsfältet. Fråga kärnan vilken rutt den skulle använda för en destination utanför båda de privata näten, och läs gränssnittet som kommer tillbaka.

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

De två första är Linux-svaret och de två sista Windows-motsvarigheten. Kör dem medan båda tunnlarna är uppe, koppla sedan från en och kör dem igen. Skillnaden mellan de två utskrifterna är det faktum du behöver innan du väljer en lösning, och det tar kortare tid än att läsa loggen för någon av klienterna.

Skriv ner resultatet, inklusive gränssnittsnamnet och prefixet som matchade. En biljett som säger att den andra VPN:en förstörde den första är en beskrivning av symtomet, inte ett ruttpåstående som någon kan agera på. Uppslaget gör det till ett faktum som nästa ingenjör kan återskapa med ett enda kommando.

Windows: hindra en profil från att äga standardrutten

Windows sparar profiler, och den inbyggda klienten låter en bero på en annan så att den första kommer upp automatiskt när den andra ringer upp. Profilen som anslöt senast tenderar att behålla standardrutten, så den praktiska ägaren är den sista uppringningen och inte den första. Ge varje profil sina egna push-rutter och slå på split tunneling för den som inte ska äga standardrutten.

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

Split tunneling ändrar detta: bara prefix som servern pushar landar i tabellen, vilket lämnar standardrutten hos den första tunneln. Designen misslyckas fortfarande om båda servrarna pushar en standardrutt, för då vinner den sista anslutningen och ingen inställning på klientsidan ändrar det. Rätta pushen på serversidan eller acceptera en ägare.

Apputlösta profiler är en annan funktion och värd att känna till: en Windows-profil kan starta när en namngiven körbar fil startar, med trafikfilter som avgör vad den bär. Det är en profilinställning och inte en brandväggsregel, och det löser ett annat problem än konflikten om standardrutten.

Linux: håll den andra tunneln utanför huvudtabellen

Att köra två openvpn --config-instanser på en maskin sätter båda klienterna i samma tabell, och tre alternativ skiljer dem med ökande isolering. Lättast är att hindra den andra klienten från att redigera tabellen alls, med route-nopull och explicita rutter, eller ett route-up-skript som bara installerar det du avser. Då bär den andra tunneln exakt de prefix du namnger och inget annat. Då bestämmer du vilka prefix som går vart i stället för att upptäcka det efteråt.

Policy-routing är mellanalternativet. En regel väljer en separat tabell för en källadress eller brandväggsmarkering, och den tabellen bär rutterna för den andra tunneln. Omvänd vägfiltrering är fällan här, eftersom ett svar som anländer på ett annat gränssnitt än det tabellen skulle välja kastas, så kontrollera inställningen rp_filter innan du drar slutsatsen att tunneln är trasig.

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

Nätverksnamnrymder är det tyngsta och renaste alternativet. Starta den andra klienten inuti ip netns, ge den ett veth-par och gå in i den namnrymden för att använda den. Störningar försvinner eftersom varje namnrymd äger egna tabeller i stället för att dela en, vilket är värt den extra konfigurationen när båda tunnlarna måste stå uppe i veckor.

Per applikation, och kedjning som ett eget problem

Ibland bör bara ett program använda den andra tunneln. På Linux når policy-routing per användare, cgroup eller port det resultatet, och en enda destination kan fästas vid ett gränssnitt utan att röra standardrutten alls. Ett program som fäster sin socket vid ett gränssnitt konsulterar aldrig ruttabellen, så en startare kan fortsätta använda den fysiska adaptern tills en adress väljs i dess egna inställningar.

Kedjning är en annan operation än att köra två tunnlar sida vid sida. Att kedja A över B betyder att adressen till den inre servern måste vara nåbar inifrån den yttre tunneln. Den yttre klienten får inte heller förväxla den inre klientens krypterade paket med ett läckage. En klient i en virtuell maskin är den grova men pålitliga versionen; båda på en värd kräver ruttarbetet ovan plus en yttre väg mot den inre servern som aldrig går in i den inre tunneln.

Skriv upp ägaren av standardrutten, prefixlistan varje tunnel bär och DNS-vägen. De tre fakta gör nästa incident till ett uppslag i stället för en utredning.