Сертыфікат шлюза ў парадку: чаму ўваход IKEv2 PEAP усё ж не атрымліваецца

Сертыфікат вашага VPN-шлюза дзейны, ланцуг праходзіць праверку, а кліент IKEv2 усё роўна адмаўляецца ўваходзіць з паведамленнем пра тэрмін дзеяння сертыфіката. Першая думка — перавыпусціць сертыфікат шлюза або змяніць метад EAP, і абодва варыянты звычайна няправільныя. Спроба ўваходу нясе дзве асобныя асобы сервера: сертыфікат шлюза, які выкарыстоўвае IKE, і сертыфікат, які прад’яўляе той, хто завяршае PEAP. Адна з іх у парадку, і менавіта другая стала прычынай, чаму кліент спыніўся.

Дзве асобы, адна спроба ўваходу

Сертыфікат у профілі VPN належыць абмену IKE: ён даказвае, што шлюз з’яўляецца тым бокам, які названы ў профілі, у межах наладжанай палітыкі IKE. Сертыфікат, які тут не праходзіць, належыць іншай размове — TLS-сесіі, якую PEAP адкрывае з тым, хто аўтэнтыфікуе карыстальніка; гэта часта RADIUS-сервер, напрыклад NPS, а не сам шлюз. Трэцяя праверка, уліковыя даныя карыстальніка, адбываецца ўнутры гэтай сесіі. Дзейны пароль не можа адрамантаваць пратэрмінаваны сертыфікат сервера, а дзейны сертыфікат шлюза не можа паручыцца за канчатковы пункт PEAP.

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

Чытайце радок журнала ў адпаведнасці з этапам

Знайдзіце паведамленне, у якім названы прычына і даты. Скарга на тэрмін дзеяння побач з памылкай суб’екта азначае, што сервер адхіліў прадстаўлены яму сертыфікат, а не тое, што карыстальнік адхіліў уваход. Затым вызначце этап: журнал charon у strongSwan паказвае IKE_SA .* established да пачатку абмену EAP, таму памылка сертыфіката пасля гэтага радка належыць асобе EAP, а памылка да яго паказвае на шлюз. Тэкст этапа ў панэлі падключэння кліента Windows кажа тое ж самае.

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

Вызначце, які канчатковы пункт завяршае PEAP

У схеме «шлюз плюс RADIUS» шлюз перадае EAP і не завяршае яго. Плагін eap-radius у strongSwan перадае абмен RADIUS-серверу, якому належаць TLS-сесія PEAP і яе сертыфікат. Супастаўце адну няўдалую спробу па абодвух журналах і ўпэўніцеся, які працэс сапраўды выбраў сертыфікат для гэтай сесіі.

Для NPS сертыфікат павінен ляжаць у сховішчы лакальнага камп’ютара, мець прызначэнне аўтэнтыфікацыі сервера, адпавядаць імені, якога чакаюць кліенты, і быць чытэльным для ўліковага запісу службы. Патрабаванні Microsoft да сертыфікатаў для NPS пералічваюць гэтыя ўмовы. Іншыя EAP-серверы маюць уласныя правілы выбару, таму не пераносьце асаблівасці NPS у разгортванне FreeRADIUS і наадварот. Правіла, якое застаецца слушным у любым выпадку: канчатковы пункт, што завяршае PEAP, валодае сертыфікатам, які вы збіраецеся змяніць.

Замяніце сертыфікат там, дзе завяршаецца EAP

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

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

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

Чаго не рабіць

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

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