Два тунэлі 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

Прачытайце існуючыя правілы, перш чым дадаць яшчэ адно. Дублікаты прыярытэтаў і забытыя табліцы — звычайная прычына таго, што палітыка метак выглядае зусім без эфекту.

Дакажыце ізаляцыю, спыніўшы адно злучэнне

Калі абодва тунэлі ўзнятыя, запішыце адрас кожнага інтэрфейса, маршрут да аднаго хоста за кожным тунэлем і шлях, якім ідзе непаўязаны пункт прызначэння. Запытайце пошук у ядра, а не чытайце адну табліцу, бо адна табліца ніколі не паказвае канчатковае рашэнне.

Потым спыніце адзін экзэмпляр і паглядзіце, як яго інтэрфейс і маршруты знікаюць, пакуль другі працуе далей. Разрыў у тым, што выжыў, азначае, што яны ўсё яшчэ дзеляць імя прылады, маршрут або правіла міжсеткавага экрана, якое ніхто не раздзяліў.

Вярніце спынены профіль і паўтарыце тыя ж праверкі. Калі тунэль выжывае толькі першы запуск пасля перазагрузкі, вы глядзіце на дэфект жыццёвага цыкла, а не на дызайн маршрутызацыі.