Дві особи в одному вході IKEv2: спершу машина, потім користувач

Сертифікат клієнта перевіряється, перший обмін завершується, і потім з'єднання зупиняється з помилкою про додатковий раунд автентифікації. У ланцюжку сертифікатів усе гаразд, і в мережі нічого не змінилося. Шлюз налаштований вимагати другий доказ від сторони, що підключається, а клієнт його ніколи не надсилає. Вирішити, хто що доводить і в якому порядку, — це все завдання, і воно починається з читання політики на кінцевій точці, де ви стоїте. Два докази різного роду, у фіксованому порядку, — це рішення про дизайн, а не прапорець.

Симптом: збій після успішного першого доказу

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

Обидва описи цього збою правильні залежно від того, де ви стоїте. З боку клієнта це виглядає як сервер, що відхиляє чинний сертифікат, а з боку сервера — як клієнт, що не може завершити вхід. Та сама подія читається як проблема довіри в одному журналі й проблема можливостей в іншому. Лише налаштована політика каже, що це.

Що додає розширення, а що ні

IKEv2 має розширення для виконання більш ніж одного обміну автентифікації в межах однієї сесії. RFC 4739 описує, серед інших послідовностей, клієнта, який доводить ідентичність за сертифікатом, а потім автентифікує людину через EAP. Документ має статус експериментального, тобто жодна реалізація не зобов'язана мати цю функцію. Не припускайте нічого про підтримку, доки інша сторона не узгодить її.

Обидві сторони мають підтримувати розширення й узгодити його під час обміну. Шлюз, налаштований на другий раунд, не може змусити клієнта виконати його, а клієнт, що його підтримує, не використає його, якщо сервер не попросить. Саме через цю асиметрію збій зазвичай виявляється як тайм-аут або помилка протоколу, а не як чітка заява про можливості. Читання конфігурації однієї сторони каже вам половину того, що станеться.

Один доказ на кінцеву точку — це звичайна форма, і це не цей дизайн. Шлюз показує свій сертифікат, користувач відповідає на EAP, і кожна сторона автентифікувала іншу рівно один раз. Ці два докази надходять із протилежних кінцевих точок, тож жоден із них не говорить окремо про машину й людину, яка нею користується.

EAP-TLS — третя форма, і вона також не ця. Там сертифікат клієнта подається всередині методу EAP, тож клієнт усе одно завершує єдину автентифікацію IKE. Облікові дані можуть виглядати ідентично до випадку з кількома раундами, тоді як протокол несе один раунд замість двох. Ось чому дизайн, скопійований із розгортання EAP-TLS, зазнає збою саме там, де очікується другий доказ.

Той самий файл читається інакше на шлюзі

Той самий файл swanctl читається інакше залежно від того, де він виконується, і саме це збиває людей з пантелику. На ноутбуці шлюз є іншою стороною, а на шлюзі нею є ноутбук, тож записуйте локальну сторону як хто я, а віддалену як кого я прийму. Блок local описує, як ця кінцева точка автентифікує себе, а блок remote зазначає, що вона вимагає від іншого кінця. Копіювання блоку між двома файлами перевертає його значення, не змінюючи жодного символу. Порівняння двох файлів майже нічого не каже, бо ті самі слова означають протилежне в кожному.

Позиція розділу задає його порядок, якщо номер раунду її не перекриває. Тому додаткові розділи local або remote описують додаткові раунди, а не альтернативи, і явний номер раунду в довіднику swanctl.conf існує саме для того, щоб зробити цей порядок навмисним. Без нього переміщення блоку змінює поведінку. Ось чому дві конфігурації, що на папері виглядають рівнозначними, можуть поводитися в протилежному порядку.

Це правило порядку породжує режим збою, який варто запам'ятати. Другий блок remote — не ще один прийнятний варіант; це друга вимога, тому політика, що читається як або/або, поводиться як і-потім. Політика шлюзу може прийняти сертифікат зареєстрованої машини, а потім вимагати EAP-обмін цього користувача, саме в такому порядку.

Відрізняйте раунди від незалежних факторів

Два раунди не є автоматично двома незалежними факторами. Повторення доказу або зберігання двох облікових даних в одному сховищі не дає тієї стійкості, яку мав додати дизайн. Незалежність — це властивість того, як зберігаються секрети й що їх компрометує, а не того, скільки обмінів виконує протокол. Дизайн, що рахує раунди як фактори, перебільшує те, що має. Ця різниця найважливіша, коли питання відповідності запитує, скільки факторів насправді використовує вхід.

Сертифікат машини доводить володіння своїм прийнятим ключем і нічого більше. Він не є апаратним засвідченням і не звітом про стан пристрою, тож політика, якій потрібна інформація про поставу, потребує іншого механізму. Поле subject також не є інвентарною міткою, якій можна довіряти, бо subject обирає той, хто видав або зареєстрував сертифікат. Якщо дизайну потрібен доказ, що машина здорова, цей доказ має надходити від компонента, який вимірює машину.

Запишіть, що насправді доводить кожен раунд, перш ніж його додати. Коли два раунди доводять те саме двічі, другий додає затримку й звернення до підтримки замість упевненості. Ця нотатка також зупиняє суперечку про те, чи виправдовує додатковий раунд свою ціну.

Напишіть правило парування й перевірте відмови

Вирішіть, які ідентичності машин можуть паруватися з якими людьми, і запишіть правило там, де живе виконання. Два чинні облікові дані поруч нічого не доводять про парування, бо парування — це рішення про авторизацію, а не результат автентифікації. Записи реєстрації або бекенд автентифікації має забезпечувати відношення, якого хоче організація.

Потім перевірте те, що має зазнавати невдачі: прийнятий користувач на несхваленій машині, несхвалений користувач із обліковими даними машини й сторона, яка не може виконати додатковий раунд. Якщо всі троє тихо отримують однаковий доступ, політика описує намір, а не забезпечує його. Порівняйте заявлену конфігурацію з тим, що повідомляє демон, бо з'єднання, яке ніколи не збіглося, виглядає так само, як правило, що пройшло:

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

Перевіряйте узгоджені раунди й отриману авторизацію, а не лише успішний вхід. І не вдавайтеся до застарілих налаштувань XAuth від IKEv1 як до скорочення: зіставляйте протокол, ролі, порядок і реальну поведінку клієнта, замість того щоб видаляти потрібний раунд, доки з'єднання не запрацює. Видалення раунду, що зазнає невдачі, — це те, як дизайн із двома доказами тихо стає дизайном з одним доказом, який ніхто не переглядав. Тримайте видалення в записі змін.