IKEv2 naslov strežnika v primerjavi z identiteto: kaj odjemalec dejansko preveri

Prehod, ki spremeni naslov, lahko še naprej deluje, medtem ko se isti prehod za novim potrdilom ustavi, zgodi pa se tudi obratno. Naslov odjemalcu pove, kam naj pošlje pakete; overjena identiteta odjemalcu pove, ali je vrstnik, ki odgovarja, tisti, ki mu mora zaupati. IKEv2 jih hrani kot dve ločeni polji, kar je uporabno, ko jih nehate obravnavati kot en niz. Prav tako so konfigurirani na različnih mestih, tako da je lahko eden pravilen, drugi pa napačen.

Preverite jih v tem vrstnem redu in se ustavite pri prvem neusklajenju, ker kasnejša preverjanja predvidevajo, da so bila prejšnja uspešna.

Prvič, katera vrednost je naslov

Naslov povezave je tisto, kar kliče odjemalec: IP, ime DNS, ki se razreši v eno, ali sprednji del z uravnoteženo obremenitvijo. To so prometne informacije in nič drugega. Identiteta se nahaja v obremenitvi ID-ja IKEv2 in se nato primerja s potrdilom vrstnika. Ime DNS v naslovnem polju ne postane pričakovana identiteta in neobdelani IP ne postane identiteta samo zato, ker je vtičnica povezana z njim.

V izrazih strongSwan je naslov right ali left, pričakovana identiteta pa je rightid ali leftid, in to je tisto, kar opisuje IKEv2 konfiguracijska dokumentacija. Če ste naslov samo urejali, ste konfigurirali polovico para.

Drugič, kaj lahko potrdilo dokaže

Identiteta ima vrsto in potrdilo mora imeti ujemajoče se ime. Identiteta DNS je zadoščena z vnosom dNSName v alternativni razširitvi imena subjekta; IP identiteta potrebuje vnos iPAddress. Potrdilo, izdano za vpn.example.com, ne dokazuje ničesar o dobesednem naslovu 203.0.113.10, potrdilo, izdano za ta naslov, pa ne dokazuje ničesar o imenu. Ponovna izdaja za drugo ime torej ni nadomestna zamenjava, tudi če sta ponovno uporabljena isti ključ in CA.

Sodobni odjemalci ignorirajo splošno ime, ko obstaja alternativno ime subjekta, mnogi pa ga v celoti ignorirajo. Če seznam SAN ne vsebuje vrednosti, ki jo odjemalec preveri, rokovanje ne uspe, potem ko je potrdilo že sprejeto kot zaupanja vredno, zaradi česar se dnevnik bere kot napaka identitete in ne napaka zaupanja.

Tretjič, kako vsaka stranka navede pričakovanja

Windows prevzame ime strežnika ali naslov, ki ste ga vnesli, in zahteva, da se potrdilo ujema z njim, zato vnos IP ustvari pričakovani IP. Odjemalec Android IKEv2 se obnaša enako in oba zavrneta veljavno, javno zaupanja vredno potrdilo, ki imenuje drugega gostitelja. Profil lahko začne odpovedovati zgolj zato, ker je nekdo med selitvijo zamenjal ime gostitelja z njegovim naslovom. Poglejte, kaj je stranka zahtevala, preden pogledate, kaj vsebuje potrdilo.

Na strongSwan je pričakovanje eksplicitno: nastavite rightid na identiteto, ki jo strežnik dejansko predstavlja, ki se lahko razlikuje od desne. Če ga nastavite na %any, sprejme vse, kar ponudi vrstnik, in odstrani točno tisti ček, ki ga želite obdržati.

Četrtič, ločite prijavo uporabnika od istovrstne identitete

Preverjanje pristnosti EAP in identiteta strežnika odgovarjata na različna vprašanja. Identiteta EAP, kot je [email protected], pove, kdo je uporabnik, potem ko se odjemalec odloči, da je strežnik pravi. Obračanje tega gesla ne more popraviti neujemanja identitete vrstnika, ker povezava nikoli ne doseže stopnje prijave uporabnika.

Prečiščeno poročilo mora poimenovati oboje: identiteto, ki jo pričakuje odjemalec, identiteto, ki jo je predstavil strežnik, in vnose SAN potrdila.

Petič, spremenite ga prek preverjenega kanala

Ko se prehod zakonito premakne, najprej posodobite naslov in pustite identiteto pri miru, ker to IKEv2 dobro obravnava. Ko se sama identiteta spremeni, to obravnavajte kot dogodek zaupanja in pridobite novo vrednost iz vira, ki mu že zaupate, ne iz končne točke, ki je trenutno v okvari. Sporočilo, poslano prek povezave, ki jo poskušate preveriti, ni dokaz o tej povezavi.

Zabeležite končni naslov, identiteto in SAN seznam skupaj v opombah profila. Naslednja oseba, ki se dotakne potrdila, bo nato videla, kateri od treh se lahko premakne.