PPP CHAP மட்டும் MPPE தேவையை ஏன் நிறைவேற்ற முடியாது

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

ஒரு PPTP இணைப்புக்குள் இரண்டு பேச்சுவார்த்தைகள் நடக்கின்றன

PPTP GRE சுரங்கப்பாதைக்குள் சாதாரண PPP அமர்வை எடுத்துச் செல்கிறது, இரண்டும் தனித்தனியாகப் பேச்சுவார்த்தை நடத்துகின்றன. வெளிப்புற அடுக்கு பாக்கெட்டுகள் எவ்வாறு மூடப்படுகின்றன, எந்தக் கட்டுப்பாட்டு channel உள்ளது என்பதைத் தீர்மானிக்கிறது; உட்புற PPP அமர்வு யார் துணை, மேலே எந்தப் பாதுகாப்பு செல்கிறது என்பதைத் தீர்மானிக்கிறது. எனவே கடவுச்சொல் கோரிக்கை உட்புற அடுக்கைப் பற்றி மட்டுமே ஏதாவது நிரூபிக்கிறது, முடிந்த வெளிப்புற கைக்குலுக்கல் இரண்டைப் பற்றியும் எதையும் நிரூபிக்கவில்லை. சுயவிவரங்கள் இங்கே தோல்வியடைவதற்குக் காரணம், கருத்து வேறுபாடு PPP-க்குள் அமர்ந்திருக்கும்போது மக்கள் சுரங்கப்பாதையைப் பிழைத்திருத்துகிறார்கள்.

சாதாரண CHAP என்பது RFC 1994-ல் உள்ள சவால்-பதில் பரிமாற்றம், பகிரப்பட்ட ரகசியத்தின் மீது மட்டுமே கட்டப்பட்டது. MS-CHAPv2 வேறு செய்திகளும் வேறு வெளியீடும் கொண்ட மற்றொரு பரிமாற்றம், RFC 2759-ல் தரப்படுத்தப்பட்டது. இரு பெயர்களிலும் உள்ள பொதுச் சொல் கம்பியில் அவர்களுக்குப் பொதுவான ஒரே விஷயம். எந்தப் பெயரும் பரிமாற்றம் எதை உருவாக்குகிறது என்று சொல்லவில்லை, அதுவே ஒரே முக்கியமான பகுதி.

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

தேவையான முறையை அது உருவாக்கக்கூடிய விசைகளுடன் பொருத்துங்கள்

MPPE விசைகள் பொதுவாக PPP-யின் பண்பு அல்ல. Microsoft CHAP குடும்பத்திற்கு வழித்தோன்றல் RFC 3079-ல் குறிப்பிடப்பட்டுள்ளது, அது உள்ளீடாகப் பகிரப்பட்ட ரகசியத்திற்குப் பதிலாக MS-CHAP பரிமாற்றத்தின் வெளியீட்டை எடுக்கிறது. EAP முறைகள் வேறு வழியில் அதே இடத்தை அடைகின்றன, அங்கீகார சேவையகம் விசைகளை MS-MPPE-Recv-Key மற்றும் MS-MPPE-Send-Key பண்புகளாகத் திருப்பித் தருகிறது. சாதாரண CHAP இரு வழிகளிலும் தோன்றுவதில்லை, இந்தப் பொருந்தாமை இருப்பதற்கான முழுக் காரணம் அதுவே.

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

இதிலிருந்து வரும் விதி சுருக்கமானது: சுயவிவரம் MPPE கோரினால், முறை MS-CHAP வகை அல்லது சேவையகம் விசைகளைத் திருப்பித் தரும் EAP முறையாக இருக்க வேண்டும். MS-CHAPv2-ஐ மட்டும் நிராகரிப்பது அதை நடைமுறைப்படுத்தாது, ஏனெனில் MS-CHAPv1-ம் விசைகளை வழித்தோன்றும், தனியாக நிராகரிக்கப்படாவிட்டால் கிடைக்கும்; இரண்டையும் நிராகரித்தால் சாதாரண CHAP-ம் PAP-ம் எஞ்சும், அவை எதையும் வழித்தோன்றாது தேவையை நிறைவேற்ற முடியாததாக்கும். உங்களுக்குப் பிடிக்காதவற்றைப் பட்டியலிடுவதற்குப் பதிலாக ஏற்கப்பட்ட முறையைத் தெளிவாகப் பெயரிடுங்கள். வாடிக்கையாளர் இணைவதற்காக குறியாக்கத் தேவையை விட்டுவிடுவது பழுதுநீக்கமல்ல, தரமிழப்பு.

வாடிக்கையாளரைத் திருத்தும் முன் சேவையகத்தின் விருப்பங்களைப் படியுங்கள்

இந்தப் பொருந்தாமைகளில் பெரும்பாலானவை சேவையகத்தில் இரு கோப்புகளில் தெரியும், அவற்றைப் படிப்பது வாடிக்கையாளரை மீண்டும் கட்டுவதை விட மலிவு. Linux PPTP முனையத்தில் தொடர்புடைய அமைப்புகள் pptpd அனுப்பும் pppd விருப்பக் கோப்பில் வாழ்கின்றன. அதைச் சேவையகத்தில் இயக்குங்கள், வாடிக்கையாளர் நிலைத் திரையிலிருந்து அல்ல. பாதுகாப்பு முறையைக் கோரும், நிராகரிக்கும் அல்லது பெயரிடும் வரிகளிலிருந்து தொடங்குங்கள்:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

வெளியீட்டைக் கொடிகளின் பட்டியலாக அல்ல, ஒப்பந்தமாகப் படியுங்கள். MPPE கோரி MS-CHAP-ன் இரு வகைகளையும் நிராகரிக்கும் வரியை எந்த வாடிக்கையாளரும் நிறைவேற்ற முடியாது, MS-CHAP முறைக்கான தேவை இல்லாதது விசை தராத பரிமாற்றங்களுக்குக் கதவைத் திறந்து விடுகிறது. பின்னர் யாருக்கு அங்கீகாரம் அனுமதிக்கப்பட்டுள்ளது என்பதைச் சரிபாருங்கள், அதை ரகசியக் கோப்பு தீர்மானிக்கிறது:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

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

PPP கட்டத்தின் அடிப்படையில் தோல்வியைக் கண்டறியுங்கள்

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

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

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

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

பழைய முனையம் அணைக்கப்படும் முன் வெளியேறலைத் திட்டமிடுங்கள்

MPPE என்பது இணைப்புப் பாதுகாப்பின் வரலாற்று இயங்குமுறை, அதன் இருப்பு PPTP-ஐ புதிய பயன்பாட்டிற்கு நியாயமான தேர்வாக ஆக்காது. Microsoft-ன் தற்போதைய வழிகாட்டுதல் புதிய தொலை அணுகல் பயன்பாடுகளுக்கு PPTP-க்கும் முன்பே பகிரப்பட்ட விசையுடன் L2TP/IPsec-க்கும் எதிராக ஏற்கனவே பரிந்துரைக்கிறது. பழைய முனையத்தை உயிருடன் வைத்திருப்பது இருக்கும் சேவையைப் பற்றிய முடிவு, அடுத்ததற்கான வார்ப்புரு அல்ல.

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

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