Hvernig blendingaaðkenning IKEv1 færist yfir í notendaaðkenningu IKEv2
Blendingurinn skildi sönnun gáttarinnar frá sönnun notandans. Flutningurinn yfir í IKEv2 heldur þeirri skiptingu en breytir samskiptunum, EAP-aðferðinni og athugun vottorðsins.
Sérhvert gamalt VPN-snið sem biður fyrst um netþjónsvottorð og svo um notendanafn ber tvö auðkenningaratvik innan eins skiptis, og sú mynd lifir lengur en siðvenjan sem kom henni á. Blendingur IKEv1 var byggður einmitt fyrir þetta: gáttin sannar sig með opinberum lykli á meðan notandinn sannar sig síðar með XAuth. IKEv2 lýsir sömu tveggja þrepa hugmynd með annarri tækni, og það er í þeim mun að flutningur mistekst. Ekkert útgáfunúmer breytir öðru í hitt, og að afrita gömlu valheiti yfir í nýtt snið gefur biðlara sem semur og auðkennir svo ekkert.
Hvað blendingurinn gerði inni í IKEv1
Í blendingi undirritar svarendinn fyrsta fasa skiptingarinnar með vottorði sínu á meðan frumkvæðið sýnir ekkert viljandi. Sönnunin á auðkenni er því ósamhverf, og það leyfði gátt að halda núverandi PKI á meðan notendur héldu lykilorðum sínum í skrá. Þegar fyrsta fasa lýkur keyrir XAuth sem beiðni og svar sem ber notendanafns- og lykilorðseiginleika inni í nú dulkóðuðu ISAKMP-rásinni.
Taktu eftir því hvar traustið lendir. Vottorðið svarar því hvaða gátt biðlarinn náði; XAuth svarar því hvaða notandi vill aðgang. Hvort tveggja kemur ekki í stað hins, og biðlari sem stilltur er til að samþykkja hvaða netþjónsvottorð sem er hefur hljóðlega hent fyrsta svarinu. Merkið blendingur er einnig notað um aggressive mode með fyrirfram deildum lykli auk XAuth, önnur skipan með sömu notendaupplifun, svo lestu sniðið en ekki nafnið. Báðar útgáfurnar koma úr drögum sem urðu aldrei staðlar, og þess vegna geta tveir framleiðendur útfært blending og samvirkjað ekki með hvorugum.
Hvernig IKEv2 nær sömu tveimur sönnunum
IKEv2 skiptir vinnunni á milli IKE_SA_INIT og IKE_AUTH. Fyrsta skiptingin semur tillögur og lykla alveg án auðkenna; önnur ber IDi, IDr og AUTH-farmana. Undir EAP fer fyrsti AUTH-farmur frumkvæðisins út tómur, svarendinn auðkennir sig fyrst með vottorði og undirskrift, og síðan gengur EAP-samtalið inni í IKE_AUTH-skilaboðunum.
Fyrirkomulagið sem gerir þetta öruggt er lykliefni. Árangursrík EAP-aðferð flytur út lotulykil, og lokafarmur AUTH hjá frumkvæðinu er reiknaður út frá honum, svo sönnun notandans og lyklar göngunnar eru bundnir saman. XAuth hefur ekkert samsvarandi: eiginleikar þess koma eftir fyrsta fasa og leggja ekkert til lyklanna. Það bil er einmitt það sem ramma IKEv2 var ætlað að loka, og þess vegna staðfestir vinnandi IKEv2-innskráning netþjónsvottorðið áður en hún biður um nokkuð.
Þessi röð er líka gagnleg greining. Þegar biðlari kvartar yfir skilríkjum áður en hann hefur sýnt þér vottorð er hann alls ekki í IKEv2 EAP-skiptingu.
Haltu þremur auðkennum aðskildum
Flutningur fer úrskeiðis þegar þrjú auðkenni falla saman í einn reit. Það er auðkenni gáttarinnar sem biðlarinn staðfestir, venjulega DNS-nafn í subject eða SAN vottorðsins. Það er auðkenni notandans sem kynnt er í EAP, kannski lénsinnskráning, netfang eða skýr EAP-auðkennisstrengur. Og það er heimildaruppsprettan sem varpar þeim notanda á net og leiðir.
swanctl-málfræði strongSwan gerir skiptinguna sýnilega: tengingin stillir remote { auth = pubkey } fyrir gáttina og local { auth = eap-mschapv2 } fyrir notandann, með EAP-auðkennið borið sér.
Þegar auðkenni notandans í nýja sniðinu er frábrugðið gömlu XAuth-eiginleikunum, til dæmis UPN í stað stutts nafns, sér auðkenningarþjónninn óþekktan notanda og bilunin lítur út eins og rangt lykilorð. Athugaðu auðkennisstrenginn áður en þú athugar skilríkin.
Kortleggðu valkostina og búðu þig undir gildrurnar
Kortlagningin er stutt og hver röð hefur gildru sem kemur aðeins fram við auðkenningu.
| 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 |
Engin þessara raða er einfalt nafnabreyting. Stillingarfarmurinn skilar vistföngum og leysum í gegnum flokkaðan eiginleikalista, á meðan eiginleikarúm XAuth var eigin uppfinning; að meðhöndla þau sem skiptanleg er hvernig snið endar með að biðja um stillingu sem gáttin mun aldrei senda.
Umferðarvalar eiga skilið eigin viðvörun. IKEv1 lýsti áhugaverðri umferð með proxy-ID sem bundin voru quick-mode-skiptingu, á meðan IKEv2 semur valana meðan á IKE_AUTH stendur og svarendinn má þrengja þá. Ósamræmi framleiðir uppsetta IKE SA án child SA, sem sumir biðlarar sýna glaðir sem tengda.
Líttu á gömlu tenginguna sem landamæri
RFC 9395 úreldir IKEv1, svo gömul blendingstenging er samhæfnislandamæri með dagsetningu, ekki grunnur. Keyrðu bæði sniðin hlið við hlið meðan á breytingunni stendur, því prófið sem skiptir máli er ekki hvort nýja sniðið kemur upp heldur hvort sami notandi á sama tæki nái sömu auðlindum.
Haltu staðfestingu vottorða strangri alla leið. Þegar biðlarinn hættir að sýna eigið vottorð er freistingin að slaka á netþjónsathuguninni þar til handabandið gengur í gegn, og það skiptir eina eftirverandi sönnuninni út fyrir græna táknmynd.
Skrifaðu niður fjóra hluti áður en þú leggur gamla sniðið af: EAP-aðferðina, auðkennisstrenginn, heimildaruppsprettuna og dagsetninguna sem stuðningur endar.