Един хъб OpenVPN, три LAN: план на адресите и iroute файлове

Три частни LAN могат да се срещнат в един хъб, без нито един обект да научава вътрешностите на другите, а цялата архитектура почива на четири кратки решения за конфигурация. Работи не заради екзотична протоколна функция, а заради план за адресите, който никой не трябва да гадае, плюс маршрути за всеки клиент, които казват на хъба кой клон притежава кой префикс. Сбъркайте едно от двете и тунелът пак се вдига, което точно прави отказа объркващ.

Минете стъпките по ред. Всяка зависи от плана от предишната стъпка и нито една не изисква нов сертификатен орган.

Започнете с план, който никой не трябва да гадае

Запишете четири непресичащи се префикса, преди да докоснете конфигурационен файл: собствената LAN на хъба, LAN на всеки клон и пулът, който се дава на роуминг клиентите. Непресичането държи всичко останало просто, защото припокриващите се диапазони превръщат маршрутизацията в главоблъсканица за най-дълго съвпадение, която никаква конфигурация за отделен клиент не поправя. След това потвърдете коя машина е шлюзът по подразбиране за всяка LAN, защото маршрутизатор на клон, който не е шлюз на своята LAN, изисква отдалечените маршрути да са инсталирани съвсем другаде. Накрая фиксирайте удостоверените имена, които идентифицират всеки клон, защото тези имена са ключовете, по които се търсят файловете за отделните клиенти.

Илюстративният план държи пула далеч от трите LAN. Вашият ще е различен и единственото твърдо правило е два диапазона да не се припокриват.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Кажете на ядрото на хъба къде са клоновете

Хъбът има нужда от две части информация за всеки клон: маршрут в ядрото, който изпраща префикса към устройството на тунела, и iroute запис, който казва на OpenVPN процеса кой клиент го притежава. Само маршрутът в ядрото доставя пакетите до тунела и спира дотам, защото демонът все още трябва да реши кой партньор да ги получи. Само iroute записът оставя тези пакети в ядрото без маршрут, по който да вървят. И двата реда принадлежат на конфигурацията, която демонът действително зарежда, а това си струва да се провери, преди да се отстранява каквото и да е друго.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Изключете клиент към клиент, когато ядрото трябва да е точката на налагане. Тази опция препраща трафика между партньорите вътре в демона, което е удобно и също означава, че правилата ви за препращане никога не виждат потока. Всичко по-долу предполага, че ядрото вижда всеки пакет между клоновете.

Дайте на всеки клон маршрутите, които му трябват

Всеки клон се нуждае от маршрути до другите клонове и до LAN на хъба, а не му трябва маршрут до собствената му свързана LAN. Изпращайте отдалечените префикси от хъба, вместо да ги поставяте във всеки маршрутизатор, така че четвърти обект по-късно да означава един нов файл за клиент вместо четири редакции. Файлът за отделен клиент също носи реда iroute, който държи собствеността и обявяването на едно място. Направете директорията и файловете ѝ четливи според модела на привилегии на сървъра, иначе търсенето се проваля без съобщение.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Четвърти обект следва същия модел: отделно удостоверено име, притежаван префикс, маршрут в ядрото на хъба, iroute запис и обявявания само към обектите, на които е разрешено да го достигат.

Тествайте в двете посоки, преди да го обявите за готово

Включете препращането на IPv4 на трите маршрутизатора, после потвърдете, че защитната стена разрешава предвидените потоци в двете посоки, защото еднопосочният тест минава със счупен обратен път по-често, отколкото някой очаква. Между обектите не е нужен превод на източника и именно запазването на оригиналния източник позволява на всеки клон да прилага собствената си политика към заявка.

Тествайте от хост в LAN на един клон към услуга в друг, после обърнете посоката, после тествайте от клон към LAN на хъба. Тези три резултата са различни доказателства и нито един от тях не предполага останалите. Ако маршрутизаторът на клон не е шлюзът по подразбиране на своята LAN, инсталирайте отдалечените префикси на истинския шлюз и добавете и пула, когато клиентите на тунела трябва да започват връзки към тази LAN.

Запишете плана, файловете за отделните клиенти и правилата на защитната стена като един документ, защото следващото добавяне на обект ще се оценява спрямо тях.

Архитектурата се държи, защото всеки слой има една задача: планът пази префиксите уникални, маршрутът в ядрото движи пакетите, iroute именува собственика, а защитната стена решава какво е разрешено. Когато нещо се счупи, този списък е и редът за проверката му.