IKEv2 adresa poslužitelja nasuprot identitetu: što klijent zapravo provjerava

Gateway koji promijeni adresu može nastaviti raditi dok se isti gateway iza novog certifikata zaustavlja, a događa se i obrnuto. Adresa govori klijentu gdje treba poslati pakete; autentificirani identitet govori klijentu je li vršnjak koji odgovara onaj kojem treba vjerovati. IKEv2 ih čuva kao dva odvojena polja, što je korisno nakon što ih prestanete tretirati kao jedan niz. Također su konfigurirani na različitim mjestima, tako da jedan može biti točan, a drugi pogrešan.

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

Prvo, koja vrijednost je adresa

Adresa veze je ono što klijent bira: IP, DNS ime koje se razrješava na jedan ili pristupni kraj s uravnoteženim opterećenjem. To je informacija o prijevozu i ništa više. Identitet se nalazi u IKEv2 ID korisnom opterećenju i zatim se uspoređuje s ravnopravnim certifikatom. Ime DNS u adresnom okviru ne postaje očekivani identitet, a neobrađeni IP ne postaje identitet samo zato što je utičnica spojena na njega.

U terminima 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, konfigurirali ste pola para.

Drugo, što potvrda može dokazati

Identitet ima vrstu, a certifikat mora nositi odgovarajuće ime. DNS identitet je zadovoljen unosom dNSName u alternativnom proširenju naziva subjekta; IP identitet treba iPAddress unos. Potvrda izdana za vpn.example.com ne dokazuje ništa o doslovnoj adresi 203.0.113.10, a ona izdana za tu adresu ne dokazuje ništa o imenu. Ponovno izdavanje za drugo ime stoga nije zamjena bez dodavanja, čak ni kada se ponovno koriste isti ključ i CA.

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

Treće, kako svaki klijent iznosi očekivanja

Windows uzima naziv poslužitelja ili adresu koju ste upisali i zahtijeva certifikat da mu odgovara, tako da upisivanje IP-a stvara očekivani IP. Android-ov IKEv2 klijent ponaša se na isti način i oba odbijaju važeći, javno pouzdani certifikat koji imenuje drugo glavno računalo. Profil može početi padati samo zato što je netko zamijenio naziv hosta njegovom adresom tijekom migracije. Pogledajte što je klijent tražio prije nego što pogledate što certifikat sadrži.

Na strongSwan očekivanje je eksplicitno: postavite rightid na identitet koji poslužitelj stvarno predstavlja, a koji se može razlikovati od desnog. Postavljanje na %any prihvaća sve što vršnjak ponudi i uklanja točno onaj ček koji pokušavate zadržati.

Četvrto, odvojite korisničku prijavu od peer identiteta

EAP provjera autentičnosti i identitet poslužitelja odgovaraju na različita pitanja. EAP identitet kao što je [email protected] govori tko je korisnik, nakon što klijent odluči da je poslužitelj pravi. Rotiranje te lozinke ne može popraviti neusklađenost peer identiteta, jer veza nikada ne dosegne fazu prijave korisnika.

Pročišćeno izvješće treba imenovati oboje: identitet koji je klijent očekivao, identitet koji je prikazao poslužitelj i SAN unose certifikata.

Peto, promijenite ga putem provjerenog kanala

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

Zabilježite konačnu adresu, identitet i SAN popis zajedno u bilješkama profila. Sljedeća osoba koja dotakne certifikat tada će vidjeti kome od njih tri je dopušteno pomicanje.