IKEv2 serverio adresas ir tapatybė: ką klientas iš tikrųjų tikrina

Šliuzas, kuris keičia adresą, gali toliau veikti, kol sustoja tie patys šliuzai, esantys už naujo sertifikato, ir atsitinka atvirkščiai. Adresas nurodo klientui, kur siųsti paketus; autentifikuota tapatybė nurodo klientui, ar atsakantis partneris yra tas, kuriuo jis turėtų pasitikėti. IKEv2 išsaugo juos kaip du atskirus laukus, o tai naudinga, kai nustosite juos laikyti viena eilute. Jie taip pat sukonfigūruoti skirtingose vietose, todėl vienas gali būti teisingas, o kitas neteisingas.

Patikrinkite juos tokia tvarka ir sustokite ties pirmuoju neatitikimu, nes vėlesniuose patikrinimuose daroma prielaida, kad ankstesni patikrinimai buvo sėkmingi.

Pirma, kuri reikšmė yra adresas

Ryšio adresas yra tai, ką klientas renka: IP, DNS pavadinimas, kuris išsprendžiamas į vieną, arba subalansuota apkrova. Tai yra transporto informacija ir nieko daugiau. Tapatybė patenka į IKEv2 ID naudingąją apkrovą ir tada sulyginama su lygiaverčio asmens sertifikatu. DNS vardas adreso laukelyje netampa laukiama tapatybe, o neapdorotas IP netampa tapatybe tik todėl, kad prie jo prijungtas lizdas.

Kalbant strongSwan, adresas yra right arba left, o numatoma tapatybė yra rightid arba leftid, ir tai aprašyta IKEv2 konfigūracijos dokumentacijoje. Jei kada nors redagavote tik adresą, sukonfigūravote pusę poros.

Antra, ką gali įrodyti sertifikatas

Tapatybė turi tipą, o sertifikate turi būti atitinkamas pavadinimas. DNS tapatybę patenkina dNSName įrašas dalyko alternatyvaus vardo plėtinyje; IP tapatybei reikia iPAddress įrašo. vpn.example.com išduota pažyma nieko neįrodo pažodinio adreso 203.0.113.10, o išduota tam adresui nieko neįrodo apie vardą. Todėl pakartotinis išdavimas naudojant kitą pavadinimą nėra pakeitimas, net jei tas pats raktas ir CA naudojami pakartotinai.

Šiuolaikiniai klientai ignoruoja bendrą pavadinimą, kai egzistuoja alternatyvus subjekto pavadinimas, o daugelis ignoruoja jį visiškai. Jei SAN sąraše nėra kliento tikrinamos vertės, po to, kai sertifikatas jau buvo priimtas kaip patikimas, rankos paspaudimas nepavyksta, todėl žurnalas skaitomas kaip tapatybės klaida, o ne pasitikėjimo klaida.

Trečia, kaip kiekvienas klientas išreiškia lūkesčius

Windows paima jūsų įvestą serverio pavadinimą arba adresą ir reikalauja, kad sertifikatas atitiktų jį, todėl įvedus IP sukuriamas IP lūkestis. Android IKEv2 klientas elgiasi taip pat ir abu atmeta galiojantį, viešai patikimą sertifikatą, įvardijantį skirtingą pagrindinį kompiuterį. Profilis gali sugesti vien dėl to, kad perkėlimo metu kas nors pakeitė pagrindinio kompiuterio pavadinimą savo adresu. Prieš žiūrėdami, kas yra sertifikate, pažiūrėkite, ko klientas paprašė.

strongSwan lūkestis yra aiškus: nustatykite rightid tapatybę, kurią iš tikrųjų pateikia serveris, kuri gali skirtis nuo teisingos. Nustačius jį į %any, priimami visi partnerio pasiūlymai ir pašalinamas būtent tas čekis, kurį bandote išlaikyti.

Ketvirta, atskirkite vartotojo prisijungimą nuo bendraamžių tapatybės

EAP autentifikavimas ir serverio tapatybė atsako į skirtingus klausimus. EAP tapatybė, pvz,, [email protected], nurodo, kas yra vartotojas, klientui nusprendus, kad serveris yra tinkamas. Sukant šį slaptažodį nepavyks ištaisyti partnerio tapatybės neatitikimo, nes ryšys niekada nepasiekia vartotojo prisijungimo etapo.

Išvalytoje ataskaitoje turi būti nurodyti abu: tapatybė, kurios tikėjosi klientas, tapatybė, kurią pateikė serveris, ir sertifikato SAN įrašai.

Penkta, pakeiskite jį per patvirtintą kanalą

Kai šliuzas teisėtai juda, pirmiausia atnaujinkite adresą ir palikite tapatybę ramybėje, nes tokiu atveju IKEv2 veikia gerai. Kai pasikeičia pati tapatybė, traktuokite ją kaip pasitikėjimo įvykį ir gaukite naują vertę iš šaltinio, kuriuo jau pasitikite, o ne iš galutinio taško, kuris šiuo metu neveikia. Pranešimas, pristatytas per ryšį, kurį bandote patvirtinti, nėra to ryšio įrodymas.

Įrašykite galutinį adresą, tapatybę ir SAN sąrašą kartu į profilio pastabas. Kitas asmuo, kuris palies sertifikatą, pamatys, kuriam iš trijų leidžiama judėti.