Pse tuneli i dytë VPN thyen të parin?

Instalimi i një klienti të dytë VPN për të arritur një rrjet klienti është mënyra e zakonshme si fillon kjo, dhe tuneli i parë errësohet ndërsa të dy klientët raportojnë sukses. Secili klient instaloi një rrugë të paracaktuar, e dyta ishte më specifike, dhe kerneli tani e ndjek atë për gjithçka përveç lidhjes së vetë jashtme të tunelit të parë. Asgjë nuk u rrëzua dhe asnjë profil nuk është i gabuar. Një rrugë zëvendësoi një tjetër, dhe zgjidhja është të vendosësh cili tunel duhet të zotërojë rrugën e paracaktuar.

Simptoma: klienti i dytë fiton në heshtje

OpenVPN: opsioni redirect-gateway def1 nuk mbishkruan 0.0.0.0/0. Ai shton 0.0.0.0/1 dhe 128.0.0.0/1: së bashku mbulojnë çdo adresë IPv4, dhe çdo prefiks mund një rrugë të paracaktuar të thjeshtë në gjatësi. Rruga e paracaktuar origjinale mbetet në tabelë dhe nuk përdoret më për trafikun e zakonshëm, dhe një rrugë hosti drejt serverit VPN e mban tunelin nga kapja e paketave të tij të jashtme. Të dy klientët e bëjnë këtë, dhe i dyti thjesht instalon çiftin e tij më vonë.

Për këtë tuneli i parë duket i vdekur, jo i shkëputur. Ndërfaqja e tij është lart, kanali i kontrollit është i gjallë, dhe asnjë trafik aplikacioni nuk arrin më tek ai. Ankesa e kundërt ka të njëjtin push që mungon: një telefon që lidhet por nuk dërgon asgjë zakonisht flet me një server që nuk njoftoi kurrë redirect-gateway, kështu që pajisja mban rrugën e saj të paracaktuar dhe arrin vetëm pishinën.

Bëni një fotografi të rrugëve përpara dhe pasi klienti i dytë lidhet. Dy gjysmë-rrugët që shfaqen në tabelë janë i gjithë ndryshimi, dhe shpjegojnë të dyja ankesat. Asgjë tjetër në tabelë nuk duhet të lëvizë që simptoma të shfaqet. Prandaj heqja e klientit të dytë rikthen të parin menjëherë.

Lexoni cili tunel fiton vërtet

Mos e nxirrni fituesin nga rendi i nisjes së klientëve ose nga ikona në tabaka. Pyetni kernelin cilën rrugë do të përdorte për një destinacion jashtë të dy rrjeteve private, dhe lexoni ndërfaqen që kthehet.

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

Dy të parat janë përgjigja e Linux dhe dy të fundit ekuivalenti i Windows. Ekzekutoni ato ndërsa të dy tunelët janë lart, pastaj shkëputni një dhe ekzekutoni përsëri. Diferenca midis dy daljeve është fakti që ju nevojitet përpara se të zgjidhni një zgjidhje, dhe kërkon më pak kohë sesa leximi i regjistrit të secilit klient.

Regjistroni rezultatin, duke përfshirë emrin e ndërfaqes dhe prefiksin që përputhej. Një biletë që thotë se VPN i dytë theu të parin është përshkrim i simptomës, jo një deklaratë rrugëtimi mbi të cilën dikush mund të veprojë. Kërkimi e kthen atë në një fakt që inxhinieri tjetër mund ta riprodhojë me një komandë.

Windows: parandaloni që një profil të zotërojë rrugën e paracaktuar

Windows ruan profile të ruajtura, dhe klienti i integruar lejon që njëri të varet nga tjetri, kështu që i pari ngrihet automatikisht kur i dyti lidhet. Profili i lidhur së fundmi tenton të mbajë rrugën e paracaktuar, kështu që zotëruesi praktik është lidhja e fundit dhe jo e para. Jepini çdo profili rrugët e veta push dhe aktivizoni split tunneling për atë që nuk duhet të zotërojë rrugën e paracaktuar.

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

