Два 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 устройства в списък на интерфейсите доказват, че и двата демона са стартирали; те не казват нищо за това кой от тях е използвал даден клиент. Второто пускане, с един изчезнал тунел, е това, което показва дали резервното ви правило прави това, което сте искали.