Два идентитета у једном IKEv2 пријављивању: уређај, затим корисник

Клијентски сертификат се верификује, прва размена се завршава, а затим веза престаје са грешком о додатном кругу провере идентитета. Ништа у ланцу сертификата није погрешно и ништа у мрежи се није променило. Гејтвеј је конфигурисан да захтева други доказ од стране која се повезује, а клијент га никада не шаље. Одлучити ко шта доказује и којим редом јесте цео задатак, и почиње читањем политике са крајње тачке на којој стојите. Два доказа различите врсте, у фиксном редоследу, јесу пројектна одлука, а не поље за штиклирање.

Симптом: неуспех после успешног првог доказа

Прва размена се завршава и дневник изгледа здраво, све док гејтвеј не затражи кориснички идентитет преко EAP. Руковање тада стаје или враћа грешку протокола која именује додатни круг. Потпуно важећи сертификат уређаја бива одбијен из разлога који нема везе са његовом ваљаношћу. Политика је затражила други доказ, а одговор клијента никада није стигао.

Оба описа тог неуспеха су тачна, зависно од тога где стојите. Са клијентске стране то изгледа као сервер који одбија важећи сертификат, а са серверске стране као клијент који не може да заврши пријаву. Исти догађај се у једном дневнику чита као проблем поверења, а у другом као проблем могућности. Само конфигурисана политика вам каже која је.

Шта проширење додаје, а шта не

IKEv2 носи проширење за извођење више од једне размене провере идентитета унутар једне сесије. RFC 4739 скицира, између осталих секвенци, клијента који доказује идентитет сертификата, а затим верификује особу преко EAP. Документ је експериментални, што значи да вам ниједна имплементација не дугује ту функцију. Не претпостављајте ништа о подршци док је друга страна не преговара.

Обе стране морају да подрже проширење и да се сагласе око њега током размене. Гејтвеј конфигурисан за други круг не може натерати клијента да га изведе, а клијент који га подржава неће га користити ако сервер не затражи. Та асиметрија је разлог зашто се неуспех обично појављује као истек времена или грешка протокола, уместо као јасна изјава о могућностима. Читање конфигурације једне стране каже вам половину онога што ће се догодити.

Један доказ по крајњој тачки је нормалан облик и није овај дизајн. Гејтвеј представља свој сертификат, корисник одговара на EAP, и свака страна је верификовала ону другу тачно једном. Та два доказа долазе са супротних крајњих тачака, па ниједан не говори ништа засебно о уређају и особи која га користи.

EAP-TLS је трећи облик и такође није овај. Тамо се клијентски сертификат представља унутар EAP методе, па клијент ипак завршава једну IKE верификацију. Акредитиви могу изгледати идентично као у случају више кругова, док протокол носи један круг уместо два. Зато дизајн копиран из EAP-TLS распореда не успева тачно на месту где се очекује други доказ.

Иста датотека се чита другачије на гејтвеју

Иста swanctl датотека се чита другачије зависно од тога где се извршава, и то је део који збуњује људе. На лаптопу је гејтвеј друга страна, а на гејтвеју је то лаптоп, зато локалну страну пишите као ко сам ја, а удаљену као кога ћу прихватити. Локални блок описује како ова крајња тачка верификује себе, а удаљени блок наводи шта захтева од друге стране. Копирање блока између две датотеке преокреће његово значење без промене иједног знака. Упоређивање две датотеке не каже вам готово ништа, јер исте речи у свакој значе супротно.

Положај одељка одређује његов редослед, осим ако га број круга не надјача. Додатни локални или удаљени одељци стога описују додатне кругове, а не алтернативе, и експлицитни број круга у референци за swanctl.conf постоји управо да то редоследно понашање учини намерним. Без њега, премештање блока мења понашање. То је такође разлог зашто две конфигурације које на папиру изгледају једнако могу да се понашају у супротном редоследу.

То правило редоследа производи режим отказа који вреди запамтити. Други удаљени блок није још једна прихватљива опција; то је други захтев, зато се политика која се чита као или/или понаша као и-затим. Политика гејтвеја може прихватити сертификат уписаног уређаја, а затим захтевати EAP размену тог корисника, тим редом.

Разликујте кругове од независних фактора

Два круга нису аутоматски два независна фактора. Понављање доказа, или држање два акредитива у истом складишту, не даје снагу коју је дизајн требало да дода. Независност је својство начина на који се тајне чувају и онога што их компромитује, а не броја размена које протокол изводи. Дизајн који кругове рачуна као факторе прецењује оно што има. Та разлика је најважнија када питање усаглашености пита колико фактора пријава заиста користи.

Сертификат уређаја доказује поседовање његовог прихваћеног кључа и ништа више. Он није хардверска атестација ни извештај о здрављу уређаја, па политика која тражи податке о стању тражи други механизам. Ни поље subject није ознака инвентара којој можете веровати, јер subject бира онај ко је сертификат издао или уписао. Ако дизајн тражи доказ да је уређај здрав, тај доказ мора доћи од компоненте која мери уређај.

Запишите шта сваки круг заиста доказује пре него што га додате. Када два круга доказују исту ствар два пута, други додаје кашњење и тикете подршке уместо осигурања. Та белешка је и оно што зауставља расправу о томе да ли додатни круг оправдава своју цену.

Напишите правило упаривања и тестирајте одбијања

Одлучите које идентитете уређаја смеју да се упаре са којим људима, и напишите правило тамо где је спровођење. Два важећа акредитива један поред другог не доказују ништа о упаривању, јер је упаривање одлука о ауторизацији, а не резултат верификације. Евиденција уписа или бекенд за верификацију мора да спроведе однос који организација жели.

Затим тестирајте шта треба да не успе: прихваћен корисник на неодобреном уређају, неодобрен корисник који држи акредитив уређаја, и друга страна која не може да изведе додатни круг. Ако сва три тихо добију исти приступ, политика описује намеру уместо да је спроводи. Упоредите декларисану конфигурацију са оним што демон пријављује, јер веза која се никада није поклопила изгледа идентично као правило које је прошло:

swanctl --list-conns
swanctl --list-sas

Проверите преговаране кругове и резултујућу ауторизацију, не само успешну пријаву. И не прибегавајте застарелим XAuth подешавањима IKEv1 као пречици: ускладите протокол, улоге, редослед и стварно понашање клијента, уместо да бришете захтевани круг док веза не проради. Брисање круга који не успева је начин на који дизајн са два доказа тихо постаје дизајн са једним доказом који нико није прегледао. Задржите брисање у евиденцији промена.