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

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-идентитет не обновува сертификат ниту воспоставува доверба во неговиот издавач, а обновувањето на сертификат не го поправа погрешното очекувано име. Прочитајте кое валидирање не успеа пред да уредите уште едно поле за идентитет. Потоа вчитајте ја конфигурацијата повторно и потврдете дека вчитаната врска ја прикажува вредноста што ја поставивте, зашто уредена датотека што никогаш не била вчитана не менува ништо. Запишете ги двете имиња и нивните слоеви во белешките за распоредување.