Памылка TLS-узгаднення 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 — трэцяя праверка: правіла, якое дазваляе порт з лакальнай падсеткі, але не з інтэрнэту, лёгка забыць пасля тэставання, і яно дае злучэнне, якое працуе з кухні і не працуе з усіх іншых месцаў.

Праверце шлях, якім сапраўды ідзе аддалены карыстальнік

Кліент у той жа LAN можа дасягнуць NAS, нават не кранаючы перанакіравання, таму гэта нічога не даказвае пра аддалены доступ. Выкарыстайце тэлефон з выключаным Wi-Fi або папрасіце кагосьці па-за сеткай і назірайце за лічыльнікам роўтара падчас гэтай спробы. Калі аддаленая спроба збоіць, а лакальная атрымліваецца, перанакіраванне або фаервал усё яшчэ ў справе.

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