IKEv2 адрес на сървър срещу самоличност: какво всъщност проверява клиентът

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

Проверете ги в този ред и спрете при първото несъответствие, защото по-късните проверки предполагат, че по-ранните са преминали.

Първо, коя стойност е адресът

Адресът на връзката е какъвто клиент набере: IP, DNS име, което се преобразува в едно, или преден край с балансиран товар. Това е транспортна информация и нищо повече. Самоличността се намира в IKEv2 ID полезния товар и след това се съпоставя със сертификата на партньора. DNS име в полето за адрес не се превръща в очакваната идентичност, а необработеният IP не става в идентичност само защото сокетът е свързан към него.

В условията на strongSwan адресът е right или left, а очакваната идентичност е rightid или leftid и това е описано в IKEv2 конфигурационната документация. Ако някога сте редактирали само адреса, вие сте конфигурирали половината от двойката.

Второ, какво може да докаже сертификатът

Самоличността има тип и сертификатът трябва да носи съответстващо име. DNS идентичност е удовлетворена от dNSName запис в алтернативното разширение на името на субекта; една IP идентичност се нуждае от iPAddress запис. Сертификат, издаден за vpn.example.com, не доказва нищо относно буквалния адрес 203.0.113.10, а такъв, издаден за този адрес, не доказва нищо относно името. Следователно повторното издаване за различно име не е заместване, дори когато същият ключ и CA се използват повторно.

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

Трето, как всеки клиент заявява очакванията си

Windows взема името или адреса на сървъра, които сте въвели, и изисква сертификатът да съответства на него, така че въвеждането на IP създава очакване за IP. Клиентът IKEv2 на Android се държи по същия начин и и двата отхвърлят валиден, публично доверен сертификат, който назовава различен хост. Профилът може да започне да се проваля само защото някой е заменил името на хоста с неговия адрес по време на миграция. Вижте какво е поискал клиентът, преди да погледнете какво съдържа сертификатът.

На strongSwan очакването е изрично: задайте rightid на идентичността, която сървърът действително представя, която може да се различава от дясната. Задаването му на %any приема всичко, което партньорът предлага, и премахва точно проверката, която се опитвате да запазите.

Четвърто, отделете потребителското влизане от равностойната идентичност

EAP удостоверяването и самоличността на сървъра отговарят на различни въпроси. EAP самоличност като [email protected] казва кой е потребителят, след като клиентът е решил, че сървърът е правилният. Завъртането на тази парола не може да коригира несъответствие на идентичността на партньор, тъй като връзката никога не достига етапа на влизане на потребителя.

Дезинфекцираният отчет трябва да назовава и двете: самоличността, която клиентът очаква, самоличността, представена от сървъра, и записите SAN на сертификата.

Пето, сменете го през потвърден канал

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

Запишете крайния адрес, самоличността и SAN списъка заедно в бележките на профила. Следващият човек, който докосне сертификата, ще види кой от тримата има право да се движи.