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

Подобни статии