Обменът IKEv2 работи, после удостоверяването се проваля: къде

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

Проверка 1: четете етапа, а не съобщението

Отказът може да дойде от три места: клиентът отхвърля самоличността на сървъра, шлюзът отхвърля доказателството на клиента, а външна услуга за удостоверяване отхвърля акаунта.

Всяко от тях дава различен ред в журнала на различна машина и всяко има различно решение. Отхвърлянето на сертификата на сървъра от страна на клиента е проблем на доверие или име при клиента; отхвърлянето на сертификата на клиента от шлюза е проблем на доверие при шлюза; провал на EAP е проблем на акаунта или на бекенда. Съобщението, което виждате, обикновено е резюме от клиента на едно от тези, затова журналът на шлюза е също толкова важен, колкото този на клиента.

Проверка 2: коя самоличност е проверена

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

В термините на strongSwan това е rightid при клиента, а от другата страна — собствената самоличност на шлюза, и несъответствието се проваля още преди да се обсъжда EAP.

Шлюзът отделно може да отхвърли сертификата на клиента, доказателството за ключа му или удостоверяването на акаунта му, и тези три не са взаимозаменяеми. Нулирането на потребителска парола не подновява сертификат на устройство, а преинсталирането на сертификат на устройство не поправя грешна самоличност на сървъра. При проблеми със сертификати проверете първо часовника, после веригата на доверие, после очаквания идентификатор; клиент, чийто часовник изостава с минути, се проваля на проверка за валидност, която изглежда като проблем с доверието. swanctl --list-certs в двата края показва какво реално притежава всяка страна.

Проверка 3: ако EAP участва

Клиентът и сървърът трябва да се съгласят за поддържан метод, а бекендът трябва да приеме предоставената самоличност.

Потребителското име може да се нуждае от домейн суфикс или специфичен формат на акаунта, който внедряването изисква, и форматът е документиран, а не гадаем. Предоставянето на документираните от оператора полета е по-бързо от проба на варианти и избягва втори проблем: повторените опити могат да задействат блокиране на акаунта, което после скрива първоначалния етап зад нов провал. Ако методът е EAP-MSCHAPv2 срещу директория, провалът може да е на директорията, а не на VPN.

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

Проверка 4: какво става след успешен вход

След като IKE_AUTH завърши, преговорите по CHILD_SA решават кои селектори за трафик се инсталират и точно там връзката може да успее и пак да не пропуска нищо.

Ново проработилият вход често разкрива проблем със селектор или маршрут, който преди е бил скрит зад отказа на удостоверяването. Ако тунелът се вдигне, а приложение все още не достига дестинацията си, гледайте договорените селектори и маршрутите, а не отново самоличността. Промяната на настройки за самоличност в този момент удря грешния етап и обикновено чупи работещ вход. Потвърдете с swanctl --list-sas, който показва децата и селекторите им отделно от IKE SA.

Проверка 5: какво да дадете на поддръжката

Изчистена хронология и точният отказ струват повече от пълен диагностичен експорт, а експортът може да съдържа частни ключове или данни за достъп, които не бива да споделяте.

Запишете времето с часовата зона, версиите на клиента и шлюза, метода, низа на самоличността, който е бил предложен, а не паролата, и точния етап, който го е отхвърлил. документацията за конфигурация на strongSwan IKEv2 описва настройките за самоличност и EAP, които решават тези изходи, и това е справочникът, който да прочетете, преди да променяте поле. След това променете едно нещо и тествайте нова връзка, защото кеширана сесия ще ви говори за старата конфигурация.