IKEv1 හි හයිබ්‍රිඩ් සත්‍යාපනය IKEv2 හි පරිශීලක සත්‍යාපනයට මාරු වන්නේ කෙසේද
හයිබ්‍රිඩ් මාදිලිය ගේට්වේ සාක්ෂිය පරිශීලක සාක්ෂියෙන් වෙන් කළේය. IKEv2 වෙත මාරු වන විට එම වෙන්වීම රැඳී පවතී, නමුත් හුවමාරුව, EAP ක්‍රමය සහ සහතික පරීක්ෂාවන් වෙනස් වේ.
පළමුව සේවාදායක සහතිකය සහ පසුව පරිශීලක නාමය ඉල්ලන සෑම පැරණි VPN පැතිකඩක්ම එකම හුවමාරුවක් තුළ සත්‍යාපන සිදුවීම් දෙකක් දරයි, මෙම හැඩය එය ගෙන ආ ප්‍රොටෝකෝලයට වඩා දිගු කලක් ජීවත් වේ. IKEv1 හි හයිබ්‍රිඩ් මාදිලිය හරියටම මේ සඳහා ගොඩනගන ලදී: ගේට්වේ තමා පොදු යතුරකින් සනාථ කරයි, පරිශීලකයා පසුව XAuth හරහා තමා සනාථ කරයි. IKEv2 එම පියවර දෙකේ අදහස වෙනත් යාන්ත්‍රණයකින් ප්‍රකාශ කරයි, මෙම වෙනස්කම් තුළම සංක්‍රමණ අසාර්ථක වේ. කිසිදු අනුවාද අංකයක් එකක් අනෙක බවට නොහරවයි, පැරණි විකල්ප නම් නව පැතිකඩකට පිටපත් කිරීම සාකච්ඡා කර පසුව කිසිවක් සත්‍යාපනය නොකරන සේවාලාභියෙකු ලබා දෙයි.
හයිබ්‍රිඩ් මාදිලිය IKEv1 තුළ කුමක් කළේද
හයිබ්‍රිඩ් පැතිකඩක ප්‍රතිචාර දක්වන පාර්ශවය පළමු අවස්ථා හුවමාරුව තම සහතිකයෙන් අත්සන් කරයි, ආරම්භකයා හිතාමතාම කිසිදු සහතිකයක් නොපෙන්වයි. එබැවින් අනන්‍යතා සාක්ෂිය අසමමිතිකය, මෙයයි ගේට්වේට එහි පවතින PKI රඳවා ගැනීමටත් පරිශීලකයන්ට ඔවුන්ගේ නාමාවලි මුරපද රඳවා ගැනීමටත් ඉඩ දුන්නේ. පළමු අවස්ථාව අවසන් වූ පසු XAuth ඉල්ලීමක් සහ පිළිතුරක් ලෙස ක්රියා කරයි, ඒවා දැන් සංකේතනය කළ ISAKMP නාලිකාව තුළ පරිශීලක නාමය සහ මුරපද ගුණාංග දරයි.
විශ්වාසය පතිත වන්නේ කොහේදැයි සැලකිල්ලට ගන්න. සහතිකය පිළිතුරු දෙන්නේ සේවාලාභියා කුමන ගේට්වේ වෙත ළඟා වුණේද යන්නයි; XAuth පිළිතුරු දෙන්නේ කුමන පරිශීලකයාට ප්‍රවේශය අවශ්‍යද යන්නයි. එකක් අනෙකට ආදේශ නොවේ, ඕනෑම සේවාදායක සහතිකයක් පිළිගැනීමට සකසන ලද සේවාලාභියා පළමු පිළිතුර නිහඬව ඉවත දමා ඇත. හයිබ්‍රිඩ් යන ලේබලය කලින් බෙදාගත් යතුර සහිත ආක්‍රමණකාරී මාදිලියට සහ XAuth ටද භාවිත වේ, එය එම පරිශීලක අත්දැකීමම ඇති වෙනත් සැකැස්මකි, එබැවින් නම නොව පැතිකඩ කියවන්න. දෙකම කිසිදා ප්‍රමිතියක් නොවූ කෙටුම්පත්වලින් එයි, එබැවින්ම නිෂ්පාදකයන් දෙදෙනෙකුට හයිබ්‍රිඩ් මාදිලිය ක්‍රියාත්මක කර කිසිවෙකු සමඟ අන්තර් ක්රියා නොකර සිටිය හැක.
IKEv2 එම සාක්ෂි දෙකට ළඟා වන්නේ කෙසේද
IKEv2 කාර්යය IKE_SA_INIT සහ IKE_AUTH අතර බෙදයි. පළමු හුවමාරුව කිසිදු අනන්‍යතාවකින් තොරව යෝජනා සහ යතුරු පිළිගනී; දෙවැන්න IDi, IDr සහ AUTH ගෙවීම් දරයි. EAP යටතේ ආරම්භකයාගේ පළමු AUTH ගෙවීම හිස්ව යයි, ප්‍රතිචාර දක්වන පාර්ශවය පළමුව තම සහතිකයෙන් සහ අත්සනින් සත්‍යාපනය වේ, පසුව EAP සංවාදය IKE_AUTH පණිවිඩ තුළ ගලා යයි.
මෙය ආරක්ෂිත කරන යාන්ත්‍රණය යතුරු ද්‍රව්‍යයයි. සාර්ථක EAP ක්‍රමයක් සැසි යතුරක් අපනයනය කරයි, ආරම්භකයාගේ අවසාන AUTH ගෙවීම එයින් ගණනය වේ, එබැවින් පරිශීලකයාගේ සාක්ෂිය සහ උමං යතුරු එකිනෙකට බැඳේ. XAuth ට එවැනි සමානයක් නැත: එහි ගුණාංග පළමු අවස්ථාවෙන් පසු පැමිණේ, යතුරුවලට කිසිවක් එකතු නොකරයි. මෙම හිඩැස පිරවීමටයි IKEv2 රාමුව නිර්මාණය කළේ, එබැවින්ම ක්‍රියාත්මක වන IKEv2 පිවිසුම කිසිවක් ඉල්ලීමට පෙර සේවාදායක සහතිකය වලංගු කරයි.
මෙම අනුපිළිවෙල ප්‍රයෝජනවත් රෝග විනිශ්චයක්ද වේ. සේවාලාභියා ඔබට සහතිකයක් නොපෙන්වා අක්තපත්‍ර ගැන පැමිණිලි කරන්නේ නම්, ඔහු IKEv2 EAP හුවමාරුවක් කරන්නේම නැත.
අනන්‍යතා තුනක් වෙන් කර තබන්න
අනන්‍යතා තුනක් එකම ක්ෂේත්‍රයකට කඩා වැටෙන විට සංක්‍රමණය වැරදි යයි. සේවාලාභියා වලංගු කරන ගේට්වේ අනන්‍යතාවක් ඇත, සාමාන්‍යයෙන් සහතිකයේ subject හෝ SAN හි DNS නාමයක්. EAP හි ඉදිරිපත් කරන පරිශීලක අනන්‍යතාවක් ඇත, වසම් පිවිසුමක්, ලිපිනයක් හෝ පැහැදිලි EAP අනන්‍යතා තන්තුවක් විය හැක. තවද එම පරිශීලකයා ජාල සහ මාර්ගවලට සිතියම් කරන අවසර මූලාශ්‍රයක් ඇත.
strongSwan හි swanctl ව්‍යාකරණය වෙන්වීම පෙනෙන ලෙස කරයි: සම්බන්ධතාවය ගේට්වේ සඳහා remote { auth = pubkey } සහ පරිශීලකයා සඳහා local { auth = eap-mschapv2 } සකසයි, EAP අනන්‍යතාව වෙන් වශයෙන් ගෙන යයි.
නව පැතිකඩේ පරිශීලක අනන්‍යතාව පැරණි XAuth ගුණාංගවලින් වෙනස් නම්, උදාහරණයක් ලෙස කෙටි නම වෙනුවට UPN, සත්‍යාපන සේවාදායකය නාඳුනන පරිශීලකයෙකු දකී, අසාර්ථකත්වය වැරදි මුරපදයක් මෙන් පෙනේ. අක්තපත්‍ර පරීක්ෂා කිරීමට පෙර අනන්‍යතා තන්තුව පරීක්ෂා කරන්න.
විකල්ප සිතියම් කර පසුව උගුල් බලාපොරොත්තු වන්න
සිතියම ස කෙටිය, සෑම පේළියකම සත්‍යාපනයේදී පමණක් දිස්වන උගුලක් ඇත.
| 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 |
එම පේළි කිසිවක් නම් මාරු කිරීමක් පමණක් නොවේ. වින්‍යාස ගෙවීම ලිපින සහ විසඳුම් ටයිප් කළ ගුණාංග ලැයිස්තුවක් හරහා ලබා දෙයි, XAuth හි ගුණාංග ක්ෂේත්‍රය එහිම සොයාගැනීමක් විය; ඒවා හුවමාරු කළ හැකි ලෙස සැලකීම යනු පැතිකඩ ගේට්වේ කිසිදා නොයවන සැකසුමක් ඉල්ලා සිටින මාර්ගයයි.
රථවාහන තෝරකයින්ට තමන්ගේම අනතුරු ඇඟවීමක් වටී. IKEv1 සිත්ගන්නා රථවාහන quick mode හුවමාරුවට බැඳුණු ප්‍රොක්සි හැඳුනුම් මගින් ප්‍රකාශ කළේය, IKEv2 IKE_AUTH අතරතුර තෝරකයින් සාකච්ඡා කරයි, ප්‍රතිචාර දක්වන පාර්ශවයට ඒවා පටු කළ හැක. නොගැළපීම child SA නොමැති ස්ථාපිත IKE SA එකක් නිපදවයි, සමහර සේවාලාභීන් එය සතුටින් සම්බන්ධ ලෙස පෙන්වයි.
පැරණි සම්බන්ධතාවය මායිමක් ලෙස සලකන්න
RFC 9395 IKEv1 කල් ඉකුත් වූ ලෙස ප්‍රකාශ කරයි, එබැවින් පැරණි හයිබ්‍රිඩ් සම්බන්ධතාවය දිනයක් සහිත ගැළපුම් මායිමකි, අත්තිවාරමක් නොවේ. වෙනස්කම අතරතුර පැතිකඩ දෙකම අසලින් අසල ධාවනය කරන්න, වැදගත් පරීක්ෂණය නව පැතිකඩ ඉහළ යනවාද යන්න නොව, එම පරිශීලකයා එම උපාංගයේම එම සම්පත් වෙත ළඟා වන්නේද යන්නය.
සහතික වලංගුකරණය ආරම්භයේ සිට අවසානය දක්වා දැඩිව තබා ගන්න. සේවාලාභියා තම සහතිකය පෙන්වීම නතර කළ විට, අත්ලොස්ස අවසන් වන තෙක් සේවාදායක පරීක්ෂාව ලිහිල් කිරීමේ පෙළඹවීම පැමිණේ, එය ඉතිරිව ඇති එකම සාක්ෂිය හරිත සංකේතයකින් වෙනස් කරයි.
පැරණි පැතිකඩ විශ්‍රාම යැවීමට පෙර කරුණු හතරක් ලියන්න: EAP ක්‍රමය, අනන්‍යතා තන්තුව, අවසර මූලාශ්‍රය සහ සහාය අවසන් වන දිනය.