Dalawang kliyente ng VPN sa isang desktop: ano ang bumabangga at ano ang gumagana

Kumokonekta ang pangalawang kliyente mo, tumitigil ang pag-resolve ng mga resource ng una, at sinasabi ng ticket na sinira ng work VPN ang personal. Walang nasira sa kahulugan ng depekto: ginawa ng dalawang kliyente ang para sa kanila, at may isang routing table lang ang makina. Ang banggaan ay tungkol sa apat na resource na inaakalang pag-aari ng bawat kliyente. Dumaan sa kanila nang sunod-sunod, at ang pag-aayos ay kadalasang nagiging desisyon sa disenyo kaysa pagkukumpuni.

Hakbang 1: alamin kung aling kliyente ang may-ari ng labasan

Basahin ang kasalukuyang desisyon sa labasan bago baguhin ang kahit ano. Sinasabi ng paghahanap ng ruta para sa pampublikong address kung aling interface at susunod na hop ang gagamitin ng packet ngayon, at iyon ang sagot kung sino ang nanalo. Ihambing ito sa mga pangalan ng interface na ginawa ng mga kliyente, na kadalasang may pangalan ng produkto o protocol. Kung itinuturo ng paghahanap ang tunnel na hindi mo inaasahan, nahahanap mo na ang banggaan.

ip route get 1.1.1.1
ip route show default
route print

May mga kliyenteng hindi talaga pinapalitan ang default na ruta; nagdaragdag sila ng dalawang kalahati, isa para sa ilalim na kalahati ng espasyo ng address at isa para sa itaas, na magkasamang sumasaklaw sa lahat. Iniiwan nito ang orihinal na default na ruta na nakikita at ginagawang parang tama ang manu-manong pagkukumpuni habang lumalabas pa rin ang trapiko sa tunnel. Basahin ang metric at haba ng prefix, hindi lang ang pagkakaroon ng default na entry.

Huminto kung parehong hinihingi ng dalawang kliyente ang parehong prefix na may parehong metric. Pipiliin ng kernel ang isa, at ang isa ay magmumukhang konektado habang wala namang dinadala.

Hakbang 2: suriin ang resolver at ang magkakapatong na prefix

Ang DNS ang pangalawang banggaan, at gumagawa ito ng kakaibang sintomas: nabigo ang mga pangalan habang gumagana ang mga address. Ipinipilit ng bawat kliyente ang sariling resolver, at ang huling sumulat ang nananalo para sa mga sumunod na query. Tanungin ang serbisyo ng resolver kung ano ang ginagamit nito sa bawat link sa halip na basahin ang pahina ng setting ng kliyente.

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

Pagkatapos ihambing ang mga pribadong prefix na ginagamit ng dalawang network. Kung parehong naglalaan ang dalawang panig mula sa parehong saklaw, walang kaayusan sa panig ng kliyente ang makakaayos nito, dahil hindi masasabi ng makina kung aling destinasyong 10.0.0.0/8 ang kabilang sa aling tunnel. Kailangang mabigyan ng bagong numero o maisalin ang isang panig, at iyon ay usapan sa mga may-ari ng network, hindi pagbabago ng configuration. Ang pagpapatong ang tanging banggaan kung saan ang tapat na sagot ay kailangang magbago ang disenyo.

Huminto dito kung nagpapatong ang mga prefix. Ipinapalagay ng lahat ng sumusunod sa listahang ito na hindi sila nagpapatong.

Hakbang 3: pumili ng pattern ng paghihiwalay na nananatili

Iniiwasan ng mga mapagkakatiwalaang pattern ang pagpapatakbo ng dalawang kliyente laban sa parehong routing table. Ang isang kliyente na may patakaran ng split tunnel na umaabot sa dalawang pribadong network ang pinakasimple, basta hindi nagpapatong ang mga destinasyon at pumapayag ang may-ari ng patakaran. Ang virtual machine o network namespace ang susunod na hakbang, dahil bawat isa ay nakakakuha ng sariling table at sariling 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/

Nagbibigay ang namespace ng parehong paghihiwalay tulad ng virtual machine nang walang pangalawang operating system, ngunit may magaspang na gilid: kailangang ilipat ang tunnel device sa loob nito, at kailangang simulan ang application sa loob. Ang hiwalay na pisikal na aparato ay kadalasang pinakamaliit na nakakagulat na opsyon para sa personal na VPN kasama ng pinamamahalaang work client. Ang pagsasalansan ng isang tunnel sa loob ng isa ay hindi pattern ng paghihiwalay; kailangang manatiling maabot ang panloob na endpoint sa pamamagitan ng panlabas na tunnel, at nagdaragdag pa ang kaayusang ito ng mga problema sa MTU at latency.

Pumili ng isang pattern at itala kung bakit. Ang paghahalo ng namespace para sa isang application at split tunnel para sa iba ay muling lumilikha ng orihinal na banggaan sa anyong mas mahirap i-debug.

Hakbang 4: i-verify ang dalawang network mula sa parehong session

Subukan ang isang resource sa bawat pribadong network mula sa kapaligiran kung saan talagang tumatakbo ang application, hindi mula sa shell mo kung tumatakbo ang app sa loob ng namespace. Suriin nang sabay ang labasang interface, na-resolve na address at response code, dahil ang tagumpay sa isa sa tatlo ay maaaring magtago ng kabiguan sa iba. Ulitin pagkatapos ng reboot, dahil ang pagkakasunod-sunod ng pagsisimula ng mga kliyente ang nagtatakda kung sino ang mananalo. Iyon ang bahaging nakakalimutang itala ng mga tao.

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

Itala ang mga bersyon ng kliyente, interface, estado ng resolver at prefix para sa bawat network. Kapag na-update ang isang kliyente at nagbago ang pag-uugali nito sa ruta, ang talaang iyon ang pagkakaiba ng limang minutong pag-aayos at muling pagbuo. Hindi ibabahagi ng susunod na tao ang alaala mo kung aling tunnel ang unang bumangon.

Kumpleto ang listahan kapag kayang pangalanan ang interface na may-ari ng default na ruta, ang resolver na ginagamit ng bawat pangalan, ang pattern na naghihiwalay sa pangalawang tunnel, at ang resulta ng isang kahilingan sa bawat network pagkatapos ng reboot. Ang anumang mas mababa ay configuration na nagkataong gumagana ngayon.