Два OpenVPN клиента на един Linux хост: кой притежава маршрута?

И двата профила съобщават, че са свързани, а единият тихо пренася трафик, предназначен за другия. Два клиента на един хост е поддържана подредба; два клиента без собственик за всеки префикс — не. Работата е по-малко за вдигане на втория тунел и повече за решаване кой процес може да претендира за кой маршрут. Мини в реда по-долу и конфигурацията следва от отговорите.

Започни с въпроса за какво е вторият тунел

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

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

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

Погледни пуловете преди маршрутите

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

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

Две семейства адреси означават два кръга от тази проверка. Пуловете IPv6 се сблъскват също толкова тихо, колкото и тези на IPv4.

Дай на всеки профил собственик

Една инстанция на профил, един конфигурационен файл на инстанция и едно име, което идентифицира двойката. При пакетиране в стил Debian името след знака @ избира файла, поради което два профила с едно и също име на инстанция никога не могат да работят заедно. Потвърди съответствието от инсталирания юнит, а не от урок.

systemctl cat [email protected]
ip -4 addr show

След това реши кой инсталира маршрутите — това е въпрос на политика, а не на синтаксис.

Когато двата сървъра изпратят несъвместими набори, или добави route-nopull и изброй само префиксите, които всеки профил изисква, или остави един да запази маршрута си по подразбиране и насочвай останалото с правило за политика. Два процеса, които и двата инсталират маршрут по подразбиране, завършват с един единствен победител и никой не може да каже защо. Щом двата тунела пренасят трафик за различни източници, отговор може да излезе през грешния, а моделът, който издържа, е маркировка на връзката, възстановена върху отговорите и насочена в собствената си таблица. Ограничи маркировките, така че собствените криптирани пакети на тунелите никога да не съвпадат с тях.

Провери всеки тунел, после спри един

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

ip rule show
ip route get 203.0.113.9

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

Запиши в бележките за внедряване кой профил притежава кой префикс, до диапазоните на пуловете. Двата тунела са умишлена подредба и следващият читател трябва да вижда границата, преди да пипа който и да е профил. Без тази бележка границата се преоткрива от този, който е на дежурство, когато споделеният префикс най-накрая се счупи.