Два 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

Прочитајте ги постојните правила пред да додадете уште едно. Двојните приоритети и заборавените табели се вообичаената причина зошто политиката со ознаки изгледа сосема без ефект.

Докажете изолација со запирање на една врска

Со двата тунели подигнати, запишете ја адресата на секој интерфејс, маршрутот до еден домаќин зад секој тунел и патот што го зема неповрзана дестинација. Побарајте го пребарувањето од јадрото наместо да читате една табела, бидејќи една табела никогаш не ја покажува конечната одлука.

Потоа запрете една инстанца и гледајте како нејзиниот интерфејс и маршрутите исчезнуваат додека другата продолжува. Прекин кај преживеаната значи дека двете уште делат име на уред, маршрут или правило на огнен ѕид што никој не го одвоил.

Вратете го запрениот профил и повторете ги истите проверки. Кога тунелот преживува само првото стартување по рестартирање, гледате дефект во животниот циклус, а не дизајн на рутирање.