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 முறை, அடையாளச் சரம், அனுமதி மூலம் மற்றும் ஆதரவு முடியும் தேதி.