IKEv2 serveri aadress vs identiteet: mida klient tegelikult kontrollib

Aadressi muutev lüüs võib edasi töötada, kuni uue sertifikaadi taga olev lüüs peatub ja juhtub ka vastupidi. Aadress ütleb kliendile, kuhu paketid saata; autentitud identiteet ütleb kliendile, kas vastaja on see, keda ta peaks usaldama. IKEv2 säilitab need kahe eraldi väljana, mis on kasulik, kui lõpetate nende käsitlemise ühe stringina. Samuti on need konfigureeritud erinevates kohtades, nii et üks võib olla õige, teine aga vale.

Kontrollige neid selles järjekorras ja lõpetage esimese mittevastavuse juures, sest hilisemad kontrollid eeldavad, et varasemad on läbitud.

Esiteks, milline väärtus on aadress

Ühenduse aadress on sõltumata sellest, mida klient valib: IP, DNS nimi, mis lahendatakse üheks või tasakaalustatud koormusega esiots. See on transporditeave ja ei midagi muud. Identiteet liigub IKEv2 ID kasulikus koormuses ja seejärel võrreldakse seda kaaslase sertifikaadiga. Aadressikastis olev DNS nimi ei muutu eeldatavaks identiteediks ja töötlemata IP-st ei saa identiteeti ainult seetõttu, et pesa on sellega ühendatud.

strongSwan terminites on aadress right või left ja eeldatav identiteet on rightid või leftid ning seda kirjeldab IKEv2 konfiguratsioonidokumentatsioon. Kui olete ainult aadressi muutnud, olete poole paarist konfigureerinud.

Teiseks, mida sertifikaat suudab tõestada

Identiteedil on tüüp ja sertifikaadil peab olema sobiv nimi. DNS identiteet on rahuldatud dNSName kirjega subjekti alternatiivses nimelaiendis; IP-identiteet vajab iPAddress kirjet. vpn.example.com kohta väljastatud sertifikaat ei tõenda midagi otsese aadressi 203.0.113.10 kohta ja selle aadressi jaoks välja antud sertifikaat ei tõenda midagi nime kohta. Teistsuguse nime uuesti väljastamine ei ole seega asendamine, isegi kui sama võtit ja CA kasutatakse uuesti.

Kaasaegsed kliendid ignoreerivad üldnimetust, kui subjekti alternatiivne nimi on olemas, ja paljud ignoreerivad seda täielikult. Kui loendis SAN ei ole väärtust, mida klient kontrollib, nurjub käepigistus pärast seda, kui sertifikaat on juba usaldusväärseks tunnistatud, mistõttu loetakse logi pigem identiteedi veana kui usaldusveana.

Kolmandaks, kuidas iga klient oma ootusi väljendab

Windows võtab teie sisestatud serveri nime või aadressi ja nõuab, et sertifikaat vastaks sellele, nii et IP-aadressi sisestamine loob IP-ootuse. Androidi IKEv2 klient käitub samamoodi ja mõlemad lükkavad tagasi kehtiva, avalikult usaldusväärse sertifikaadi, mis nimetab erinevat hosti. Profiil võib hakata ebaõnnestuma ainuüksi seetõttu, et keegi asendas hostinime migreerimise ajal selle aadressiga. Vaadake, mida klient küsis, enne kui vaatate, mida sertifikaat sisaldab.

strongSwan puhul on ootus selge: määrake rightid identiteediks, mida server tegelikult esitab, mis võib erineda õigest. Kui määrate selle väärtusele %any, võetakse vastu kõik, mida partner pakub, ja eemaldatakse täpselt see tšekk, mida proovite hoida.

Neljandaks eraldage kasutaja sisselogimine kaaslaste identiteedist

EAP autentimine ja serveri identiteet vastavad erinevatele küsimustele. EAP identiteet, näiteks [email protected], ütleb, kes on kasutaja, kui klient on otsustanud, et server on õige. Selle parooli pööramine ei saa kaaslaste identiteedi mittevastavust parandada, kuna ühendus ei jõua kunagi kasutaja sisselogimisfaasi.

Puhastatud aruanne peaks nimetama mõlemad: kliendi oodatud identiteet, serveri esitatud identiteet ja sertifikaadi SAN kirjed.

Viiendaks muutke seda kinnitatud kanali kaudu

Kui lüüs seaduspäraselt liigub, värskendage esmalt aadressi ja jätke identiteet rahule, sest see on nii IKEv2 käsitleb hästi. Kui identiteet ise muutub, käsitlege seda usaldussündmusena ja hankige uus väärtus allikast, mida juba usaldate, mitte lõpp-punktist, mis praegu ebaõnnestub. Ühenduse kaudu, mida proovite kinnitada, edastatud sõnum ei ole selle ühenduse tõend.

Salvestage lõplik aadress, identiteet ja SAN nimekiri koos profiilimärkmetesse. Järgmine inimene, kes sertifikaati puudutab, näeb seejärel, kummal neist kolmest on lubatud liikuda.