Клієнт OpenVPN для всієї LAN на OpenWrt: робочий порядок

Володіння інтерфейсом, політика зони, masquerade і таблиці за SSID — це чотири окремі завдання. Виконайте їх по порядку, і тунель на весь роутер перестане з вами воювати.

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

Вирішіть, що ділить тунель

Роутер, який роздає Wi-Fi і DHCP, може запускати клієнт сам. Це ставить кожен під'єднаний пристрій за тунель без налаштування на кожному пристрої, і саме такий варіант потрібен більшості невеликих майданчиків. У нього ж найширша зона ураження, коли тунель падає, бо кожен пристрій втрачає шлях одночасно. На LAN не залишається робочого виходу назовні.

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

Так чи інакше, зробіть підмережі LAN різними. Однакові діапазони змушують одну сторону виглядати під'єднаною напряму, і чорна діра, що виникає з цього, читається як збій VPN годинами.

Дайте тунелю власника

Оголосіть тунель мережевим інтерфейсом з іменем, пристроєм і без власного протоколу. Тоді мережева система створює й обслуговує пристрій, і все далі посилається на інтерфейс за іменем, а не за пристроєм. Саме це дозволяє зоні знайти його.

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

Тримайте ім'я однаковим у конфігурації мережі, фаєрвола і VPN. Зона перелічує мережі за іменем, тому одна помилка в символі лишає тунель поза всіма зонами, поки сам інтерфейс виглядає здоровим. Здоровий інтерфейс без політики — найважчий для виявлення стан.

Помістіть його в зону, потім дозвольте пересилання в неї

Зона фаєрвола — це місце, де живе політика: вхід, вихід, пересилання і masquerade. Тунель поза зоною керується значеннями за замовчуванням, які ви не обирали, і це рідко те, що потрібно клієнту роутера. Блоки нижче оголошують інтерфейс, ставлять його в зону і дозволяють трафіку LAN входити до цієї зони.

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

У випусках старших за 21.02 той самий рядок інтерфейсу пишеться як option ifname, тому перевірте, яку форму розуміє встановлена прошивка, перш ніж вставляти. Блок пересилання — це дозвіл, який взагалі дає трафіку LAN користуватися тунелем. Без нього пристрій піднятий, клієнт підключений, і жоден вузол LAN не досягає тунелю. Це найпоширеніша скарга «підключено, але без інтернету» в клієнтів роутера.

Masquerade у зоні VPN згортає кожну адресу LAN в адресу тунелю роутера до того, як пакет вийде. Це знімає потребу у зворотному маршруті до вашої підмережі на дальньому боці.

Якщо дальній бік уже маршрутизує вашу LAN, вимкнення masquerade лишає адреси джерела видимими і робить журнали за клієнтами осмисленими. Виберіть один варіант і запишіть який, бо ці два вибори згодом дають різні питання до підтримки. Видалення пересилання LAN-to-WAN за замовчуванням — окреме рішення зі своїм наслідком. Приберіть його, і власний доступ роутера до інтернету піде разом з ним.

Назвіть справжній аплінк у NAT

У прошивці, де правило трансляції написане вручну, саме вихідний інтерфейс — це поле, яке ламається. Правило, яке називає vlan2 нічого не робить, коли сесія завершується на ppp0. Правило взагалі без інтерфейсу може транслювати трафік, який мав залишитися приватним. Жодна з помилок не оголошує про себе, бо тунель продовжує працювати.

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Замініть ppp0 у цьому правилі на інтерфейс із ip route або зі списку активних інтерфейсів, потім дивіться на лічильник, поки вузол LAN завантажує сторінку. На роутері з одним провайдером одного правила masquerade для аплінку зазвичай достатньо. Друге правило для інтерфейсу тунелю не замінює перше.

Потім додайте параметри клієнта, які вирішують, що входить у тунель. Директива redirect-gateway надсилає інтернет-трафік клієнта через VPN, а без неї тунель несе лише маршрути, які проштовхує сервер. Перевірте отриману таблицю маршрутів, перш ніж торкатися DNS.

Розділіть Wi-Fi другою таблицею

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

Пакети policy routing в OpenWrt виражають саме таку комбінацію. Можна й вручну, з правилом за джерелом і таблицею, чий маршрут за замовчуванням указує на пристрій тунелю.

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

Підозрюйте годинник і прапорець пристрою

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

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

Схожі статті