IKEv1 з XAuth і OTP: што пытае кожнае поле

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

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

Тры таямніцы, тры ўладальнікі

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

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

PSK: бок, а не чалавек

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

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

XAuth: састарэлы абмен карыстальніка

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

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

OTP: тое, што запытвае бэкенд

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

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

Дзе ўпіраецца мяжа кліента

Fortinet паведамляе, што FortiClient 7.4.4 і наступныя ўжо не падтрымліваюць IKEv1 для IPsec VPN, і гэта мяжа прадукту і версіі, а не ўсеагульнае выдаленне, як заўвага пра сумяшчальнасць FortiClient гэта фіксуе. Іншыя кліенты таксама не ўзаемазаменныя: OpenConnect і openfortivpn гавораць на пэўных пратаколах шлюза, а не на адвольных профілях IKEv1. Праверце версію IKE, рэжым PSK, падтрымку XAuth і мадэль узаемадзеяння ўсталяванага кліента па асобнасці. Кліент, які падключаецца іншым метадам, не даказаў зыходнае патрабаванне.

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

Дыягностыка без адключэння фактару

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

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