EAP ці кліенцкія сертыфікаты? Як вызначыць аўтэнтыфікацыю IKEv2
Два ўліковыя даныя, дзве задачы: адно даказвае канечны пункт, другое — карыстальніка. Вызначце, які этап не спрацаваў, перш чым скідваць пароль ці перавыдаваць сертыфікат.
Ваш шлюз можа даказаць уласную ідэнтычнасць сертыфікатам, а вашу — праз EAP, і гэта спалучэнне звычайнае, а не супярэчлівае. Два механізмы адказваюць на розныя пытанні: ці гэты канечны пункт менавіта той, якога я чакаю, і ці гэты карыстальнік або прылада мае дазвол. Наяўнасць EAP у профілі не адключае праверку сервера. Менавіта чытанне профілю як аднаго параметра прыводзіць людзей да скіду не таго ўліковага даных.
Вызначце, якое патрабаванне не спрацавала, перш чым кранаць любы з двух аб’ектаў. Этап збою скажа вам гэта, калі чытаць па парадку.
Два ўліковыя даныя, два патрабаванні
Сертыфікат сервера звязвае імя з ключом, і кліент правярае гэтую сувязь па сваім сховішчы даверу. Кліенцкі сертыфікат звязвае ідэнтычнасць з ключом, і шлюз правярае, што прадстаўлены сертыфікат ланцужком вядзе да чагосьці, чаму ён давярае. EAP нясе абмен аўтэнтыфікацыі, змест якога залежыць ад абранага метаду. Гэта тры структуры з рознымі тэрмінамі жыцця, рознымі ўладальнікамі і рознымі рэжымамі збою.
Парольная фраза, якая адкрывае прыватны ключ, не з’яўляецца паролем уліковага запісу, нават калі абодва запыты з’яўляюцца на працягу секунд адзін ад аднаго. Адзін лакальны для сховішча ключоў прылады, а другі правяраецца серверам аўтэнтыфікацыі за шлюзам.
EAP — гэта кантэйнер, а не метад
EAP — гэта каркас: шлюз і кліент дамаўляюцца пра метад, і метад вызначае, ці задзейнічаны пароль, токен, тунеляваны ўнутраны абмен ці сертыфікат, як тлумачыць дакументацыя strongSwan па IKEv2. Менавіта таму EAP-TLS зусім не падобны на EAP-MSCHAPv2 з боку кліента, хоць абодва паказваюцца як EAP у меню. Профіль, які называе толькі EAP, не паведаміў вам, што спытаюць у карыстальніка.
Чытайце метад і бэкенд разам. Бэкенд вызначае фармат уліковага запісу, паводзіны блакіроўкі і тое, што насамрэч змяняе скід пароля, і нічога з гэтага не відаць у кліенцкім профілі.
Змяшанае разгортванне — гэта норма
Сертыфікат сервера плюс EAP для карыстальніка — гэта форма, якую разгортвае большасць шлюзаў аддаленага доступу, бо яна дае кліенту правяральны канечны пункт, а аператару — ідэнтычнасць кожнага карыстальніка ў цэнтральным сховішчы ўліковых запісаў. Разгортванні з кліенцкімі сертыфікатамі таксама існуюць, звычайна там, дзе ідэнтычнасць прылады важнейшая за пароль. Абодва законныя, і памылка — меркаваць, што тое, што вы бачылі на мінулым тыдні, і ёсць тое, што перад вамі.
Спытайце ў аператара дакументаваны метад і фармат уліковага запісу, замест таго каб выводзіць іх з назваў палёў у кліенце.
Рашэнне па этапе збою
Упарадкуйце назіранні. Памылка даверу да любога запыту карыстальніка — гэта праблема сертыфіката сервера, і ніякі пароль яе не выправіць. Запыт, за якім ідзе адмова, — гэта праблема аўтэнтыфікацыі карыстальніка, а метад EAP і бэкенд — падазраваныя. Паспяховая аўтэнтыфікацыя, за якой ідзе збой child-SA, не з’яўляецца ні тым, ні іншым.
Важныя яшчэ два адрозненні. Кліент, які адхіляе сертыфікат сервера, звычайна паведамляе пра неадпаведнасць імені або невядомы цэнтр сертыфікацыі, што ёсць пытаннем сховішча даверу. Шлюз, які адхіляе карыстальніка, часта запісвае метад EAP і катэгорыю прычыны, што ёсць пытаннем уліковага запісу або палітыкі.
Эксплуатацыя дзвюх мадэляў
Для сертыфікатаў работа — гэта выпуск, абнаўленне, адкліканне і выдаленне страчаных прылад, і яна адбываецца па графіку, які вы кантралюеце. Для EAP работа — гэта жыццёвы цыкл уліковага запісу, падтрымка метадаў на кожнай кліенцкай платформе і любы другі фактар, якога патрабуе бэкенд. Ні адна мадэль не таннейшая ў абстракцыі; яны нагружаюць розныя каманды. Запішыце, якую з іх насамрэч выкарыстоўвае ваша разгортванне, бо скрыпты падтрымкі адрозніваюцца больш, чым канфігурацыя.
Трымайце іх асобна ў сваіх нататках. Заканчэнне тэрміну сертыфіката дае збой у пэўную дату, блакіроўка ўліковага запісу дае збой пасля змены пароля, а неадпаведнасць метаду дае збой толькі на адной платформе.
Пасля прыняцця ідэнтычнасці
Аўтэнтыфікацыя — гэта адны вароты. Даччыная асацыяцыя бяспекі, селектары трафіку, DNS і ўласныя дазволы праграмы — гэта наступныя вароты, кожныя з якіх збаіць па сваіх правілах. Прынятая ідэнтычнасць, якая нікуды не дасягае, — гэта не праблема аўтэнтыфікацыі.
Запішыце метад, выкарыстаны ўліковы запіс або сертыфікат і этап, які збаіў. Гэтая нататка ператварае наступны інцыдэнт у пошук замест эксперыменту.