Kako se hibridna autentifikacija IKEv1 preslikava u IKEv2 autentifikaciju korisnika
Hibridni režim razdvajao je dokaz pristupnika od dokaza korisnika. Prelazak na IKEv2 zadržava tu podjelu, ali mijenja razmjenu, EAP metodu i provjere certifikata.
Svaki stari VPN profil koji prvo traži certifikat servera pa korisničko ime nosi dva događaja autentifikacije u jednoj razmjeni, a taj oblik nadživljava protokol koji ga je uveo. Hibridni režim IKEv1 napravljen je upravo za to: pristupnik se dokazuje javnim ključem, a korisnik se dokazuje kasnije preko XAuth. IKEv2 izražava istu dvostepenu ideju drugim mehanizmom, i upravo u tim razlikama migracije propadaju. Nijedan broj verzije ne pretvara jedno u drugo, a kopiranje starih naziva opcija u novi profil daje klijenta koji pregovara i zatim ništa ne autentificira.
Šta je hibridni režim radio unutar IKEv1
U hibridnom profilu odgovarač potpisuje razmjenu prve faze svojim certifikatom, dok inicijator namjerno ne predstavlja nijedan. Dokaz identiteta je dakle asimetričan, i to je omogućilo pristupniku da zadrži postojeći PKI, a korisnicima njihove direktorijske lozinke. Kada prva faza završi, XAuth se izvršava kao zahtjev i odgovor koji nose atribute korisničkog imena i lozinke unutar već šifrovanog ISAKMP kanala.
Obratite pažnju gdje završava povjerenje. Certifikat odgovara na koje je pristupnik klijent stigao; XAuth odgovara koji korisnik želi pristup. Nijedno ne zamjenjuje drugo, a klijent podešen da prihvati bilo koji certifikat servera tiho je odbacio prvi odgovor. Oznaka hibridni koristi se i za agresivni režim s unaprijed podijeljenim ključem plus XAuth, drugačiji raspored s istim korisničkim iskustvom, pa čitajte profil, a ne naziv. Obje varijante potječu iz nacrta koji nikada nisu postali standardi, i zato dva proizvođača mogu implementirati hibridni režim i ne sarađivati ni s jednim.
Kako IKEv2 dolazi do ista dva dokaza
IKEv2 dijeli posao između IKE_SA_INIT i IKE_AUTH. Prva razmjena dogovara prijedloge i ključeve potpuno bez identiteta; druga nosi IDi, IDr i AUTH terete. Pod EAP prvi AUTH teret inicijatora izlazi prazan, odgovarač se prvo autentificira certifikatom i potpisom, a zatim razgovor EAP teče unutar IKE_AUTH poruka.
Mehanizam koji to čini sigurnim je ključni materijal. Uspješna EAP metoda izvozi sesijski ključ, a završni AUTH teret inicijatora izračunava se iz njega, pa su dokaz korisnika i ključevi tunela vezani. XAuth nema ekvivalent: njegovi atributi dolaze poslije prve faze i ničemu ne doprinose kod ključeva. Upravo tu prazninu okvir IKEv2 je dizajniran zatvoriti, i zato funkcionalna IKEv2 prijava provjerava certifikat servera prije nego što bilo šta zatraži.
Taj redoslijed je i korisna dijagnostika. Kada se klijent žali na akreditive prije nego što vam je pokazao certifikat, on uopšte ne izvodi IKEv2 EAP razmjenu.
Držite tri identiteta odvojeno
Migracija krene po zlu kada se tri identiteta sliju u jedno polje. Tu je identitet pristupnika koji klijent provjerava, obično DNS ime u subject ili SAN certifikata. Tu je identitet korisnika predstavljen u EAP, možda domenska prijava, adresa ili izričit EAP identitetski niz. I tu je izvor autorizacije koji tog korisnika preslikava na mreže i rute.
strongSwan swanctl sintaksa čini podjelu vidljivom: veza postavlja remote { auth = pubkey } za pristupnik i local { auth = eap-mschapv2 } za korisnika, a EAP identitet se nosi odvojeno.
Kada se identitet korisnika u novom profilu razlikuje od starih XAuth atributa, na primjer UPN umjesto kratkog imena, server za autentifikaciju vidi nepoznatog korisnika i kvar izgleda kao pogrešna lozinka. Provjerite identitetski niz prije nego što provjerite akreditive.
Preslikajte opcije, a zatim očekujte zamke
Preslikavanje je kratko i svaki red ima zamku koja se pojavljuje tek pri autentifikaciji.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
Nijedan od tih redova nije puko preimenovanje. Konfiguracijski teret isporučuje adrese i rezolvere kroz tipiziranu listu atributa, dok je XAuth prostor atributa bio vlastiti izum; tretirati ih kao zamjenjive jeste način na koji profil završi tražeći postavku koju pristupnik nikada neće poslati.
Selektori saobraćaja zaslužuju vlastito upozorenje. IKEv1 je izražavao zanimljiv saobraćaj preko proxy ID-a vezanih za quick mode razmjenu, dok IKEv2 pregovara selektore tokom IKE_AUTH i odgovarač ih može suziti. Nesklad stvara uspostavljen IKE SA bez child SA, koji neki klijenti veselo prikazuju kao povezan.
Tretirajte staru vezu kao granicu
RFC 9395 označava IKEv1 zastarjelim, pa je stara hibridna veza granica kompatibilnosti s datumom, a ne temelj. Pokrenite oba profila uporedo tokom promjene, jer test koji je bitan nije da li se novi profil diže, nego da li isti korisnik na istom uređaju dolazi do istih resursa.
Držite provjeru certifikata strogom cijelo vrijeme. Kada klijent prestane predstavljati vlastiti certifikat, iskušenje je ublažiti provjeru servera dok se handshake ne završi, a to mijenja jedini preostali dokaz za zelenu ikonu.
Zapišite četiri stvari prije nego što umirovite stari profil: EAP metodu, identitetski niz, izvor autorizacije i datum kada podrška prestaje.