Два 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 уреди во листата интерфејси докажуваат дека двата демони стартувале; тие не кажуваат ништо за тоа кој го користел одреден клиент. Второто извршување, со еден тунел помалку, е она што покажува дали вашето резервно правило го прави тоа што сте го намериле.