Публічний префікс через OpenVPN: виправити зворотний шлях

Спостерігайте, як тунель піднімається і клієнт пінгує протилежний бік, а потім публічна адреса, що належить за VPN, відповідає з іншого місця або не відповідає взагалі. Цей симптом зазвичай не має нічого спільного з шифром чи сертифікатами. Префікс, маршрутизований провайдером, доставляється як IP-маршрут, і перенести його через OpenVPN означає відтворити цей маршрут на двох рівнях і зберегти адресу джерела на зворотному шляху. Робити міст на WAN не потрібно, і додавання адреси на інтерфейс не створює вищого маршруту.

Префікс спочатку має бути маршрутизований до вас

Запитайте провайдера, як доставляється блок. Префікс, маршрутизований на основну адресу вашого сервера, — це не те саме, що адреси, які провайдер очікує побачити безпосередньо в сегменті WAN. З описаною тут схемою працює лише перша модель.

Якщо провайдер маршрутизує 198.51.100.64/28 на ваш вхідний сервер, пакети цього діапазону надходять на сервер і зупиняються там, якщо ви їх не пересилаєте. Якщо ж провайдер робить міст діапазону на ваш uplink, сервер має відповідати на ARP за нього, а це інша проблема.

Перевірте модель доставки, перш ніж торкатися OpenVPN: ззовні пінгніть адресу з блоку і подивіться, який інтерфейс її приймає. Якщо нічого не надходить, жодна конфігурація тунелю не допоможе. Якщо адреса відповідає безпосередньо на WAN, провайдер робить міст, а не маршрутизує, і схема нижче не застосовується.

Два рівні маршрутизації: маршрут ядра і iroute

OpenVPN потрібен префікс у двох місцях. Ядро має знати, що префікс належить тунельному пристрою, щоб пакети, які пересилаються, потрапляли в OpenVPN, а не в маршрут за замовчуванням. OpenVPN також має знати, який автентифікований клієнт володіє префіксом, і це запис iroute у каталозі, специфічному для клієнта.

Маршрут на боці сервера виглядає так, причому префікс і маска мають відповідати виділенню:

ip route add 198.51.100.64/28 dev tun0

Конфігурація, специфічна для клієнта, призначає володіння. Помістіть її у файл CCD, названий за загальним ім'ям сертифіката клієнта, і переконайтеся, що саме цей каталог сервер справді читає:

iroute 198.51.100.64 255.255.255.240

Документація OpenVPN про маршрутизовані мережі описує обидва рівні та чому вони розділені. Маршрут ядра без iroute надсилає пакети в тунель без власника, і OpenVPN їх відкидає. iroute без маршруту ядра залишає пакети на шляху за замовчуванням сервера. Обидві помилки з боку клієнта виглядають як зламаний тунель.

Де живе адреса служби

Делегований префікс — це не те саме, що власні адреси тунелю. За бажанням пронумеруйте лінк із приватного простору і розмістіть публічну адресу служби там, де служба справді працює.

На Linux-клієнті, який завершує службу локально, достатньо однієї адреси хоста:

ip address add 198.51.100.70/32 dev lo

Якщо префікс маршрутизується далі на хост VM або іншу LAN, налаштуйте натомість цей низхідний шлях і його зворотний маршрут. Призначати кожну адресу блоку VPN-клієнту не потрібно, і це створює конфлікти згодом.

Збережіть публічне джерело на зворотному шляху

Відповідь із делегованого префікса має вийти через тунель і досягти маршруту провайдера. Якщо віддалений хост надсилає її через свого ISP, адреса джерела виглядає підробленою, і провайдер або призначення її відкидають. Рішення — правило на основі джерела або окрема таблиця маршрутизації, а не ширший NAT. Без нього служба працює від партнера тунелю і не працює звідусіль інде.

На вхідному сервері широке правило masquerade — звичайний винуватець. Воно переписує публічне джерело на основну адресу сервера, і клієнт ніколи не бачить справжню:

iptables -t nat -S POSTROUTING

Обмежте NAT тими приватними VPN-клієнтами, яким він потрібен, і залиште делегований префікс неперекладеним. Потім переконайтеся, що сервер взагалі пересилає префікс, бо ланцюг пересилання із забороною за замовчуванням тихо його відкидає.

Перевірте обидва напрямки, перш ніж довіряти

Перевірка — це чотири спостереження, а не одне. Переконайтеся, що маршрут провайдера надходить, ядро надсилає префікс у тунель, OpenVPN прив'язує його до потрібного клієнта, а відповідь повертається з недоторканим публічним джерелом. Кожне спостереження має свою команду, тому збій вказує на рівень, а не на всю схему. Виконуйте їх у цьому порядку після кожної зміни конфігурації.

Запитайте ядро, який шлях обирає делегована адреса, і спостерігайте за тунелем, поки виконується запит:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Фільтрація зворотного шляху може скасувати правильний маршрут. Перевірте чинне налаштування на тунелі та на uplink і пам'ятайте, що суворий режим відхиляє трафік, джерело якого не збігається з інтерфейсом, через який він надійшов:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Нарешті, перевірте випадок збою. Зупиніть тунель і переконайтеся, що публічний префікс не витікає через звичайний uplink. Відновлення VPN має повернути службу, не розширюючи набір портів, які відкриває хост.