Две самоличности в един вход по IKEv2: първо машината, после потребителят

Клиентски сертификат се валидира, първият обмен завършва и след това връзката спира с грешка за допълнителен кръг на удостоверяване. Във веригата на сертификата няма нищо сбъркано и в мрежата нищо не се е променило. Шлюзът е конфигуриран да изисква второ доказателство от свързващата се страна, а клиентът никога не го изпраща. Да се реши кой какво доказва и в какъв ред е цялата задача, и тя започва с четене на политиката от крайната точка, на която стоите. Две доказателства от различен вид, в фиксиран ред, е проектно решение, а не отметка в квадратче.

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

Първият обмен завършва и журналът изглежда здрав, докато шлюзът поиска потребителска самоличност чрез EAP. Тогава ръкостискането засича или връща протоколна грешка с името на допълнителния кръг. Напълно валиден машинен сертификат се отхвърля по причина, която няма нищо общо с валидността му. Политиката поиска второ доказателство, а отговорът на клиента така и не дойде.

И двете описания на този провал са точни в зависимост от това къде стоите. От страна на клиента изглежда като сървър, който отхвърля валиден сертификат, а от страна на сървъра — като клиент, който не може да завърши входа. Едно и също събитие се чете като проблем с доверието в единия журнал и проблем със способностите в другия. Само конфигурираната политика ви казва кой от двата е.

Какво добавя разширението и какво не

IKEv2 носи разширение за повече от един обмен на удостоверяване в една сесия. RFC 4739 описва, наред с други последователности, клиент, който доказва самоличност по сертификат и после удостоверява човек чрез EAP. Документът е със статус Experimental, което значи, че никоя реализация не ви е длъжна с тази функция. Не предполагайте нищо за поддръжката, докато партньорът не я договори.

Двете страни трябва да поддържат разширението и да се съгласят за него по време на обмена. Шлюз, конфигуриран за втори кръг, не може да принуди клиент да го изпълни, а клиент, който го поддържа, няма да го използва, освен ако сървърът не поиска. Именно тази асиметрия е причината провалът обикновено да се проявява като изчакване или протоколна грешка, вместо като ясно изявление за възможности. Четенето на конфигурацията на едната страна ви казва половината от това, което ще се случи.

Едно доказателство на крайна точка е нормалната форма и това не е този дизайн. Шлюзът представя своя сертификат, потребителят отговаря по 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 като към пряк път: съпоставете протокола, ролите, реда и реалното поведение на клиента, вместо да изтривате задължителен кръг, докато връзка не успее. Изтриването на кръга, който се проваля, е начинът, по който дизайн с две доказателства тихо става дизайн с едно доказателство, който никой не е прегледал. Запазете изтриването в записа на промените.