Hoe IKEv1 se hibriede stawing by IKEv2 se gebruikersverifikasie aansluit

Elke ou VPN-profiel wat eers ’n bediener-sertifikaat en dan ’n gebruikersnaam vra, dra twee verifikasiegebeurtenisse binne een uitruiling, en daardie vorm oorleef die protokol wat dit ingebring het. Die IKEv1 hibriede modus is juis hiervoor gebou: die gateway bewys homself met ’n publieke sleutel terwyl die gebruiker hom later deur XAuth bewys. IKEv2 druk dieselfde twee-stap-idee met ander meganisme uit, en dit is in daardie verskille waar migrasies misluk. Geen weergawenommer skakel die een na die ander om nie, en om die ou opsiename na ’n nuwe profiel te kopieer lewer ’n kliënt wat onderhandel en dan niks verifieer nie.

Wat die hibriede modus in IKEv1 gedoen het

In ’n hibriede profiel onderteken die responder die fase-een-uitruiling met sy sertifikaat terwyl die initiator doelbewus geen aanbied nie. Die identiteitsbewys is dus asimmetries, en dit is wat ’n gateway in staat gestel het om sy bestaande PKI te hou terwyl gebruikers hul gids-wagwoorde gehou het. Sodra fase een voltooi is, loop XAuth as ’n versoek en antwoord wat gebruikersnaam- en wagwoordkenmerke binne die nou-geënkripteerde ISAKMP-kanaal dra.

Let op waar die vertroue beland. Die sertifikaat antwoord watter gateway die kliënt bereik het; XAuth antwoord watter gebruiker toegang wil. Nie een vervang die ander nie, en ’n kliënt wat enige bediener-sertifikaat aanvaar, het die eerste antwoord stilweg weggegooi. Die etiket hibried word ook vir aggressive mode met pre-shared key plus XAuth gebruik, ’n ander reëling met dieselfde gebruikerservaring, so lees die profiel eerder as die naam. Albei variante kom uit konsepte wat nooit standaarde geword het nie, en daarom kan twee verskaffers hibriede modus implementeer en met nie een interopereer nie.

Hoe IKEv2 by dieselfde twee bewyse uitkom

IKEv2 verdeel die werk oor IKE_SA_INIT en IKE_AUTH. Die eerste uitruiling onderhandel voorstelle en sleutels sonder enige identiteit; die tweede dra IDi, IDr en die AUTH-vragte. Onder EAP gaan die initiator se eerste AUTH-vrag leeg uit, die responder verifieer hom eerste met sy sertifikaat en handtekening, en daarna loop die EAP-gesprek binne die IKE_AUTH-boodskappe.

Die meganisme wat dit veilig maak, is sleutelmateriaal. ’n Suksesvolle EAP-metode voer ’n sessiesleutel uit, en die initiator se finale AUTH-vrag word daaruit bereken, sodat die gebruiker se bewys en die tonnel se sleutels aan mekaar gebind is. XAuth het geen ekwivalent nie: sy kenmerke kom ná fase een en dra niks tot die sleutels by nie. Daardie gaping is presies wat die IKEv2-raamwerk ontwerp is om te sluit, en daarom valideer ’n werkende IKEv2-aanmelding die bediener-sertifikaat voordat dit enigiets vra.

Hierdie volgorde is ook ’n nuttige diagnose. Wanneer ’n kliënt oor aanmeldingsgegewens kla voordat hy jou ’n sertifikaat gewys het, doen hy glad nie ’n IKEv2 EAP-uitruiling nie.

Hou drie identiteite apart

’n Migrasie loop verkeerd wanneer drie identiteite in een veld ineenstort. Daar is die gateway-identiteit wat die kliënt valideer, gewoonlik ’n DNS-naam in die sertifikaat se subject of SAN. Daar is die gebruikersidentiteit wat in EAP aangebied word, miskien ’n domeinaanmelding, ’n adres of ’n eksplisiete EAP-identiteitsstring. En daar is die magtigingsbron wat daardie gebruiker op netwerke en roetes afbeeld.

Die swanctl-sintaksis van strongSwan maak die skeiding sigbaar: die verbinding stel remote { auth = pubkey } vir die gateway en local { auth = eap-mschapv2 } vir die gebruiker, met die EAP-identiteit apart gedra.

Wanneer die gebruikersidentiteit in die nuwe profiel van die ou XAuth-kenmerke verskil, byvoorbeeld ’n UPN eerder as ’n kort naam, sien die verifikasi-bediener ’n onbekende gebruiker en lyk die fout na ’n verkeerde wagwoord. Kontroleer die identiteitsstring voordat jy die aanmeldingsgegewens kontroleer.

Karteer die opsies en verwag dan die strikke

Die kartering is kort en elke ry het ’n strik wat eers by verifikasie opduik.

Nie een van daardie rye is ’n blote hernoeming nie. Die konfigurasie-vrag lewer adresse en oplossers deur ’n getipeerde kenmerklys, terwyl XAuth se kenmerkruimte sy eie uitvinding was; om hulle as uitruilbaar te behandel, is hoe ’n profiel uiteindelik om ’n instelling vra wat die gateway nooit sal stuur nie.

Verkeerskeurders verdien hul eie waarskuwing. IKEv1 het interessante verkeer deur proxy-ID’s uitgedruk wat aan ’n quick-mode-uitruiling gebind was, terwyl IKEv2 die keurders tydens IKE_AUTH onderhandel en die responder dit mag vernou. ’n Wanpassing lewer ’n gevestigde IKE SA sonder child SA, wat sommige kliënte vrolik as verbind vertoon.

Behandel die ou verbinding as ’n grens

RFC 9395 verklaar IKEv1 verouderd, so ’n ou hibriede verbinding is ’n versoenbaarheidsgrens met ’n datum, nie ’n fondament nie. Laat beide profiele langs mekaar loop tydens die oorskakeling, want die toets wat saak maak is nie of die nuwe profiel opkom nie, maar of dieselfde gebruiker op dieselfde toestel dieselfde hulpbronne bereik.

Hou sertifikaatvalidering deurgaans streng. Sodra die kliënt ophou om sy eie sertifikaat aan te bied, is die versoeking om die bedienerkontrole te verslap tot die handshake deurkom, en dit ruil die enigste oorblywende bewys vir ’n groen ikoon.

Skryf vier dinge neer voordat jy die ou profiel aftree: die EAP-metode, die identiteitsstring, die magtigingsbron en die datum waarop ondersteuning eindig.