OpenVPN сървър и клиент на един хост: защо клиентите отпадат

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

Една машина, две роли и два несъвместими отговора къде трябва да отиват отговорите.

Един пул, два сървъра: кой печели

Всеки екземпляр на сървър се нуждае от собствена подмрежа за тунела. Копирането на ред като server 10.8.0.0 255.255.255.0 във втората конфигурация дава на двата екземпляра един и същ префикс и резултатът е или отказ да стартира, или тихо състезание, в което клиентите на единия сървър получават адреси, които другият също смята за свои. Различните UDP портове и различните имена на устройства не помагат, защото нито едно от двете не докосва адресното пространство. Сменете втория пул и го сменете навсякъде, където маршрутите го споменават.

Избройте какво е живо преди да редактирате: ip -4 addr show изброява тунелните устройства, ss -lunp изброява слушателите, а systemctl list-units назовава юнитите. Един поглед към адресите на тунелите решава дали пуловете се сблъскват.

Какво добавя клиентският профил към таблицата

Клиентската половина записва маршрути веднага щом се свърже. redirect-gateway def1 разделя маршрута по подразбиране на 0.0.0.0/1 плюс 128.0.0.0/1, като и двата минават през новото устройство, заедно с маршрут до хоста на отдалечения сървър, който умишлено е закрепен към физическия интерфейс. Това закрепване съществува, за да запази тунелът път за собствения си транспорт. Всичко останало, включително отговорите, които локалният сървър дължи на собствените си клиенти, сега следва новия маршрут по подразбиране и излиза през отдалечената връзка.

Значи втората колизия не е счупен тунел. Това е работещ тунел на грешно място в таблицата.

Три начина да разделим ролите

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

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

Кой от двата екземпляра е виновен

Спрете клиентския екземпляр и тествайте отново първоначалните клиенти. Незабавното възстановяване означава маршрутизация, а не сървър. Върнете клиента и проследете един отговор с ip route get, на който са подадени и адрес на източника, и адрес на дестинацията, което показва пътя, който ядрото би избрало, след което наблюдавайте интерфейса, който пакетите наистина използват, с tcpdump -ni any port 1194. Файлът за състоянието на сървъра, който се записва на всеки няколко секунди чрез директивата status, носи списъка със свързани клиенти и байтови броячи за двете посоки.

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