Рукопожатие 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 или попросите кого-нибудь вне сети и следите за счётчиком маршрутизатора во время этой попытки. Если удалённая попытка сбоит, а локальная удаётся, переадресация или брандмауэр всё ещё в игре.

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