Рукостискання OpenVPN на Synology не проходить? Перевірте переадресацію в LAN

Ноутбук повідомляє, що рукостискання TLS не вдалося, тож виникає спокуса перебудувати сертифікати. Спершу поставте нудніше питання: на якому саме порту Ethernet слухає Synology? У NAS із двома портами LAN дві адреси, і пакет VPN Server у DSM прив'язує свій слухач OpenVPN до однієї з них. Коли маршрутизатор переадресує 1194 на іншу адресу, жоден пакет не доходить до служби, і клієнтові немає з чим домовлятися.

Текст помилки вводить в оману, бо описує останнє, що спробував клієнт, а не перше, що зламалося. Двох хвилин порівняння сторінки пакета з правилом маршрутизатора достатньо, щоб розібратися.

Знайдіть адресу, до якої прив'язаний слухач

DSM називає свої порти LAN 1 і LAN 2, і кожен має окрему адресу та підмережу. Відкрийте VPN Server, прочитайте інтерфейс, указаний на вкладці OpenVPN, потім відкрийте Панель керування та запишіть адресу IPv4, яку DSM має на тому самому інтерфейсі. Саме ці два значення, а не ім'я вузла NAS, має назвати переадресація.

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

Подивіться на сам сокет через SSH, бо це єдине місце, яке показує, до чого демон насправді прив'язався, а не те, що має на увазі сторінка налаштувань.

sudo netstat -anp | grep 1194

Відредагуйте наявну переадресацію, а не додавайте нову

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

external 1194/udp  ->  192.0.2.20:1194/udp

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

Якщо адреса NAS видається через DHCP, зарезервуйте її до збереження правила. Закінчення оренди переназначає адресу, переадресація далі вказує на старе значення, і рукостискання починає збоїти того дня, коли NAS ніхто не торкався. Статичне налаштування на боці NAS вирішує ту саму проблему за умови, що адреса поза діапазоном DHCP маршрутизатора.

Доведіть, чи пакети взагалі доходять

Спершу запустіть захоплення на NAS, потім під'єднайтеся з клієнта і прочитайте адресу джерела у виводі. Захоплення, запущене після збою, нічого не показує і нічого не доводить.

sudo tcpdump -i any -n udp port 1194

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

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

Коли пакети приходять, перестаньте звинувачувати переадресацію

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

Транспорт — це інша невідповідність, яку варто перевірити явно, бо профіль і пакет редагуються в різних місцях. Зміна профілю з UDP на TCP без перемикання пакета залишає клієнта чекати слухача, якого немає, і клієнт повідомляє той самий загальний текст рукостискання, що й для всього іншого. Прочитайте рядок proto у файлі, потім подивіться на протокол, вибраний на сторінці сервера, і лише потім робіть висновок, що вони збігаються. Читання правил брандмауера DSM — третя перевірка: правило, яке дозволяє порт із локальної підмережі, але не з інтернету, легко залишити після тестування, і воно дає з'єднання, яке працює з кухні і збоїть усюди інде.

Перевірте шлях, який віддалений користувач справді проходить

Клієнт у тій самій локальній мережі може дістатися NAS, взагалі не торкаючись переадресації, тож це нічого не доводить про віддалений доступ. Скористайтеся телефоном із вимкненим Wi-Fi або попросіть когось поза мережею і стежте за лічильником маршрутизатора під час цієї спроби. Якщо віддалена спроба збоїть, а локальна вдається, переадресація або брандмауер усе ще в грі.

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