எந்த PPP பயனர் பெயரும் ஆராயப்படுவதற்கு முன்பே NO_PROPOSAL_CHOSEN வருகிறது, இது பயனுள்ள உண்மை மட்டுமல்ல, செய்தி தவறாக வழிநடத்துவதற்கான காரணமும் ஆகும். ஒரு பக்கம் ஒரு முன்மொழிவை நிராகரித்ததாக அது தெரிவிக்கிறது; எந்த அளவுரு பொருந்தவில்லை என்பதைத் தெரிவிக்கவில்லை, மேலும் நிராகரிப்பு IKE தொடர்பு கட்டப்படும் போது நிகழ்ந்ததா அல்லது பின்னர் போக்குவரத்துப் பாதுகாப்பு பற்றிய பேச்சுவார்த்தையின் போது நிகழ்ந்ததா என்பதைப் பற்றியும் எதுவும் கூறவில்லை. இந்த இரண்டு சாத்தியங்களுக்குப் பின்னால் இரண்டு வெவ்வேறு திருத்தங்கள் உள்ளன, அவற்றில் ஒன்று மட்டுமே மக்கள் முதலில் கை வைக்கும் PFS தேர்வுப்பெட்டியுடன் தொடர்புடையது.

ஒரு செய்தி, இரண்டு முன்மொழிவுத் தொகுப்புகள்

IKEv1 L2TP/IPsec அமைப்பில் இரண்டு பேச்சுவார்த்தைகள் தொடர்ச்சியாக நடைபெறுகின்றன. கட்டம் 1 மறையாக்க வழிமுறை, ஒருமைப்பாட்டு வழிமுறை மற்றும் Diffie-Hellman குழுவிலிருந்து IKE பாதுகாப்புத் தொடர்பை உருவாக்குகிறது. பின்னர் கட்டம் 2 போக்குவரத்து எவ்வாறு பாதுகாக்கப்படும் என்பதைப் பேசுகிறது, PFS தேவை அந்த இரண்டாவது உரையாடலுக்கே உரியது.

PhaseWhat is agreedWhat a rejection here means
Phase 1Encryption, integrity, DH group for the IKE SANo management tunnel exists, so nothing later can run
Phase 2ESP transforms plus the PFS group policyThe IKE SA negotiates, then child negotiation fails

கட்டங்கள் தொடர்ச்சியாக இருப்பதால், தோல்வியின் இடம் எந்தப் பட்டியலை ஒப்பிட வேண்டும் என்பதைச் சொல்கிறது. செய்தியின் முழுப் பரிசோதனை மதிப்பும் அதில்தான் உள்ளது, எந்த அமைப்பையும் தொடுவதற்கு முன் அதை வெளியே எடுப்பது மதிப்புடையது.

PFS தேர்வுப்பெட்டி கட்டம் 1 ஐ ஏன் சரிசெய்ய முடியாது

PFS ஐ முடக்குவது கட்டம் 2 இன் ஒரு பண்பை மாற்றுகிறது. இரு பக்கங்களும் கட்டம் 1 இல் ஒருபோதும் உடன்படவில்லை என்றால், ESP உரையாடல் ஒருபோதும் நடைபெறாது, எனவே தேர்வுப்பெட்டி நிராகரிப்பில் எந்த விளைவையும் ஏற்படுத்தாது, அதனால்தான் அதை மாற்றுவது அதே பிழையை வேறு நேர முத்திரையுடன் தருகிறது.

எதிர்மறைப் பிழையும் அதே அளவு பொதுவானது. வெற்றிகரமான IKE தொடர்பு ESP முன்மொழிவு ஏற்கத்தக்கது என்பதை நிரூபிக்கவில்லை, கட்டம் 2 இன் குழு பொருந்துகிறது என்பதை ஒருபோதும் நிரூபிக்கவில்லை. நிறுவப்பட்ட நிர்வாகச் சுரங்கப்பாதையைக் கட்டம் 1 பற்றிய சான்றாக மட்டுமே கருதுங்கள். மக்கள் பச்சைக் கோட்டை «சுரங்கப்பாதை இயங்குகிறது» என்று படித்து, இரண்டாவது பேச்சுவார்த்தை தொடங்கவில்லை என்று யாரும் சொல்லாததால் தவறான கட்டத்தில் ஒரு மணி நேரம் வீணாக்குகிறார்கள்.

வழிமுறைகளைத் தேர்ந்தெடுப்பதற்கு முன் பதிவைப் படியுங்கள்

நிராகரிப்பிற்கு முன் வந்த செய்திகளை, இணைப்பை உண்மையில் கையாளும் பின்தளத்திலிருந்து சேகரித்து, அவற்றை அதே முயற்சியுடன் தொடர்புபடுத்துங்கள். அந்தத் தொடர்பு இல்லாமல் நீங்கள் வேறு இணைப்பின் வரலாற்றைப் படித்து அதிலிருந்து முடிவுகளை எடுக்கிறீர்கள்.

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

