Hoekom breek 'n tweede VPN-tonnel die eerste een?

Om 'n tweede VPN-kliënt te installeer om een klantnetwerk te bereik, is die gewone manier waarop dit begin, en die eerste tonnel word donker terwyl albei kliënte sukses rapporteer. Elke kliënt het 'n verstekroete geïnstalleer, die tweede een was meer spesifiek, en die kernel volg dit nou vir alles behalwe die eerste tonnel se eie buitenste verbinding. Niks het omgeval nie en geen profiel is verkeerd nie. Een roete het 'n ander vervang, en die oplossing is om te besluit watter tonnel die verstek moet besit.

Die simptoom: die tweede kliënt wen stilweg

OpenVPN se redirect-gateway def1 oorskryf nie 0.0.0.0/0 nie. Dit voeg 0.0.0.0/1 en 128.0.0.0/1 by: saam dek hulle elke IPv4-adres, en elke voorvoegsel klop 'n gewone verstek op lengte. Die oorspronklike verstek bly in die tabel en word nie meer vir gewone verkeer gebruik nie, en 'n gasheersroete na die VPN-bediener verhoed dat die tonnel sy eie buitenste pakkette vasvang. Albei kliënte doen dit, en die tweede een installeer bloot sy paar later.

Dit is hoekom die eerste tonnel dooierig lyk eerder as ontkoppel. Sy koppelvlak is op, sy beheerkanaal leef, en geen toepassingsverkeer bereik dit meer nie. Die omgekeerde klag kom van dieselfde ontbrekende stoot: 'n selfoon wat koppel maar niks stuur nie, praat gewoonlik met 'n bediener wat nooit redirect-gateway geadverteer het nie, so die toestel hou sy eie verstek en bereik net die poel.

Neem 'n roetefoto voor en nadat die tweede kliënt koppel. Die twee halfroetes wat in die tabel verskyn, is die hele verandering, en hulle verduidelik albei klagtes. Niks anders in die tabel hoef te skuif vir die simptoom om te verskyn nie. Dit is ook hoekom die verwydering van die tweede kliënt die eerste een dadelik herstel.

Lees watter tonnel werklik wen

Moenie die wenner aflei uit die volgorde waarin die kliënte begin het of uit die ikoon in die systeem nie. Vra die kernel watter roete dit vir 'n bestemming buite albei private netwerke sou gebruik, en lees die koppelvlak wat terugkom.

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

Die eerste twee is die Linux-antwoord en die laaste twee is die Windows-ekwivalent. Voer hulle uit terwyl albei tonnele op is, ontkoppel dan een en voer hulle weer uit. Die verskil tussen die twee uitsette is die feit wat jy nodig het voordat jy 'n oplossing kies, en dit neem minder tyd as om enige kliënt se log te lees.

Teken die resultaat aan, insluitend die koppelvlaknaam en die voorvoegsel wat gepas het. 'n Kaartjie wat sê die tweede VPN het die eerste gebreek, is 'n beskrywing van die simptoom, nie 'n roetestelling waarop enigiemand kan reageer nie. Die opsoek verander dit in 'n feit wat die volgende ingenieur in een opdrag kan reproduseer.

Windows: keer dat een profiel die verstek besit

Windows hou gestoorde profiele, en die ingeboude kliënt laat een van 'n ander afhang sodat die eerste outomaties opkom wanneer die tweede skakel. Watter profiel die meeste onlangs gekoppel het, hou geneig om die verstek te hou, so die praktiese eienaar is die laaste skakel eerder as die eerste. Gee elke profiel sy eie gestoorde roetes en skakel verdeelde tonneling aan vir die een wat nie die verstek moet besit nie.

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

Verdeelde tonneling verander dit: net voorvoegsels wat die bediener stoot, beland in die tabel, wat die eerste tonnel die verstek laat hou. Die ontwerp misluk steeds as albei bedieners 'n verstekroete stoot, want dan wen die laaste verbinding en geen kliëntkant-instelling verander dit nie. Maak die bedienerkant-stoot reg of aanvaar een eienaar.

Toepassinggeaktiveerde profiele is 'n ander funksie en die moeite werd om te ken: 'n Windows-profiel kan begin wanneer 'n genoemde uitvoerbare lêer begin, met verkeersfilters wat besluit wat dit dra. Dit is 'n profielinstelling eerder as 'n firewallreël, en dit los 'n ander probleem op as die verstekroete-konflik.

Linux: hou die tweede tonnel uit die hooftabel

Om twee openvpn --config-instansies op een masjien te laat loop, plaas albei kliënte in dieselfde tabel, en drie opsies skei hulle met toenemende isolasie. Die ligste is om die tweede kliënt heeltemal te keer om die tabel te redigeer, met route-nopull en eksplisiete roetes, of 'n route-up-skrip wat net installeer wat jy bedoel. Dan dra die tweede tonnel presies die voorvoegsels wat jy noem en niks anders nie. Dan besluit jy watter voorvoegsels waarheen gaan eerder as om dit daarna te ontdek.

Beleidsroetering is die middelste opsie. 'n Reël kies 'n aparte tabel vir een bronadres of firewallmerk, en daardie tabel dra die roetes vir die tweede tonnel. Omgekeerde-pad-filtering is die lokval hier, want 'n antwoord wat op 'n ander koppelvlak aankom as wat die tabel sou kies, word laat val, so kyk na die rp_filter-instelling voordat jy aflei die tonnel is stukkend.

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

Netwerknaamruimtes is die swaarste opsie en die skoonste. Begin die tweede kliënt binne ip netns, gee dit 'n veth-paar, en gaan daardie naamruimte binne om dit te gebruik. Steuring verdwyn omdat elke naamruimte sy eie tabelle besit in plaas van een te deel, wat die ekstra opstelling werd is wanneer albei tonnele weke lank op moet bly.

Per toepassing, en ketting as 'n aparte probleem

Soms moet net een program die tweede tonnel gebruik. Op Linux bereik beleidsroetering per gebruiker, cgroup of poort daardie resultaat, en 'n enkele bestemming kan aan 'n koppelvlak vasgepen word sonder om die verstek hoegenaamd te raak. 'n Toepassing wat sy sok aan een koppelvlak vaspen, raadpleeg glad nie die roetetabel nie, so 'n laai kan die fisiese adapter bly gebruik totdat 'n adres binne sy eie instellings gekies word.

Ketting is 'n ander bewerking as om twee tonnele langs mekaar te laat loop. Om A oor B te ketting beteken die binneste bediener se adres moet van binne die buitenste tonnel bereikbaar wees. Die buitenste kliënt moenie die binneste kliënt se geënkripteerde pakkette vir 'n lek aansien nie. Een kliënt binne 'n virtuele masjien is die bot maar betroubare weergawe; albei op een gasheer vereis die roetewerk hierbo plus 'n buitenste pad na die binneste bediener wat nooit die binneste tonnel binnegaan nie.

Skryf die verstekeienaar neer, die voorvoegsellys wat elke tonnel dra, en die DNS-pad. Daardie drie feite verander die volgende voorval in 'n opsoek eerder as 'n ondersoek.