Dy klientë OpenVPN në një gateway Linux: ndani politikën

Dy daemonë OpenVPN mund të raportojnë të dy një tunel të suksesshëm ndërsa gateway-i dërgon çdo klient përmes të njëjtit. Asgjë në dorështrëngim nuk vendos se cilin tunel përdor një klient; vendos kerneli, paketë pas pakete, duke kaluar rregullat e politikës dhe më pas tabelën që emërton çdo rregull. Kur e shikoni kështu, konfigurimi nuk është më për opsionet e OpenVPN dhe bëhet një matricë rrugëtimi me dy pronarë.

Vendos kerneli, jo daemoni

Një paketë e përcjellë arrin në ndërfaqen LAN dhe kodi i rrugëtimit vlerëson listën e rregullave sipas rendit të përparësisë. Rregulli i parë, përzgjedhësi i të cilit përputhet, emërton një tabelë, dhe rrugët e asaj tabele zgjedhin pajisjen e daljes. Nëse tabela nuk ka një rrugë përputhëse, kërkimi vazhdon te rregulli tjetër, dhe pikërisht ky detaj bën që një konfigurim gjysmë i përfunduar të dështojë në heshtje dhe jo me zhurmë.

Procesi i tunelit nuk ka zë në atë kalim. Ai krijon një ndërfaqe dhe mund të instalojë rrugë, por nëse paketa e një klienti të caktuar hyn në atë ndërfaqe varet plotësisht nga tabela ku u dërgua. Prandaj dy tunele me rrugë të importuara identike konkurrojnë, dhe shkruesi i fundit fiton për të gjithë. Prandaj një konfigurim mund të duket i balancuar në skedarë dhe gjithsesi t’i dërgojë të gjithë klientët përmes një daemoni të vetëm.

Jepini secilës instancë grupin e vet të burimeve

Filloni me emrat, sepse emrat e ripërdorur janë mënyra se si dy instancat përfundojnë duke ndarë gjendjen aksidentalisht. Caktoni pajisje tuneli të ndryshme, skedarë konfigurimi të ndryshëm, kredenciale të ndryshme dhe njësi shërbimi të ndryshme. Regjistroni pikën e jashtme të skajit dhe adresën e tunelit të secilës instancë në të njëjtën tabelë si matrica e politikës, që një ndryshim i mëvonshëm të ketë një vend ku të shohë.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull i mban rrugët që serveri shtyn jashtë tabelës lokale, dhe pikërisht këtë dëshironi kur tabelat e politikës duhet të jenë të qarta. Nëse një server i caktuar shtyn edhe opsionin redirect-gateway, dhe nëse versioni juaj i klientit mbështet formën me filtër, ia vlen ta kontrolloni në manual në vend që ta supozoni.

Shkruani matricën: burim, tabelë, pajisje

Për çdo grup klientësh, shtoni një rregull që zgjedh një tabelë sipas adresës së burimit, më pas vendosni rrugën e synuar në atë tabelë:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

Tabelës i duhen rrugët e destinacionit që grupi duhet të ketë, plus çdo përjashtim lokal ose administrues që e mban gateway-in të përdorshëm. Një tabelë që përmban vetëm një rrugë të parazgjedhur është politikë tuneli të plotë për atë grup, gjë që mund të jetë saktësisht e drejtë, por duhet të jetë një vendim dhe jo një lëshim.

Transporti i vetë tunelit nuk është në një grup klientësh

Paketat e kriptuara të çdo daemoni lindin në vetë gateway-in, të adresuara te partneri i jashtëm. Një rregull që përputhet vetëm me një prefiks burimi klienti i lë ato paketa në paqe, dhe prandaj rregullat e kufizuara nga burimi janë më të sigurta se rregullat që përputhen me gjithçka. Një rregull pa përzgjedhës mund të kapë transportin e vetë tunelit dhe ta kthejë përmes një tuneli, dhe atëherë lidhja dështon në një mënyrë që duket si problem i ofruesit.

Mbani sesionin lokal të administrimit dhe shtegun e shtresës së poshtme haptazi jashtë tabelave të politikës. Shkruani ato përjashtime pranë matricës; janë pjesë e dizajnit, jo një zgjidhje e përkohshme që duhet rizbuluar gjatë një incidenti.

Zgjedhja e një shtegu nuk e lejon atë

Leja për përcjellje është një vendim i dytë i marrë më vonë në rrugë. Një rregull muri zjarri që pranon paketat që dalin përmes tunelit të dytë nuk e bën kodin e rrugëtimit ta zgjedhë atë, dhe një tabelë e saktë nuk jep leje për të përcjellë. Të dyja duhet të ekzistojnë, dhe një test që provon vetëm njërën do t’ju mashtrojë për tjetrën. Kur një grup funksionon dhe tjetri jo, kontrolloni ato dy hapa veçmas në vend që të rishkruani tabelat.

Përkthimi i burimit është një vendim i tretë, dhe duhet të kufizohet në grupin e burimit dhe pajisjen e tunelit që vërtet e mban. Shtoni një zinxhir të dedikuar për dy instancat në vend që të zbrazni zinxhirin postrouting, sepse shërbime të palidhura mund të kenë zëra atje dhe zbrazja i heq ato në heshtje.

Çfarë ndodh kur bie një tunel

Vendosni sjelljen në dështim paraprakisht. Kur një tabelë tuneli humbet rrugën e saj, kërkimi bie te rregulli tjetër, dhe trafiku i grupit vazhdon përmes tunelit tjetër ose lidhjes së zakonshme të sipërme pa asnjë gabim. Nëse kjo nuk është e pranueshme, shtoni një rregull përfundimtar me një numër prioriteti më të ulët që kthen një rezultat të paarritshëm për atë burim, që humbja të jetë e dukshme në vend që të absorbohet.

Dërgoni një kërkesë të re nga çdo grup burimi dhe shënoni katër fakte: tabelën e zgjedhur, pajisjen e daljes, burimin e përkthyer dhe nëse përgjigja u kthye në të njëjtën rrugë. Më pas ulni një tunel dhe përsëritni. Dy pajisje TUN në një listë ndërfaqesh provojnë se të dy daemonët nisën; ato nuk thonë asgjë për atë që përdori një klient i caktuar. Ekzekutimi i dytë, me një tunel më pak, është ai që tregon nëse rregulli juaj rezervë bën atë që kishit ndërmend.