Два OpenVPN клијента на једном Linux гејтвеју: поделите политику

Два OpenVPN демона могу оба да пријаве успешан тунел док гејтвеј шаље сваког клијента кроз исти. Ништа у руковању не одлучује који тунел клијент користи; то одлучује језгро, пакет по пакет, пролазећи кроз правила политике и затим кроз табелу коју свако правило именује. Кад се тако гледа, конфигурација престаје да буде о OpenVPN опцијама и постаје матрица рутирања са два власника.

Језгро одлучује, не демон

Прослеђени пакет стиже на LAN интерфејс и код за рутирање оцењује листу правила по редоследу приоритета. Прво правило чији се бирач поклапа именује табелу, а руте те табеле бирају излазни уређај. Ако табела нема одговарајућу руту, претрага се наставља на следеће правило, и управо тај детаљ чини да недовршено подешавање закаже тихо, а не гласно.

Процес тунела нема реч у том проласку. Он ствара интерфејс и може да инсталира руте, али да ли пакет одређеног клијента улази у тај интерфејс зависи потпуно од табеле у коју је послат. Зато се два тунела са једнаким увезеним рутама такмиче, а последњи који пише побеђује за све. Зато подешавање може изгледати уравнотежено у конфигурационим датотекама, а ипак слати све клијенте кроз један демон.

Дајте свакој инстанци сопствени скуп ресурса

Почните од имена, јер поново употребљена имена су пут којим две инстанце случајно почну да деле стање. Доделите одвојене уређаје тунела, одвојене конфигурационе датотеке, одвојене акредитиве и одвојене сервисне јединице. Запишите спољну крајњу тачку и адресу тунела сваке инстанце у исту табелу као матрицу политике, да би каснија измена имала једно место где ће погледати.

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

dev tun-lab
route-nopull

route-nopull држи руте које сервер гура изван локалне табеле, и то је управо оно што желите када табеле политике треба да буду експлицитне. Да ли дати сервер гура и опцију redirect-gateway и да ли ваша верзија клијента подржава облик са филтером, вреди проверити у приручнику уместо претпостављати.

Напишите матрицу: извор, табела, уређај

За сваку групу клијената додајте правило које бира табелу по адреси извора, затим ставите жељени пут у ту табелу:

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

Табели су потребне одредишне руте које група треба да има, плус сви локални или управљачки изузеци који гејтвеј држе употребљивим. Табела која садржи само подразумевану руту је политика пуног тунела за ту групу, што може бити тачно исправно, али то треба да буде одлука, а не пропуст.

Сопствени транспорт тунела није у групи клијената

Шифровани пакети сваког демона настају на самом гејтвеју, упућени спољном партнеру. Правило које се поклапа само са префиксом извора клијента оставља те пакете на миру, зато су правила ограничена на извор безбеднија од правила која се поклапају са свим. Правило без бирача може да ухвати сопствени транспорт тунела и да га врати кроз тунел, и тада веза закаже на начин који изгледа као проблем провајдера.

Држите локалну управљачку сесију и пут доњег слоја експлицитно изван табела политике. Запишите те изузетке поред матрице; они су део дизајна, а не заобилазно решење које треба поново открити током инцидента.

Избор пута не даје дозволу

Дозвола за прослеђивање је друга одлука донета касније на путу. Правило ватрозида које прихвата пакете који излазе кроз други тунел не тера код за рутирање да га изабере, а исправна табела не даје дозволу за прослеђивање. Оба морају да постоје, а тест који доказује само једно завешће вас у погледу другог. Када једна група ради а друга не, проверите та два корака одвојено уместо да преписујете табеле.

Превођење извора је трећа одлука и треба да буде ограничено на изворну групу и уређај тунела који га заиста носи. Додајте посебан ланац за две инстанце уместо да празните ланац postrouting, јер неповезане услуге могу имати уносе тамо, а пражњење их тихо уклања.

Шта се дешава када један тунел падне

Одлучите понашање при отказу унапред. Када табела тунела изгуби своју руту, претрага пада на следеће правило и саобраћај групе се наставља кроз други тунел или обичан узлазни канал без икакве грешке. Ако то није прихватљиво, додајте завршно правило са нижим бројем приоритета које за тај извор враћа недоступан резултат, да губитак буде видљив уместо упијен.

Пошаљите нов захтев из сваке изворне групе и запишите четири чињенице: изабрану табелу, излазни уређај, преведени извор и да ли се одговор вратио истим путем. Затим спустите један тунел и поновите. Два TUN уређаја у листи интерфејса доказују да су оба демона покренута; она не кажу ништа о томе који је одређени клијент користио. Друго извршавање, са једним тунелом мање, је оно које показује да ли ваше резервно правило ради оно што сте намеравали.