Чаму Android падключаецца да хатняга IPsec VPN, а Windows не

Тэлефон без скаргаў падключаецца да VPN роўтара, а ноўтбук у той жа Wi-Fi не можа. Тыя ж уліковыя даныя, той жа сервер, тая ж хвіліна. Розніца ў падтрымцы пратакола, а не ў паролі: роўтар прапануе профіль, які адна аперацыйная сістэма рэалізуе, а другая не мела ніколі.

Спачатку вызначце профіль, затым параўнайце яго з тым, што кожны кліент фактычна гаворыць.

Адно меню, тры пратаколы

Пад адным загалоўкам IPsec спажывецкая прашыўка можа хаваць тры зусім розныя тунелі. Першы — IKEv1 з XAUTH: агульны сакрэт групы, а зверху імя карыстальніка і пароль. Другі — L2TP/IPsec, дзе PPP працуе ўсярэдзіне транспарту IPsec, абароненага агульным ключом. Трэці — IKEv2, які аўтэнтыфікуецца сертыфікатамі або EAP.

Чытайце палі, а не назву. Агульны сакрэт групы плюс спіс карыстальнікаў — гэта IKEv1 XAUTH. Агульны ключ плюс уліковы запіс PPP — гэта L2TP/IPsec. Серверны сертыфікат без агульнага сакрэту — гэта IKEv2.

Разрыў у падтрымцы паміж тэлефонам і ноўтбукам

Android мае ўбудаваны кліент IKEv1 XAUTH PSK, менавіта таму тэлефон паспяхова працуе з роўтарам, які не прапануе нічога іншага. Windows — не: яго ўласны кліент падтрымлівае L2TP/IPsec і IKEv2, і опцыі IKEv1 XAUTH няма. Паўторны ўвод сакрэту не дапаможа, бо не хапае пратакола, а не ўліковых даных.

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

Дзве налады, якія ламаюць слушныя профілі

Старонка L2TP/IPsec у Synology прапануе сцяжок Enable SHA2-256 compatible mode (96 bit). Кліенты Apple пачынаючы з iOS 14 і macOS Big Sur адхіляюць гэты ўрэзаны рэжым, таму для іх сцяжок трэба зняць. Калі пакінуць яго ўключаным, тунель аўтэнтыфікуецца і потым абрываецца, што выглядае як дрэнныя ўліковыя даныя і не з’яўляецца імі. Вытворца дакументуе перамыкач, і абнаўленне аперацыйнай сістэмы — звычайна той момант, калі гэта пачынае мець значэнне.

Windows трымае сертыфікаты ў двух асобных сховішчах, і IKEv2 чытае толькі машыннае. Імпартуйце кліенцкі сертыфікат з прыватным ключом ва ўліковы запіс камп’ютара; сертыфікат, змешчаны ў ваш уласны ўліковы запіс, бачны ў кансолі кіравання, але ніколі не дасягае службы IKEv2. EAP-TLS — адзіны выпадак, калі сертыфікат карыстальніка прыдатны, і падпісвальны CA ўсё роўна павінен быць давераны машыне. Памылка тут выглядае як збой аўтэнтыфікацыі, а не як запыт адсутнага сертыфіката.

Калі роўтар застаецца як ёсць

Роўтар, які гаворыць толькі XAUTH PSK, пакідае тры шляхі: кліент вытворцы, кліент трэцяга боку, які ўсё яшчэ рэалізуе профіль, або перанос канцавой кропкі тунеля на нешта, што гаворыць IKEv2. Напрыклад, AVM публікуе кліенцкае праграмнае забеспячэнне для Windows і экспартаваны файл канфігурацыі для сваіх роўтараў. Гэты шлях падтрымліваецца і азначае ўсталяванне інструмента вытворцы на кожным ноўтбуку.

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

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

Дыягнастуйце звонку ўнутр

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

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