OpenVPN iroute срещу маршрут в ядрото: кое липсва?

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

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

Две решения, а не един маршрут

Представете си връзка между два обекта, при която 10.77.20.0/24 стои зад един клиент. Маршрутът в ядрото на сървъра, например ip route add 10.77.20.0/24 dev tun0, изпраща съответните пакети към устройството на тунела. След това OpenVPN се обръща към собствената си вътрешна таблица, изградена от записи iroute в директорията с конфигурация на клиента, за да реши коя връзка с партньор ще ги получи. Без маршрута в ядрото пакетът никога не стига до процеса, а без маршрута за партньора стига до процеса и не отива никъде.

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

Къде принадлежи iroute и какво казва

Записът отива във файл за отделен клиент, именуван по common_name на клиента, в client-config-dir, като iroute 10.77.20.0/24. Съвпадението на името на файла не е козметично: OpenVPN търси удостоверената идентичност и чете файла точно с това име, затова файл site-a действа само за клиент, чието общо име е site-a. Добавете ccd-exclusive, ако клиенти без такъв файл трябва да бъдат отказани напълно, което е правилната настройка, когато всеки клиент е шлюз на обект. Дръжте по един файл на шлюз и го именувайте по субекта на сертификата, който наистина издавате.

Тествайте записа от сървъра, преди да обвинявате далечната LAN. Файлът със състоянието изброява свързаните клиенти с общите им имена, а сървър, работещ с --verb 4, записва в журнала инсталирането на iroute при свързване на партньора. Ако при свързване не се появи нищо, файлът е в грешна директория или посочва грешна идентичност.

Клопката: файлът е налице, идентичността е грешна

Правилно изглеждащ iroute, прикачен към грешен партньор, губи повече време от липсващ файл, защото всичко на диска изглежда наред. Преименуване на сертификати, дублирани общи имена и username-as-common-name, който променя ефективната идентичност, всички го пораждат. Проверете коя идентичност е удостоверил сървърът, вместо която сте очаквали: изходът от състоянието е авторитетен, а името на файла е само ключ за търсене.

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

Завършете пътя отвъд партньора

Собствеността върху партньора е средата на пътя, не краят. Клиентът трябва да препраща пакети от тунела в своята LAN, което означава включено препращане на IP на този хост и правило на защитната стена, разрешаващо преминаването. Хостовете в далечната LAN се нуждаят от обратен път за адреса на тунела: или маршрут, сочещ обратно към шлюза, или съзнателно проектиран NAT от страната на клиента. Потвърдете настройката за препращане на клиента с sysctl net.ipv4.ip_forward, вместо да приемате стойност по подразбиране на дистрибуцията.

Ако други VPN клиенти трябва да достигат тази подмрежа, схемата отново расте: сървърът се нуждае от client-to-client, а тези клиенти трябва да маршрутизират префикса през тунела. Нищо от това не следва от собствената таблица за маршрутизиране на сървъра.

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