IPsec முன்மொழிவில் என்ன இருக்கிறது? IKE மற்றும் ESP புலங்கள்
முன்மொழிவு என்பது ஒரு முழுமையான சலுகை, அல்காரிதம்களின் பை அல்ல. எந்தப் புலங்கள் IKE க்கு சொந்தம், எவை ESP க்கு, மற்றும் ஒரு பொருந்தாமை ஏன் முழுத் தொகுப்பையும் நிராகரிக்கிறது என்பதைப் பாருங்கள்.
IKE தொடங்குகிறது, இரு தரப்பும் AES ஐ அறிவிக்கின்றன, இருந்தும் சுரங்கப்பாதை NO_PROPOSAL_CHOSEN உடன் தோல்வியடைகிறது. பதிவு முன்மொழிவின் பெயரைக் கூறுகிறது, ஆனால் பொருந்தாத புலத்தைக் கூறவில்லை. முன்மொழிவு ஒரு முழுமையான சலுகை, ஒரு பொருந்தாத புலம் அந்த வரியை மட்டுமல்ல, முழுக் கலவையையும் செல்லாததாக்குகிறது. இதைச் சார்பற்ற அல்காரிதம் தேர்வுகளின் பையாகப் படிப்பதே பொருந்தாமை மறைவாக இருப்பதற்கான வழக்கமான காரணம்.
தனித்தனி முன்மொழிவு பட்டியல்களுடன் இரு பேச்சுவார்த்தைகள்
IKEv2 இரு பாதுகாப்பு இணைப்புகளை உருவாக்குகிறது. முதல் IKE SA, இது கட்டுப்பாட்டுப் பரிமாற்றத்தையே பாதுகாக்கிறது, இரண்டாவது CHILD SA, இது உங்கள் போக்குவரத்தை ESP வழியாகக் கொண்டு செல்கிறது. ஒவ்வொன்றுக்கும் அதன் சொந்த முன்மொழிவு பட்டியல் உள்ளது, ஒரு தரப்பு ஒன்றை ஏற்று மற்றதை நிராகரிக்கலாம்.
இந்தப் பிரிவு ஒரு பொதுவான குழப்பத்தை விளக்குகிறது: செயல்படும் IKE SA, கட்டுப்பாட்டு சேனலின் அல்காரிதம்கள் பொருந்தின என்பதை மட்டுமே நிரூபிக்கிறது. CHILD முன்மொழிவு தோல்வியடைந்தால், முதல் கட்டம் முடிந்து பதிவுகள் மேலே ஆரோக்கியமாகத் தெரிந்தாலும், சுரங்கப்பாதை ஒரு பாக்கெட்டும் கொண்டு செல்லாது.
ஒவ்வொரு பட்டியலுக்குள்ளும் வரிசையும் முக்கியம். பதிலளிப்பவர் தொடக்கியவரின் வரிசைப்படுத்தப்பட்ட சலுகைகளில் இருந்து தேர்ந்தெடுக்கிறார், எனவே பரந்த அளவில் ஒத்துழைக்கும் உள்ளீட்டைக் குறுகிய ஒன்றுக்கு மேலே நகர்த்துவது எந்தத் தொகுப்பு நிறுவப்படும் என்பதை மாற்றும், எந்த அல்காரிதப் பெயரும் மாறாமல். இயல்புநிலைகளை நம்பாமல் அந்த வரிசையை உள்ளமைவில் பொருத்துங்கள். நிலையான வரிசை தளங்களுக்கிடையேயான பதிவு ஒப்பீட்டையும் அர்த்தமுள்ளதாக்குகிறது.
எந்தப் புலங்கள் எந்த முன்மொழிவுக்கு
புலங்களின் தொகுப்பு சிறியது, ஆனால் இரு பேச்சுவார்த்தைகளிலும் ஒன்றுபோல் இல்லை. ஒரு நிரலில் உள்ள புலம் மற்றொன்றில் இல்லாமல் இருக்கலாம், எனவே அட்டவணையை வரி வரியாகப் படியுங்கள். இலக்கணம் செயலாக்கத்தைப் பொறுத்து மாறுபடும்; strongSwan இன் முன்மொழிவு ஆவணங்கள் ஒரு குறிப்பிட்ட குறிப்பு ஆகும்.
| Field | IKE SA proposal | CHILD SA proposal |
|---|---|---|
| Encryption | Required | Required |
| Integrity | Required unless AEAD | Required unless AEAD |
| PRF | Required | Not present |
| DH group | Required | Only for PFS |
| ESN | Not present | Optional |
மறையாக்கப் புலம் மறைக்குறியீட்டையும், பெரும்பாலான இலக்கணங்களில் அதன் விசை நீளத்தையும் குறிப்பிடுகிறது. ஒருமைப்பாட்டுப் புலம் மறையாக்கப்பட்ட உரையை அங்கீகரிக்கப் பயன்படும் ஹாஷைக் குறிப்பிடுகிறது, PRF என்பது IKE SA க்கான விசைப் பொருளைப் பெறும் செயல்பாட்டைக் குறிப்பிடுகிறது. DH குழு புதிய பகிரப்பட்ட ரகசியப் பொருளை நிறுவுகிறது, அதனால்தான் அது இரு பக்கமும் தெரிகிறது, ஆனால் வெவ்வேறு நோக்கங்களுக்கு.
நீட்டிக்கப்பட்ட வரிசை எண்கள் தரவுப் பாதைக்கு மட்டுமே சொந்தம். அவை வரிசை இடத்தை விரிவாக்குகின்றன, CHILD முன்மொழிவின் பகுதியாகப் பேச்சுவார்த்தை செய்யப்படுகின்றன, எனவே அங்குள்ள பொருந்தாமை CHILD சலுகையை நிராகரிக்கும், IKE SA தொடப்படாமல் இருக்கும்.
ஒரு முழுமையான சலுகை எவ்வாறு தேர்ந்தெடுக்கப்படுகிறது
ஒவ்வொரு முன்மொழிவும் ஒரு தொகுப்பு, பதிலளிப்பவர் ஒவ்வொரு கட்டாயப் புலமும் ஏற்கத்தக்க தொகுப்பைத் தேடுகிறார். இரு பட்டியல்களிலும் AES மற்றும் SHA-256 இருக்கலாம், இருந்தும் பொருந்தும் உள்ளீடு இல்லாமல் இருக்கலாம், ஏனெனில் விசை நீளம், PRF அல்லது DH குழு வேறுபடுகின்றன. ஒப்பீடு ஒவ்வொரு அல்காரிதத்திற்கும் அல்ல, ஒவ்வொரு முன்மொழிவுக்கும் நடக்கிறது.
எதுவும் பொருந்தவில்லை என்றால், பதிலளிப்பவர் தோல்வியடைந்த SA வகையுடன் NO_PROPOSAL_CHOSEN அனுப்புகிறார். உள்ளமைவைத் திருத்தும் முன் அறிவிப்பு எந்த முன்மொழிவு பட்டியலைச் சார்ந்தது என்பதைப் படியுங்கள்; IKE முன்மொழிவு நிராகரிக்கப்பட்டபோது ESP அல்காரிதம்களை மாற்றுவது ஒரு பிழைத்திருத்த சுழற்சியை வீணாக்குகிறது.
சுயவிவரத்தை மாற்றும்போது தேர்வு நடத்தையை அறிவது பயனுள்ளது. சில செயலாக்கங்கள் தொடக்கியவரின் வரிசையை விரும்புகின்றன, மற்றவை உள்ளூர் கொள்கையின்படி மறுவரிசைப்படுத்துகின்றன, எனவே இரு விற்பனையாளர்களிடையே செயல்படும் தொகுப்பு மறைந்துவிடலாம் இணைப்பை எந்தப் பக்கம் தொடங்குகிறது என்பதை நீங்கள் திருப்பும்போது.
AEAD ஒரு புலத்தைச் சேர்ப்பதற்குப் பதிலாக நீக்குகிறது
AES-GCM மற்றும் ChaCha20-Poly1305 ஒரே செயல்பாட்டில் அங்கீகாரமும் மறையாக்கமும் செய்கின்றன. அவற்றில் ஒன்று ESP க்குத் தேர்ந்தெடுக்கப்படும்போது, AEAD கட்டமைப்பு ஏற்கனவே அதை உள்ளடக்குவதால், ஒருமைப்பாட்டு அல்காரிதம் தனியாகப் பேச்சுவார்த்தை செய்யப்படுவதில்லை. எனவே AES-GCM ஐ SHA-256 உடன் இணைக்கும் முன்மொழிவு சிறந்த நிலையில் தேவையற்றது, மோசமான நிலையில் நிராகரிக்கப்படுகிறது.
IKE பக்கத்தில் PRF இன்னும் தனியாக உள்ளது, ஏனெனில் அது பேலோடுகளைப் பாதுகாப்பதற்குப் பதிலாக கட்டுப்பாட்டு சேனலுக்கு விசைகளைப் பெறுகிறது. அதனால்தான் IKE முன்மொழிவு AEAD மறைக்குறியீட்டை PRF மற்றும் DH குழுவுடன் சட்டப்படி இணைக்க முடியும், அதே நேரம் தொடர்புடைய ESP முன்மொழிவு AEAD மறைக்குறியீட்டையும் விருப்ப PFS குழுவையும் மட்டுமே பட்டியலிடுகிறது.
விசை நீளம் மறையாக்க டோக்கனின் பகுதி, எனவே AES-128-GCM மற்றும் AES-256-GCM வெவ்வேறு சலுகைகள். 256-bit விசைகளைக் கருதிய வழிகாட்டியிலிருந்து நகலெடுத்த சுயவிவரம் 128-bit க்கு உள்ளமைக்கப்பட்ட முனைப்புள்ளியுடன் பொருந்தாது, இரு வரிகளும் AES-GCM என்று சொன்னாலும். இரு தரப்பும் மறைக்குறியீட்டு குடும்பத்தில் உடன்பட்டு, இடைக்கோட்டுக்குப் பின் உள்ள எண்ணின் காரணமாக ஒருவரையொருவர் நிராகரிக்கலாம்.
உள்ளமைவை அல்ல, நிறுவப்பட்ட SA ஐப் படியுங்கள்
உள்ளமைக்கப்பட்ட முன்மொழிவு பட்டியல் ஒரு சலுகை; நிறுவப்பட்ட SA முடிவு. strongSwan மற்றும் Linux கர்னலில் இரு பார்வைகளும் கிடைக்கின்றன:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas ஒவ்வொரு SA க்கும் பேச்சுவார்த்தை செய்யப்பட்ட அல்காரிதம்களை அச்சிடுகிறது, CHILD AEAD பயன்படுத்துகிறதா என்பதும் உட்பட. ip xfrm state கர்னல் உண்மையில் எதை நிறுவியது என்பதைக் காட்டுகிறது, மற்றும் விசைப் புதுப்பித்தல் நீங்கள் ஆவணப்படுத்தியதிலிருந்து வேறுபட்ட தொகுப்புக்குத் திரும்பவில்லை என்பதை உறுதிப்படுத்தும் இடம் அதுவே.
சரிசெய்தலுக்குப் பிறகு அந்த வெளியீட்டை உள்ளமைவுக்கு அருகில் சேமியுங்கள். கிளையன் புதுப்பிப்பு அதன் இயல்புநிலைகளை மாற்றும்போது, பதிவு செய்யப்பட்ட தொகுப்பு ஒப்பீட்டுக்கான அடிப்படைக் கோட்டைத் தருகிறது, ஒப்பீடு விசாரணையை மீண்டும் தொடங்குவதற்குப் பதிலாக நகர்ந்த புலத்தைச் சுட்டிக்காட்டுகிறது.