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

Мрежни пролаз који мења адресу може да настави да ради док се исти мрежни пролаз иза новог сертификата заустави, а дешава се и обрнуто. Адреса говори клијенту где да пошаље пакете; аутентификовани идентитет говори клијенту да ли је колега који одговара онај коме треба да верује. IKEv2 их чува као два одвојена поља, што је корисно када престанете да их третирате као један низ. Такође су конфигурисани на различитим местима, тако да једно може бити исправно док друго није у реду.

Проверите их овим редоследом и зауставите се на првом неслагању, јер касније провере претпостављају да су прошле прошле.

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

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

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

Друго, шта сертификат може да докаже

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

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

Треће, како сваки клијент изражава очекивања

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

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

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

EAP аутентификација и идентитет сервера одговарају на различита питања. EAP идентитет као што је [email protected] говори ко је корисник, након што је клијент одлучио да је сервер прави. Ротирање те лозинке не може да поправи неусклађеност истоврсног идентитета, јер веза никада не досеже фазу пријављивања корисника.

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

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

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

Забележите коначну адресу, идентитет и SAN листу заједно у белешкама о профилу. Следећа особа која додирне сертификат ће тада видети коме од њих троје је дозвољено да се креће.