Слухач OpenVPN 2.5 на DD-WRT памёр? Прачытайце створаны канфіг

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

Дэман — не файрвол

Гэта розніца важная, бо знешне абодва збоі выглядаюць аднолькава: кліент адпраўляе рукапоціск і не атрымлівае адказу. Адзін — гэта працэс, які не працуе, другі — працэс, які працуе і фільтруе.

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

Прачытайце канфіг, створаны 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. Кожнае з гэтых змяненняў ператварае раней працоўную канфігурацыю ў збой разбору або перамоваў.

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

Чытайце першую памылку ў журнале, а не апошнюю. Разбор спыняецца на першай дрэннай дырэктыве, і ўсё пасля яе — шум ад завяршэння.

Папярэднія ўмовы, спецыфічныя для Broadcom

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

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

Затым аднавіце звычайную службу, бо дэман у пярэднім плане і init-скрыпт будуць змагацца за порт.

Дакажыце, што слухач існуе, перш чым наладжваць кліентаў

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

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

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