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

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

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

Првата размена завршува и логот изгледа здрав, сѐ додека гејтвејот не побара кориснички идентитет преку EAP. Тогаш ракувањето запира или враќа протоколна грешка што го именува дополнителниот круг. Целосно валиден сертификат на машина се одбива од причина што нема никаква врска со неговата важност. Политиката бараше втор доказ, а одговорот на клиентот никогаш не пристигна.

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

Што додава проширувањето и што не

IKEv2 носи проширување за повеќе од една размена на автентикација во една сесија. RFC 4739 скицира, меѓу другите секвенци, клиент што докажува идентитет со сертификат и потоа автентицира лице преку EAP. Документот сѐ уште е експериментален, што значи дека ниту една имплементација не ви ја должи таа функција. Не претпоставувајте ништо за поддршката додека партнерот не ја договори.

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

Еден доказ по крајна точка е нормалната форма и ова не е тој дизајн. Гејтвејот го презентира својот сертификат, корисникот одговара преку EAP и секоја страна ја автентицирала другата точно еднаш. Тие два докази доаѓаат од спротивни крајни точки, па ниту еден не кажува нешто одделно за машината и лицето што ја користи.

EAP-TLS е трета форма и таа исто така не е оваа. Таму клиентски сертификат се презентира внатре во EAP метод, па клиентот сепак завршува една IKE автентикација. Акредитивите можат да изгледаат идентични на случајот со повеќе кругови, додека протоколот носи еден круг наместо два. Затоа дизајн копиран од распоредување на EAP-TLS пропаѓа точно во точката каде што се очекува вториот доказ.

Истиот файл на гејтвејот се чита поинаку

Истиот swanctl файл се чита поинаку зависно од тоа каде се извршува, и токму тој дел ги сопнува луѓето. На преносниот сметач гејтвејот е партнер, а на гејтвејот преносниот сметач е партнер, па страната local пишете ја како кој сум јас, а страната remote како кого ќе го прифатам. local блокот опишува како оваа крајна точка се автентицира себеси, а remote блокот наведува што бара од другиот крај. Копирањето на блок меѓу двата файла го превртува неговото значење без да смени ниту еден знак. Споредувањето на двата файла не ви кажува речиси ништо, бидејќи истите зборови во секој од нив значат спротивно.

Позицијата на секцијата го одредува нејзиниот ред, освен ако бројот на кругот не го надвладее. Затоа дополнителните секции local или remote опишуваат дополнителни кругови, а не алтернативи, а експлицитниот број на круг во референцата за swanctl.conf постои токму за да го направи тоа подредување намерно. Без него, преместувањето на блок го менува однесувањето. Затоа и две конфигурации што на хартија изгледаат еквивалентни можат да работат во спротивен ред.

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

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

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

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

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

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

Одлучете кои идентитети на машини можат да се спаруваат со кои луѓе и напишете го правилото таму каде што живее спроведувањето. Два валидни акредитиви еден до друг не докажуваат ништо за спарувањето, бидејќи спарувањето е одлука за авторизација, а не резултат на автентикација. Регистрациските записи или автентикацискиот бекенд мора да ја спроведат врската што организацијата ја сака.

Потоа тестирајте што треба да пропадне: прифатен корисник на неодобрена машина, неодобрен корисник што ги има акредитивите на машината и партнер што не може да го изврши дополнителниот круг. Ако сите три тивко добијат ист пристап, политиката опишува намера наместо да ја спроведува. Споредете ја декларираната конфигурација со она што го пријавува демонот, бидејќи врска што никогаш не се совпаднала изгледа исто како правило што поминало:

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

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