L2TP/IPsec தோல்வியடைகிறது: IPsec, சுரங்கப்பாதை அங்கீகாரம் அல்லது PPP உள்நுழைவை பிரிக்கவும்

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

மூன்று அங்கீகார நிலைகள், மூன்று வேறுபட்ட அடையாளங்கள்

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

L2TP கட்டுப்பாட்டு இணைப்பு இரண்டாவது, தனித்த சவால்-பதில் பரிமாற்றத்தைச் சேர்க்கலாம், இது இரு முனைகளும் வைத்திருக்க வேண்டிய பகிரப்பட்ட ரகசியத்தால் இயக்கப்படுகிறது.

RFC 2661 அந்தக் கட்டுப்பாட்டு இணைப்பு அங்கீகாரத்தை விருப்பமாக்குகிறது, இதுவே அதே தவறு இரு சேவையகங்களில் வெவ்வேறு அறிகுறிகளை உருவாக்குவதற்குக் காரணம். சுரங்கப்பாதை ரகசியத்தை ஒருபோதும் அமைக்காத வரிசைப்படுத்தல் அந்த நிலையை முழுமையாகத் தவிர்க்கிறது; ஒரு பக்கத்தில் மட்டும் அமைத்தது PPP வழங்கப்படுவதற்கு முன்பே தோல்வியடைகிறது. பின்னர் PPP பயனரை PAP, CHAP அல்லது MSCHAPv2 மூலம் அங்கீகரித்து பெயரை உள்ளூர், chap-secrets அல்லது RADIUS இல் இருக்கக்கூடிய கணக்குக் களஞ்சியத்திற்கு வழங்குகிறது. அந்த நேரத்தில் தவறான கடவுச்சொல் இன்னும் செயல்படும் சுரங்கப்பாதையையும் தோல்வியடைந்த அமர்வையும் உங்களிடம் விட்டுவிடும்.

கட்டமைப்பைத் திருத்தும் முன் நிற்கும் இடத்தைப் படியுங்கள்

நிலை வெளியீடு strongSwan அல்லது Libreswan ஐச் சேர்ந்ததா என்பதை அறிய ipsec --version இல் தொடங்குங்கள். பின்னர் வாடிக்கையாளர் உரையாடலை அல்ல, சேவையகப் பதிவைப் படியுங்கள், ஏனெனில் எந்த நிலை மறுத்தது என்பதை சேவையகம் பதிவு செய்கிறது.

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

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

முதல் நிலை: IPsec க்கு தொடர்பு உள்ளதா?

strongSwan இல் ipsec statusall அல்லது Libreswan இல் ipsec whack --status இயக்கி, பூஜ்ஜியமற்ற எண்ணிக்கையாளர்களுடன் நிறுவப்பட்ட குழந்தைத் தொடர்பைத் தேடுங்கள். ip xfrm state இரண்டிலும் கர்னல் பார்வையைக் காட்டுகிறது. எண்ணிக்கையாளர்கள் உயரும் நிறுவப்பட்ட SA இணை என்றால் முதல் நிலை முடிந்தது, தொடரலாம்.

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

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

இரண்டாம் நிலை: L2TP கட்டுப்பாட்டு இணைப்பு அங்கீகரிக்கப்பட்டதா?

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

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

PPP பேச்சுவார்த்தையைத் தொடங்கும் அமர்வு மட்டுமே சுரங்கப்பாதை நிலையை உண்மையில் கடந்தது.

மூன்றாம் நிலை: PPP கணக்கை மறுக்கிறதா?

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

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

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