strongSwan EAP: ідентичність IKE проти очікуваного імені AAA

Клієнт strongSwan EAP може перевіряти два імені сервера. remote.id охоплює шлюз IKE, а local.aaa_id — сервер EAP; це не одне поле.

Автентифікація EAP через IKEv2 може вимагати від клієнта перевірити два різні імені сервера в одному з’єднанні. Шлюз, що завершує IKE, пред’являє одну ідентичність, а серверна частина EAP, що завершує внутрішній обмін TLS, може пред’явити іншу. У strongSwan вони живуть у різних блоках конфігурації, і ім’я в неправильному блоці дає збій, що виглядає як проблема із сертифікатом. Саме читання того, яка перевірка не пройшла, показує, який блок правити.

Одне з’єднання, дві ідентичності сервера

Перша ідентичність належить обміну IKE. Клієнт набирає адресу й очікує, що протилежна сторона доведе певну ідентичність, зазвичай ім’я в сертифікаті шлюзу.

Друга належить EAP. З PEAP або TTLS клієнт будує тунель TLS до сервера автентифікації всередині IKE SA, і цей внутрішній сервер пред’являє власний сертифікат. Коли серверна частина — окремий хост, її ім’я відрізняється від імені шлюзу. Клієнт, який перевіряє лише перше ім’я, приймає все, що стверджує друге. А клієнт з одним іменем в обох місцях зазнає збою, щойно ці два справді розійдуться.

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

Яке поле належить якому рівню

У swanctl адреса й ідентичність IKE — окремі налаштування, а ідентичність EAP — третя.

Віддалена адреса вибирає, куди йдуть пакети, а віддалена ідентичність указує, що має довести протилежна сторона. Очікування EAP записується під блоком local, бо воно описує обмін EAP цього клієнта, а не поведінку IKE протилежної сторони. Саме це розміщення читають неправильно. Ім’я стоїть у конфігурації клієнта, описуючи при цьому сервер, і через це воно здається недоречним.

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

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

Чому aaa_id живе під local

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

Значення за замовчуванням робить пастку гострішою. Коли явне значення не задано, очікувана ідентичність AAA йде за віддаленою ідентичністю, тож розгортання з одним іменем працює й приховує різницю. Явне значення важливе лише тоді, коли розгортання EAP справді завершується деінде. Встановлення його на інше ім’я без цієї причини створює збій, який оператор не може відтворити. Прочитайте розгортання, перш ніж вигадувати друге ім’я.

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

Інтерфейси, які не можуть виразити розділення

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

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

Альтернативу не слід вигадувати на клієнті. Запросіть підтримувану схему письмово, потім зберігайте цю відповідь разом із профілем.

Відрізняйте невідповідність ідентичності від простроченого сертифіката

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

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

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

Схожі статті