To VPN-klientar på éin skrivebordsmaskin: kva som kolliderer, og kva som verkar

Den andre klienten din koplar til, ressursane til den første sluttar å løysast opp, og saka seier at arbeids-VPN-en øydela den personlege. Ingenting er øydelagt i tydinga feil: begge klientane gjorde det dei er laga for, og maskina har berre éi rutetabell. Kollisjonen gjeld fire ressursar som kvar klient føreset at han eig. Gå gjennom dei i rekkjefølgje, og rettinga blir vanlegvis eit designval i staden for ein reparasjon.

Steg 1: finn ut kven klient som eig utgangen

Les den gjeldande utgangsavgjerda før du endrar noko. Ruteoppslaget for ein offentleg adresse fortel deg kva grensesnitt og kva neste hopp ein pakke ville brukt akkurat no, og det er svaret på kven som vann. Samanlikn det med grensesnittnamna klientane har oppretta, som vanlegvis ber produkt- eller protokollnamnet. Viss oppslaget peikar på tunnelen du ikkje venta, har du alt funne kollisjonen.

ip route get 1.1.1.1
ip route show default
route print

Nokre klientar erstattar ikkje standardruta i det heile; dei legg til to halvdelar, éin for den nedre halvdelen av adresserommet og éin for den øvre, som saman dekkjer alt. Det lèt den opphavlege standardruta vere synleg og får ein manuell reparasjon til å sjå rett ut medan trafikken framleis går ut gjennom tunnelen. Les metrikken og prefikslengda, ikkje berre om det finst ei standardoppføring.

Stopp viss begge klientane krev same prefiks med same metrikk. Kjernen vel éin, og den andre vil sjå tilkopla ut medan han ikkje ber noko.

Steg 2: kontroller resolveren og dei overlappande prefiksa

DNS er den andre kollisjonen, og han gir eit særeige symptom: namn feilar medan adresser verkar. Kvar klient skyv sin eigen resolver gjennom, og den siste som skriv vinn for spørjingane som følgjer. Spør resolvertjenesta kva ho brukar per lenkje i staden for å lese innstillingssida til klienten.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Samanlikn deretter dei private prefiksa dei to netverka brukar. Viss begge sider tildeler frå same område, vil inga klient-side ordning rette det, fordi maskina ikkje kan seie kva 10.0.0.0/8-destinasjon som høyrer til kva tunnel. Éi side må omnummererast eller omsetjast, og det er ein samtale med netverkseigarane i staden for ei konfigurasjonsendring. Overlapp er den einaste kollisjonen der det ærlege svaret er at designet må endrast.

Stopp her viss prefiksa overlappar. Alt seinare i denne sjekklista føreset at dei ikkje gjer det.

Steg 3: vel eit separasjonsmønster som held

Dei pålitelege mønstera unngår å køyre to klientar mot same rutetabell. Éin klient med ein split-tunnel-policy som når begge dei private netverka er det enklaste, føresett at destinasjonane ikkje overlappar og at eigaren av policyen er samd. Ein virtuell maskin eller eit netverksnamnerom er neste steg, fordi kvar får si eiga tabell og sin eigen resolver.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Eit namnerom gir same separasjon som ein virtuell maskin utan det andre operativsystemet, men det har skarpe kantar: tunnel-eininga må flyttast inn i det, og programmet må startast inni det. Ei eiga fysisk eining er ofte det minst overraskande valet for ein personleg VPN ved sida av ein administrert arbeidsklient. Å stable éin tunnel inni ein annan er ikkje eit separasjonsmønster; det indre endepunktet må halde fram med å vere tilgjengeleg gjennom den ytre tunnelen, og ordninga legg på MTU- og latenstidsproblem i tillegg.

Vel eitt mønster og skriv ned kvifor. Å blande eit namnerom for eitt program med ein split-tunnel for resten gjenopprettar den opphavlege kollisjonen i ein vanskelegare feilsøkbar form.

Steg 4: verifiser begge netverka frå same økt

Test éin ressurs på kvart privat netverk frå miljøet der programmet faktisk køyrer, ikkje frå skalet ditt viss appen køyrer inne i eit namnerom. Kontroller utgangsgrensesnittet, den oppløyste adressa og svarkoden saman, fordi ein suksess i éin av dei tre kan skjule ein feil i dei andre. Gjenta etter ein omstart, sidan rekkjefølgja klientane startar i avgjer kven som vinn. Nettopp den rekkjefølgja gløymer folk å notere.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Noter klientversjonane, grensesnittna, tilstanden til resolveren og prefiksa for kvart netverk. Når ein klient blir oppdatert og endrar ruteåtferda si, er den registreringa skilnaden mellom ei fem minutts retting og ei gjenoppbygging. Den neste personen deler ikkje minnet ditt om kven tunnel som kom opp først.

Sjekklista er komplett når du kan namngje grensesnittet som eig standardruta, resolveren kvart namn brukar, mønsteret som skil den andre tunnelen, og resultatet av éin førespurnad per netverk etter ein omstart. Alt mindre er ein konfigurasjon som tilfeldigvis verkar i dag.