Wêrom brekt in twadde VPN-tunnel de earste?

It ynstallearjen fan in twadde VPN-klant om ien klantnetwurk te berikken is de gewoane manier hoe't dit begjint, en de earste tunnel wurdt tsjuster wylst beide klanten sukses rapportearje. Elke klant ynstallearre in standertrûte, de twadde wie spesifiker, en de kernel folget dy no foar alles behalve de eigen bûtenferbining fan 'e earste tunnel. Neat stoarte yn en gjin profyl is ferkeard. Ien rûte ferfong in oare, en de oplossing is om te besluten hokker tunnel de standert moat besitte.

It symptoom: de twadde klant wint stil

OpenVPN: de opsje redirect-gateway def1 oerskriuwt 0.0.0.0/0 net. Hy foeget 0.0.0.0/1 en 128.0.0.0/1 ta: tegearre dekke se elk IPv4-adres, en elk foarheaksel ferslacht in gewoane standert op lingte. De oarspronklike standert bliuwt yn 'e tabel en wurdt net mear brûkt foar gewoan ferkear, en in hostrûte nei de VPN-tsjinner hâldt de tunnel derfan ôf syn eigen bûtenpakketten te fangen. Beide klanten dogge dit, en de twadde ynstallearret gewoan syn pear letter.

Dêrom liket de earste tunnel dea ynstee fan loskeppele. Syn ynterface is omheech, syn kontrôlekanaal libbet, en gjin applikaasjeforkear berikt him mear. De omkearde klacht hat deselde ûntbrekkende push: in tillefoan dy't ferbynt mar neat stjoert, praat meastentiids mei in tsjinner dy't nea redirect-gateway oankundige hat, dus it apparaat hâldt syn eigen standert en berikt allinnich de pool.

Meitsje in rûte-ôfbylding foar en nei't de twadde klant ferbynt. De twa heale rûtes dy't yn 'e tabel ferskine binne de hiele feroaring, en se ferklearje beide klachten. Neat oars yn 'e tabel hoecht te bewegen om it symptoom te toanen. Dêrom bringt it fuortheljen fan 'e twadde klant de earste daliks werom.

Lês hokker tunnel echt wint

Blied it winnende net ôf út 'e folchoarder wêryn't de klanten begûnen of út it byldsje yn 'e taakbalke. Freegje de kernel hokker rûte hy brûke soe foar in bestimming bûten beide privee netwurken, en lês de ynterface dy't weromkomt.

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

De earste twa binne it Linux-antwurd en de lêste twa it Windows-ekwivalint. Fier se út wylst beide tunnels omheech binne, ferbrek dan ien en fier se wer út. It ferskil tusken de twa útfier is it feit dat jo nedich hawwe foardat jo in oplossing kieze, en it kostet minder tiid as it lêzen fan it logboek fan ien fan beide klanten.

Skriuw it resultaat op, ynklusyf de ynterfacenamme en it foarheaksel dat oerienkaam. In ticket dat seit dat de twadde VPN de earste brutsen hat, is in beskriuwing fan it symptoom, gjin rûtestelling dêr't immen op hanje kin. It sykjen makket der in feit fan dat de folgjende yngenieur mei ien opdracht reprodusearje kin.

Windows: foarkom dat ien profyl de standert besit

Windows bewarret opsleine profylen, en de ynboude klant lit ien fan in oare ôfhingje sadat de earste automatysk omheech komt as de twadde ferbynt. It profyl dat it lêst ferbûn is, hâldt meastentiids de standert, dus de praktyske eigner is de lêste ferbining ynstee fan de earste. Jou elk profyl syn eigen push-rûtes en skeakel split tunneling oan foar dyjinge dy't de standert net besitte moat.

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

Split tunneling feroaret dat: allinnich foarheaksels dy't de tsjinner pusht, lânje yn 'e tabel, wat de standert by de earste tunnel lit. It ûntwerp mislearret noch altyd as beide tsjinners in standertrûte pushe, want dan wint de lêste ferbining en gjin ynstelling oan klantkant feroaret dat. Reparearje de push oan tsjinnerkant of akseptearje ien eigner.

App-lansearre profylen binne in oare funksje en wurdich om te kennen: in Windows-profyl kin starte as in neamd útfierber bestân begjint, wêrby't ferkearsfilters beslute wat it draacht. Dat is in profylynstelling en gjin firewallregel, en it lost in oar probleem op as it konflikt fan 'e standertrûte.

Linux: hâld de twadde tunnel bûten de haadtabel

Twa openvpn --config-eksimplaren op ien masine draaie set beide klanten yn deselde tabel, en trije opsjes skiede se mei tanimmende isolaasje. De lichtste is om de twadde klant de tabel hielendal net bewurkje te litten, mei route-nopull en eksplisite rûtes, of in route-up-skript dat allinnich ynstallearret wat jo bedoele. Dan draacht de twadde tunnel krekt de foarheaksels dy't jo neame en neat oars. Dan beslute jo hokker foarheaksels wêr hinne geane ynstee fan it efterôf te ûntdekken.

Beliedsrûtering is de middenopsje. In regel kiest in aparte tabel foar ien boarneadres of firewallmarke, en dy tabel draacht de rûtes fan 'e twadde tunnel. Reverse-path-filtern is hjir de fal, want in antwurd dat op in oar ynterface oankomt as dat de tabel kieze soe, wurdt weilitten, dus kontrolearje de ynstelling rp_filter foardat jo konkludearje dat de tunnel brutsen is.

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

Netwurknammeromten binne de swierste opsje en de skjinste. Start de twadde klant binnen ip netns, jou him in veth-pear en gean dy nammeromte yn om him te brûken. Ynterferinsje ferdwynt om't elke nammeromte syn eigen tabellen hat ynstee fan ien te dielen, wat de ekstra opset wurdich is as beide tunnels wiken omheech bliuwe moatte.

Per applikaasje, en keatening as in apart probleem

Soms moat allinnich ien programma de twadde tunnel brûke. Op Linux berikt beliedsrûtering op brûker, cgroup of poarte dat resultaat, en ien bestimming kin oan in ynterface fêstmakke wurde sûnder de standert hielendal oan te reitsjen. In applikaasje dy't syn socket oan ien ynterface fêstmakket, rieplachtet de rûtetabel hielendal net, dus in lansearder kin trochgean mei de fysike adapter te brûken oant in adres yn syn eigen ynstellingen keazen wurdt.

Keatening is in oare operaasje as twa tunnels njonken inoar draaie. A oer B keatening betsjut dat it adres fan 'e binnenste tsjinner berikber wêze moat fan binnen de bûtenste tunnel. De bûtenste klant mei ek net de fersifere pakketten fan 'e binnenste klant foar in lek oansjen. Ien klant binnen in firtuele masine is de grove mar betroubere ferzje; beide op ien host freget it rûtewurk hjirboppe plus in bûtenpaad nei de binnenste tsjinner dat nea de binnenste tunnel yn giet.

Skriuw de eigner fan 'e standert op, de foarheakselflist dy't elke tunnel draacht, en it DNS-paad. Dy trije feiten meitsje it folgjende ynsidint in sykjen ynstee fan in ûndersyk.