Мертвий слухач на DD-WRT зазвичай означає, що демон завершився під час розбору своєї конфігурації, а не що правило firewall заблокувало порт. OpenVPN 2.5 посилив кілька значень за замовчуванням, на які покладалися старі конфігурації, і створена конфігурація, що працювала на старій збірці, може бути відхилена ще до відкриття сокета. Причина в журналі самого роутера, а вхідні дані — у створеному файлі. Читати обидва в такому порядку швидше за будь-яке перехоплення пакетів.

Демон — не firewall

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

Розділіть їх двома перевірками, перш ніж щось змінювати, бо правка firewall на мертвому демоні лише додає другу змінну.

Прочитайте конфігурацію, яку створив DD-WRT

DD-WRT не передає OpenVPN текст, який ви ввели у веб-інтерфейсі. Він записує створену конфігурацію в /tmp/openvpn/openvpn.conf і запускає демон із цим файлом, тому поля інтерфейсу й будь-який текст у Additional Config об’єднуються ще до того, як OpenVPN їх побачить. Якщо ви налагоджуєте форму, а не створений файл, ви читаєте намір, а не фактичні вхідні дані. Скопіюйте цей файл у постійне місце, поки перезавантаження /tmp його не очистило.

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

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

Що OpenVPN 2.5 перестав приймати

OpenVPN 2.5 замінив ncp-ciphers на data-ciphers, а також підняв мінімальну версію TLS за замовчуванням до 1.2. Він змінив і обробку стискання: сторона, що пропонує стискання, відхиляється, якщо конфігурація явно цього не дозволяє, і оголосив застарілими старі назви опцій, як-от ns-cert-type на користь remote-cert-tls. Кожна з цих змін перетворює раніше робочу конфігурацію на відмову розбору або узгодження.

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

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

Передумови, специфічні для Broadcom

На збірках Broadcom тунельний пристрій має існувати до того, як демон зможе його використати. Перевірте, що модуль tun завантажено і що /dev/net/tun присутній, бо відсутній пристрій дає відмову запуску, яка не має нічого спільного із сертифікатами. Те саме стосується допоміжних скриптів, які DD-WRT створює для маршрутів і DNS: якщо їх немає або вони не виконувані, демон може запуститися і все одно не завершити налаштування.

Запустіть демон у передньому плані з більшою докладністю на створеній конфігурації, коли потрібне справжнє повідомлення. Запуск у передньому плані друкує помилку розбору, яку проковтнув init-скрипт.

Потім відновіть звичайну службу, бо демон у передньому плані та init-скрипт боротимуться за порт.

Доведіть, що слухач існує, перш ніж налагоджувати клієнтів

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

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

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

Схожі статті