Два шлюза, един VPN: защо OpenVPN избира грешния канал нагоре

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

Адресът на тунела не е крайната точка

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

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

Намерете адреса, към който клиентът действително се е свързал

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

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

Редът в журнала посочва адреса и порта на партньора в момента на свързване. Ако той не съвпада с профила, нещо пред клиента пренаписва дестинацията преди връзката да започне.

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

Закрепете крайната точка и прочетете реда на политиката

Маршрутът до хост е по-конкретен от всеки маршрут по подразбиране. Затова /32 за адреса на партньора печели в таблицата, която го съдържа. Обичайната форма посочва шлюза и устройството изрично:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

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

ip rule show
ip route get 203.0.113.40

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

Когато крайната точка се мести

Име на хост, което се разрешава до няколко адреса, обезсилва постоянен /32 веднага щом отговорът се промени. Профил с няколко реда remote има същия проблем, защото клиентът може да попадне на който и да е от тях. Обновявайте маршрута от собствените куки за жизнения цикъл на клиента, вместо да го добавяте ръчно. Скрипт up, който чете договорения партньор и инсталира маршрута до хост, поддържа изключението в съответствие с реалността, а съответстващ скрипт down го премахва.

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

Дръжте вътрешната политика отделно

Преместването на външния път не дава достъп до нова частна подмрежа и не променя кои дестинации сървърът избутва в тунела. Маршрутът на долния слой избира кабела; изтласканите маршрути избират какво влиза в тунела. Именно разделянето на тези две решения прави разделянето предвидимо.

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

Потвърдете резултата с две независими наблюдения: локалния адрес и устройството на сокета и маршрута, до който се разрешава частната дестинация. Когато и двете съвпадат с намерението ви, разделянето е реално. Ръководството на OpenVPN 2.6 покрива опциите за свързване remote и local, които решават към кой адрес се обръща клиентът.