IKEv2 adresa servera naspram identiteta: šta klijent zapravo provjerava

Gateway koji mijenja adresu može nastaviti raditi dok se isti gateway iza novog certifikata zaustavlja, a dešava se i obrnuto. Adresa govori klijentu gdje da pošalje pakete; autentificirani identitet govori klijentu da li je kolega koji odgovara onaj kome treba vjerovati. IKEv2 ih čuva kao dva odvojena polja, što je korisno kada prestanete da ih tretirate kao jedan niz. Također su konfigurirani na različitim mjestima, tako da jedno može biti ispravno, a drugo pogrešno.

Provjerite ih ovim redoslijedom i zaustavite se na prvom neslaganju, jer kasnije provjere pretpostavljaju da su prošle prošle.

Prvo, koja je vrijednost adresa

Adresa veze je ono što klijent bira: IP, DNS ime koje se razrješava na jedan, ili front end s balansiranim opterećenjem. To su informacije o transportu i ništa više. Identitet se nalazi u IKEv2 ID korisnom učitavanju i zatim se uparuje sa sertifikatom ravnopravnog partnera. Ime DNS u adresnom polju ne postaje očekivani identitet, a sirova IP adresa ne postaje identitet samo zato što je soket povezan na njega.

U smislu strongSwan, adresa je right ili left, a očekivani identitet je rightid ili leftid, a to je ono što IKEv2 konfiguracijska dokumentacija opisuje. Ako ste ikada uređivali samo adresu, konfigurisali ste polovinu para.

Drugo, šta sertifikat može dokazati

Identitet ima tip, a certifikat mora nositi odgovarajuće ime. Identitet DNS je zadovoljen unosom dNSName u proširenju alternativnog imena subjekta; IP identitet treba unos iPAddress. Certifikat izdat za vpn.example.com ne dokazuje ništa o doslovnoj adresi 203.0.113.10, a certifikat izdat za tu adresu ne dokazuje ništa o imenu. Ponovno izdavanje za drugo ime stoga nije zamjenska zamjena, čak i kada se isti ključ i CA ponovo koriste.

Moderni klijenti zanemaruju uobičajeno ime kada postoji alternativno ime subjekta, a mnogi ga potpuno ignorišu. Ako SAN lista ne sadrži vrijednost koju klijent provjerava, rukovanje ne uspijeva nakon što je certifikat već prihvaćen kao pouzdan, zbog čega se dnevnik čita kao greška identiteta, a ne kao greška povjerenja.

Treće, kako svaki klijent izražava očekivanja

Windows uzima ime servera ili adresu koju ste upisali i zahtijeva da certifikat odgovara njima, tako da upisivanje IP-a stvara očekivanje IP-a. Klijent Android IKEv2 se ponaša na isti način, i oba odbijaju važeći, javno pouzdani certifikat koji imenuje drugi host. Profil može početi da ne uspijeva samo zato što je neko zamijenio ime hosta njegovom adresom tokom migracije. Pogledajte šta je klijent tražio pre nego što pogledate šta sertifikat sadrži.

Na strongSwan očekivanje je eksplicitno: postavite rightid na identitet koji server zapravo predstavlja, a koji se može razlikovati od desnog. Postavljanjem na %any prihvata se sve što kolega ponudi i uklanja upravo ček koji pokušavate zadržati.

Četvrto, odvojite prijavu korisnika od istovrsnog identiteta

EAP autentifikacija i identitet servera odgovaraju na različita pitanja. EAP identitet kao što je [email protected] govori ko je korisnik, nakon što klijent odluči da je server pravi. Rotiranje te lozinke ne može popraviti nepodudarnost istovrsnog identiteta, jer veza nikada ne doseže fazu prijave korisnika.

Pročišćeni izvještaj bi trebao imenovati oba: identitet koji je klijent očekivao, identitet koji je server predstavio i SAN unose certifikata.

Peto, promijenite ga putem provjerenog kanala

Kada se gateway legitimno pomjeri, prvo ažurirajte adresu i ostavite identitet na miru, jer se u tom slučaju IKEv2 dobro snalazi. Kada se sam identitet promijeni, tretirajte ga kao događaj povjerenja i preuzmite novu vrijednost iz izvora kojem već vjerujete, a ne iz krajnje točke koja trenutno ne uspijeva. Poruka isporučena preko veze koju pokušavate potvrditi nije dokaz o toj vezi.

Zabilježite konačnu adresu, identitet i SAN listu zajedno u napomenama o profilu. Sljedeća osoba koja dodirne certifikat će tada vidjeti kome je od njih troje dozvoljeno da se kreće.