Split tunneling e ndryshon këtë: vetëm prefikset e shtyra nga serveri hyjnë në tabelë, gjë që e lë rrugën e paracaktuar tek tuneli i parë. Dizajni dështon përsëri nëse të dy serverët shtyjnë një rrugë të paracaktuar, sepse atëherë fiton lidhja e fundit dhe asnjë cilësim në anën e klientit nuk e ndryshon atë. Rregulloni pushin në anën e serverit ose pranoni një zotërues.

Profilet e nisura nga aplikacioni janë funksion tjetër dhe ia vlen t'i njihni: një profil Windows mund të nisë kur nis një ekzekutues i emëruar, me filtra trafiku që vendosin çfarë mbart. Është cilësim profili dhe jo rregull firewall, dhe zgjidh një problem tjetër nga konflikti i rrugës së paracaktuar.

Linux: mbajeni tunelin e dytë jashtë tabelës kryesore

Ekzekutimi i dy instancave openvpn --config në një makinë i vendos të dy klientët në të njëjtën tabelë, dhe tre opsione i ndajnë me izolim në rritje. Më i lehti është të ndaloni plotësisht klientin e dytë të redaktojë tabelën: route-nopull me rrugë eksplicite, ose një skript route-up që instalon vetëm atë që synoni. Atëherë tuneli i dytë mbart saktësisht prefikset që emërtoni dhe asgjë tjetër. Atëherë ju vendosni cilat prefikse shkojnë ku, në vend që ta zbuloni më vonë.

Rrugëtimi me politika është opsioni i mesëm. Një rregull zgjedh një tabelë të veçantë për një adresë burimi ose një shenjë firewall, dhe ajo tabelë mbart rrugët e tunelit të dytë. Filtrimi i rrugës së kundërt është kurthi këtu, sepse një përgjigje që arrin në një ndërfaqe të ndryshme nga ajo që do të zgjidhte tabela hidhet poshtë, prandaj kontrolloni cilësimin rp_filter përpara se të konkludoni që tuneli është i prishur.

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

Hapësirat e emrave të rrjetit janë opsioni më i rëndë dhe më i pastër. Nisni klientin e dytë brenda ip netns, jepini një çift veth dhe hyni në atë hapësirë emrash për t'i përdorur. Ndërhyrja zhduket sepse çdo hapësirë emrash zotëron tabelat e veta në vend që të ndajë një, gjë që ia vlen konfigurimi shtesë kur të dy tunelët duhet të qëndrojnë lart për javë.

Për aplikacion dhe zinxhirimi si problem i veçantë

Ndonjëherë vetëm një program duhet të përdorë tunelin e dytë. Në Linux, rrugëtimi me politika sipas përdoruesit, cgroup ose portës arrin atë rezultat, dhe një destinacion i vetëm mund të fiksohet në një ndërfaqe pa prekur fare rrugën e paracaktuar. Një aplikacion që fikson socketin e tij në një ndërfaqe nuk konsulton fare tabelën e rrugëtimit, kështu që një lansues mund të vazhdojë të përdorë përshtatësin fizik derisa një adresë të zgjidhet në cilësimet e tij.

Zinxhirimi është operacion tjetër nga ekzekutimi i dy tunelëve krah për krah. Zinxhirimi i A mbi B do të thotë që adresa e serverit të brendshëm duhet të jetë e arritshme nga brenda tunelit të jashtëm. Klienti i jashtëm gjithashtu nuk duhet t'i marrë paketat e kriptuara të klientit të brendshëm si rrjedhje. Një klient brenda një makine virtuale është versioni i ashpër por i besueshëm; të dy në një host kërkojnë punën e rrugëtimit më sipër plus një rrugë të jashtme drejt serverit të brendshëm që nuk hyn kurrë në tunelin e brendshëm.

Shkruani zotëruesin e rrugës së paracaktuar, listën e prefikseve që mbart secili tunel dhe rrugën DNS. Këto tre fakte e kthejnë incidentin tjetër në kërkim në vend të hetimit.