அந்த வரிகளிலிருந்து இரண்டு கேள்விகளுக்குப் பதிலளியுங்கள்: கட்டம் 1 தொடர்பு நிறுவப்பட்டதா, எந்தப் பரிமாற்றம் தோல்வியடைந்தது. அந்த இரண்டு பதில்களும் தேடலை ஒரே பண்புப் பட்டியலாகச் சுருக்குகின்றன. சுற்றியுள்ள சூழல் இல்லாத வெறும் அறிவிப்பால் அதைச் செய்ய முடியாது, மன்ற இழையிலிருந்து ஒரு முன்மொழிவை முயற்சிப்பது எவ்வளவு கவர்ச்சிகரமானதாக இருந்தாலும். வேறு பின்தளம் கொண்ட இயந்திரத்திலிருந்து வேலை செய்யும் சரத்தை நகலெடுப்பது பொதுவாக ஒரு நிராகரிப்பை மற்றொன்றால் மாற்றுகிறது, சற்று தாமதமாக.

பின்தளத்தின் இலக்கணம் பயணிக்காது

எதையும் ஒப்பிடுவதற்கு முன் NetworkManager-l2tp பதிப்பையும் IPsec பின்தளப் பதிப்பையும் பதிவு செய்யுங்கள். Libreswan மற்றும் strongSwan முன்மொழிவு இலக்கணத்தையோ ஒரே மாதிரியான வழிமுறைத் தொகுப்புகளையோ பகிர்ந்து கொள்வதில்லை, எனவே ஒன்றில் வேலை செய்யும் சரம் மற்றொன்றில் இலக்கணப் பிழை. நிறுவப்பட்ட பின்தளம் கொள்கையின்படி IKEv1 ஐயும் நிராகரிக்கக்கூடும், அப்போது எந்த முன்மொழிவும் ஒருபோதும் ஏற்கப்படாது.

திட்டத்தின் README அந்தப் பின்தள வேறுபாடுகளை ஆவணப்படுத்தி, கட்டம் 1 மற்றும் கட்டம் 2 புலங்களைத் தனித்தனியாக வைத்திருக்கிறது. அதை அமைப்பின் ஆவணமாகப் படியுங்கள், ஒவ்வொரு வரலாற்று மறையீட்டையும் பலவீனமான குழுவையும் இயக்க அழைப்பாக அல்ல, ஏனெனில் அப்படிச் செய்வதால் மட்டுமே வெற்றிபெறும் இணைப்பு நீங்கள் கட்டக் கேட்கப்பட்ட இணைப்பு அல்ல.

தொகுப்பில் உடன்படுங்கள், பின்னர் நிலைகளைச் சரிபாருங்கள்

எந்த IKE மற்றும் ESP தொகுப்புகள் ஆதரிக்கப்படுகின்றன மற்றும் அங்கீகரிக்கப்பட்டுள்ளன என்று நுழைவாயில் இயக்குநரிடம் கேளுங்கள், பின்னர் அந்தப் பதிலை வாடிக்கையாளரின் உள்ளமைவுக் கோப்புடன் அல்ல, அதன் உண்மையான முன்மொழிவுகளுடன் ஒப்பிடுங்கள். வேறுபாடு குறிப்பாக கட்டம் 2 இன் PFS பற்றியதாக இருந்தால், ஆதரிக்கப்படும் குழு அல்லது வெளிப்படையாக அங்கீகரிக்கப்பட்ட PFS இல்லாத கொள்கையில் முடிவு செய்யுங்கள். பிழையின் பெயரிலிருந்து கொள்கையை ஊகிக்க வேண்டாம்.

ஒரே ஒற்றுமை அமைப்பு இனி ஏற்காத மறையாக்கத்தைக் கோரினால், முடிவு நுழைவாயிலுக்கோ நெறிமுறை இடம்பெயர்வுக்கோ உரியது. ஏதாவது பேச்சுவார்த்தை நடத்தும் வரை வாடிக்கையாளர் சரத்தை விரிவுபடுத்துவது, அறியப்பட்ட பலவீனத்தை அருகில் பச்சை டிக்குடன் அனுப்பும் வழி.

உண்மையான பொருந்தாமையைத் திருத்திய பிறகு, L2TP மற்றும் PPP ஐ ஆராய்வதற்கு முன் IPsec நிறுவலை உறுதிப்படுத்துங்கள், மேலும் பின்னர் வரும் எந்த அங்கீகார நிராகரிப்பையும் அடுத்த கட்டத்திற்கு உரியதாகக் கருதுங்கள். பின்னர் அங்கீகரிக்கப்பட்ட சோதனை செயல்பாட்டில் புதுப்பித்தலைச் சோதியுங்கள், ஏனெனில் முதல் தொடர்பை நிறுவுவது அதன் மீதமுள்ள ஆயுளைப் பற்றி எதுவும் கூறாது.

தொடர்புடைய கட்டுரைகள்