Едно Pi, два екземпляра OpenVPN: какво чете всеки модул

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

Всяко име на екземпляр избира своя файл

В модулните файлове, доставени с OpenVPN 2.6, стартовите аргументи носят заместител за екземпляра, който се попълва от текста след знака @. Шаблонът за сървър работи от сървърната конфигурационна директория и съпоставя аргумента си с %i.conf там, докато шаблонът за клиент прави същото от клиентската директория. Така [email protected] чете admits.conf в сървърната директория, а [email protected] чете uplink.conf в клиентската директория и нито едно от имената няма значение в другата директория.

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

systemctl cat [email protected]
systemctl cat [email protected]

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

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

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

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

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

Импортиран маршрут може да погълне отговорите към вашите потребители

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

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

Попитайте ядрото за пътя, който отговорът всъщност ще поеме, преди да напишете каквото и да е правило. Адресите по-долу са заместители за адрес на подложката на Pi и публичния адрес на един roaming потребител.

ip rule show
ip route get 198.51.100.7 from 192.0.2.10

Проверете разделението, после спирайте ролите една по една

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

След това спрете клиентската роля и наблюдавайте какво запазва сървърната роля. Това е най-евтиният начин да намерите правило за маршрут или маркировка, което е било предназначено за един екземпляр и е приложено към двата.

systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pager

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