Miks teine VPN-tunnel esimese katki teeb?

Teise VPN-kliendi paigaldamine ühe kliendivõrgu kättesaamiseks on tavaline viis, kuidas see algab, ja esimene tunnel kustub, samal ajal kui mõlemad kliendid teatavad edust. Iga klient paigaldas vaikimisi marsruudi, teine oli täpsem, ja tuum järgib seda nüüd kõige jaoks peale esimese tunneli enda välisühenduse. Miski ei kukkunud kokku ja ükski profiil pole vale. Üks marsruut asendas teise, ja lahendus on otsustada, milline tunnel peaks vaikimisi marsruuti omama.

Sümptom: teine klient võidab vaikselt

OpenVPN: valik redirect-gateway def1 ei kirjuta 0.0.0.0/0 üle. See lisab 0.0.0.0/1 ja 128.0.0.0/1: koos katavad need iga IPv4-aadressi, ja iga prefiks võidab pikkuselt tavalist vaikimisi marsruuti. Algne vaikimisi marsruut jääb tabelisse ja seda ei kasutata enam tavalise liikluse jaoks, ning host-marsruut VPN-serverini hoiab tunnelit omaenda välispakette püüdmast. Mõlemad kliendid teevad seda, ja teine paigaldab lihtsalt oma paari hiljem.

Seetõttu näeb esimene tunnel välja surnud, mitte katkenud. Selle liides on üleval, juhtkanal elab, ja ükski rakenduse liiklus ei jõua sinna enam. Vastupidine kaebus on sama puuduva pushi tulemus: telefon, mis ühendub, aga ei saada midagi, räägib tavaliselt serveriga, mis ei teavitanud kunagi redirect-gateway valikut, nii et seade hoiab oma vaikimisi marsruuti ja jõuab ainult basseini.

Tee marsruudipilt enne ja pärast teise kliendi ühendumist. Kaks poolmarsruuti, mis tabelisse ilmuvad, on kogu muutus, ja need selgitavad mõlemat kaebust. Midagi muud tabelis ei pea sümptomi ilmumiseks liikuma. Seetõttu taastab teise kliendi eemaldamine esimese hetkega.

Loe, milline tunnel tegelikult võidab

Ära tuleta võitjat klientide käivitamise järjekorrast ega süsteemisalve ikoonist. Küsi tuumalt, millist marsruuti see kasutaks sihtkoha jaoks väljaspool mõlemat privaatvõrku, ja loe tagastatud liides.

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

Kaks esimest on Linuxi vastus ja kaks viimast Windowsi vaste. Käivita need, kui mõlemad tunnelid on üleval, seejärel lahuta üks ja käivita uuesti. Kahe väljundi erinevus on fakt, mida vajad enne lahenduse valimist, ja see võtab vähem aega kui ühegi kliendi logi lugemine.

Kirjuta tulemus üles, sealhulgas liidese nimi ja sobiv prefiks. Pilet, mis ütleb, et teine VPN rikkus esimese, on sümptomi kirjeldus, mitte marsruudiväide, mille alusel keegi saaks tegutseda. Otsing muudab selle faktiks, mida järgmine insener saab ühe käsuga korrata.

Windows: keela ühel profiilil vaikimisi marsruuti omada

Windows hoiab salvestatud profiile ja sisseehitatud klient lubab ühel teisest sõltuda, nii et esimene tõuseb automaatselt, kui teine helistab. Viimati ühendatud profiil kipub vaikimisi marsruuti hoidma, seega on praktiline omanik viimane helistamine, mitte esimene. Anna igale profiilile oma push-marsruudid ja lülita split tunneling sisse sellel, mis ei peaks vaikimisi marsruuti omama.

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

Split tunneling muudab seda: tabelisse jõuavad ainult serveri poolt pushitud prefiksid, mis jätab vaikimisi marsruudi esimesele tunnelile. Disain ebaõnnestub endiselt, kui mõlemad serverid pushivad vaikimisi marsruudi, sest siis võidab viimane ühendus ja ükski kliendipoolne säte ei muuda seda. Paranda push serveri poolel või lepi ühe omanikuga.

Rakendusega käivitatavad profiilid on teine funktsioon ja tasub teada: Windowsi profiil võib käivituda, kui käivitub nimetatud käivitatav fail, kusjuures liiklusfiltrid otsustavad, mida see kannab. See on profiili säte, mitte tulemüüri reegel, ja see lahendab teistsuguse probleemi kui vaikimisi marsruudi konflikt.

Linux: hoia teine tunnel peamisest tabelist väljas

Kahe openvpn --config eksemplari käivitamine ühes masinas paneb mõlemad kliendid samasse tabelisse, ja kolm valikut eraldavad neid kasvava isolatsiooniga. Kõige kergem on takistada teisel kliendil tabelit üldse muuta, kasutades route-nopull koos selgete marsruutidega või route-up-skripti, mis paigaldab ainult selle, mida kavatsed. Siis kannab teine tunnel täpselt neid prefikse, mida nimetad, ja mitte midagi muud. Siis otsustad sina, millised prefiksid kuhu lähevad, selle asemel et seda hiljem avastada.

Poliitikapõhine marsruutimine on keskmine valik. Reegel valib ühe lähteaadressi või tulemüürimärgi jaoks eraldi tabeli, ja see tabel kannab teise tunneli marsruute. Vastupidise tee filtreerimine on siin lõks, sest vastus, mis saabub teisele liidesele kui tabel valinuks, visatakse ära, seega kontrolli sätet rp_filter enne, kui järeldad, et tunnel on katki.

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

Võrgupimeruumid on kõige raskem ja puhtaim valik. Käivita teine klient ip netns sees, anna sellele veth-paar ja sisene sellesse nimeruumi, et seda kasutada. Häired kaovad, sest igal nimeruumil on oma tabelid ühise jagamise asemel, mis on lisaseadistuse väärt, kui mõlemad tunnelid peavad nädalaid üleval püsima.

Rakenduse kaupa ja aheldamine eraldi probleemina

Mõnikord peaks teist tunnelit kasutama ainult üks programm. Linuxis saavutab selle poliitikapõhine marsruutimine kasutaja, cgroupi või pordi järgi, ja ühe sihtkoha saab liidese külge kinnitada ilma vaikimisi marsruuti üldse puutumata. Rakendus, mis kinnitab oma sokli ühe liidese külge, ei konsulteeri marsruuditabeliga üldse, seega käivitaja saab jätkata füüsilise adapteri kasutamist, kuni selle enda sätetes valitakse aadress.

Aheldamine on teine toiming kui kahe tunneli kõrvuti käitamine. A aheldamine üle B tähendab, et sisemise serveri aadress peab olema välise tunneli seest kättesaadav. Väline klient ei tohi ka sisemise kliendi krüpteeritud pakette lekkuseks pidada. Üks klient virtuaalmasinas on toores, kuid usaldusväärne versioon; mõlemad ühes hostis nõuavad ülaltoodud marsruuditööd pluss välist teed sisemise serveri poole, mis ei sisene kunagi sisemisse tunnelisse.

Kirjuta üles vaikimisi marsruudi omanik, iga tunneli kantavate prefiksite loend ja DNS-tee. Need kolm fakti muudavad järgmise juhtumi otsinguks, mitte uurimiseks.