IKEv2 адреса на серверот наспроти идентитет: што клиентот всушност проверува

Портата што ја менува адресата може сѐ уште да работи додека истата порта зад нов сертификат запира, а се случува и обратното. Адресата му кажува на клиентот каде да испраќа пакети; автентицираниот идентитет му кажува на клиентот дали врсникот што одговара е оној на кого треба да му верува. IKEv2 ги чува како две посебни полиња, што е корисно откако ќе престанете да ги третирате како една низа. Тие исто така се конфигурирани на различни места, така што едното може да биде точно додека другото не е во ред.

Проверете ги по овој редослед и застанете на првото несовпаѓање, бидејќи подоцнежните проверки претпоставуваат дека претходните поминале.

Прво, која вредност е адресата

Адресата за поврзување е она што клиентот го бира: IP, име DNS што се решава на еден или преден крај балансиран со оптоварување. Тоа се информации за транспорт и ништо повеќе. Идентитетот се вози во IKEv2 лична карта и потоа се совпаѓа со сертификатот на врсникот. Името DNS во полето за адреса не станува очекуван идентитет, а необработената IP не станува идентитет само затоа што штекерот е поврзан со него.

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

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

Идентитетот има тип, а сертификатот треба да носи соодветно име. Идентитетот DNS се задоволува со запис dNSName во наставката за алтернативно име на предметот; на IP-идентитетот му треба внесување iPAddress. Сертификатот издаден за vpn.example.com не докажува ништо за буквалната адреса 203.0.113.10, а оној издаден за таа адреса не докажува ништо за името. Затоа, повторното издавање за различно име не е замена, дури и кога истиот клуч и CA повторно се користат.

Современите клиенти го игнорираат вообичаеното име кога постои алтернативно име на предметот, а многумина целосно го игнорираат. Ако списокот SAN не ја содржи вредноста што ја проверува клиентот, ракувањето не успева откако сертификатот веќе е прифатен како доверлив, поради што дневникот се чита како грешка на идентитетот наместо како грешка на доверба.

Трето, како секој клиент ги наведува очекувањата

Windows го зема името на серверот или адресата што сте ја напишале и бара сертификатот да се совпадне со нив, така што пишувањето IP создава очекување за IP. Клиентот на Android на IKEv2 се однесува на ист начин и обајцата одбиваат важечки, јавно доверлив сертификат кој именува различен хост. Профилот може да почне да не успева само затоа што некој го заменил името на домаќинот со неговата адреса за време на миграцијата. Погледнете што бара клиентот пред да погледнете што содржи сертификатот.

На strongSwan очекувањата се експлицитни: поставете го rightid на идентитетот што серверот всушност го прикажува, што може да се разликува од десно. Поставувањето на %any прифаќа се што ќе понуди врсникот и го отстранува токму чекот што се обидувате да го задржите.

Четврто, одделете го корисничкото најавување од идентитетот на колегите

EAP автентикацијата и идентитетот на серверот одговараат на различни прашања. Идентитетот EAP како што е [email protected] кажува кој е корисникот, откако клиентот ќе одлучи дека серверот е вистинскиот. Со ротирање на таа лозинка не може да се поправи несовпаѓањето на идентитетот на врсниците, бидејќи врската никогаш не стигнува до фазата за најавување на корисникот.

Исчистениот извештај треба да ги именува и двете: идентитетот што го очекувал клиентот, идентитетот што го презентирал серверот и записите на сертификатот SAN.

Петто, сменете го преку проверен канал

Кога портата легитимно ќе се помести, прво ажурирајте ја адресата и оставете го идентитетот сам, бидејќи тоа е случајот што IKEv2 добро се справува. Кога самиот идентитет ќе се промени, третирајте го како настан за доверба и добијте ја новата вредност од извор на кој веќе му верувате, а не од крајната точка што моментално не успева. Пораката испорачана преку врската што се обидувате да ја потврдите не е доказ за таа врска.

Запишете ја конечната адреса, идентитетот и списокот SAN заедно во белешките на профилот. Следното лице што ќе го допре сертификатот ќе види на кое од тројцата му е дозволено да се движи.