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

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

Започнете от работата, която втората връзка трябва да свърши

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

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

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

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

Припокриващите се пулове се чупят преди маршрутизацията

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

Погледнете и локалната LAN. Домашна LAN с номер 192.168.1.0/24, която един тунел също излага, създава същата двусмисленост, а симптомът е име на хост, което се разрешава, докато връзката така и не завършва. Това изглежда като повреда в разрешаването на имена, докато не отпечатате маршрутите.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Сравнете двата изхода с двете сървърни конфигурации, преди да пипате клиента. Ако префиксите се припокриват, спрете и преномерирайте, защото никакво рестартиране няма да ги раздели.

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

Всеки профил получава собствено име на инстанция и собствен конфигурационен файл, така че инстанцията office зарежда office.conf, а тази с име lab зарежда lab.conf. Потвърдете това съответствие през мениджъра на услуги, вместо да вярвате на списък на директория, защото drop-in може да промени кой файл се зарежда. Грешното съответствие означава, че настройвате профила, който не работи.

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

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

Маркерите задържат отговорите на интерфейса, от който са дошли

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

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

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

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

Докажете изолацията, като спрете една връзка

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

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

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