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

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

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

ஒப்பிடுவதற்கு முன் இரு முனைகளிலும் கடிகாரங்களை ஒத்திசைக்கவும். IPsec-ஐ சுத்தம் செய்து PPP-யில் தோல்வியடைந்த மறுமுயற்சி, கிளையன்ட் இறுதிச் செய்தியை மட்டும் காட்டும்போதும் சேவையகப் பதிவு முந்தைய முயற்சியை இன்னும் வைத்திருக்கும்போதும் ஒரே தோல்வியாகத் தெரிகிறது. மிகவும் சத்தமான வரியினால் அல்ல, நேர முத்திரையினால் படியுங்கள்.

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

ஒவ்வொரு அடுக்கும் உண்மையில் எதைக் கொண்டுள்ளது

IPsec இரு சகாக்களுக்கு இடையே பாக்கெட்டுகளைப் பாதுகாக்கிறது; L2TP அந்தப் பாதுகாக்கப்பட்ட பாதையின் உள்ளே PPP அமர்வை எடுத்துச் செல்கிறது, அதனால்தான் RFC 3193 தனிச் சுரங்கப்பாதைக்குப் பதிலாகப் போக்குவரத்து முறையைக் குறிப்பிடுகிறது. கிளையன்ட் லேபிள் L2TP என்கிறது, எனவே சுரங்கப்பாதையும் உள்நுழைவும் ஒரே பொறிமுறையாகத் தோன்றுகின்றன. அவை அல்ல: L2TP கட்டுப்பாட்டு இணைப்பு, வரிசைப்படுத்தல் அதை இயக்கும் இடத்தில் சுரங்கப்பாதையின் முனைகளை அங்கீகரிக்கிறது, PPP தனியாக CHAP, PAP அல்லது MS-CHAPv2 மூலம் சேவையகக் கொள்கையின்படி பயனரை அங்கீகரிக்கிறது.

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

அங்கீகாரமும் PPP-யின் முடிவு அல்ல. பயனர் ஏற்கப்பட்ட பிறகு IPCP கிளையன்ட் முகவரியையும் சேவையகம் வழங்கத் தயாராக உள்ள DNS, WINS விருப்பங்களையும் பேச்சுவார்த்தை செய்கிறது. கிளையன்ட் CHAP அல்லது MS-CHAPv2 தாண்டியும் முகவரியின்றி முடியலாம், அது PPP-க்குள் ஏற்படும் தோல்வி, வழிப்பாதைச் சிக்கல் அல்ல. IPsec இல்லாத வெறும் L2TP செல்லுபடியாகவும் பாதுகாப்பற்றதாகவும் இருக்கும், எனவே வெற்றிகரமான இணைப்பு போக்குவரத்து பாதுகாக்கப்பட்டதை ஒருபோதும் நிரூபிக்காது; சேவையகம் எதைக் கோருகிறது என்பதைச் சரிபார்க்கவும், கிளையன்ட் லேபிளை அல்ல.

முதல் காணாமற்போன கட்டத்திலிருந்து முடிவு செய்யுங்கள்

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

First thing missingWhat it meansChange this
No IKE reply on 500 or 4500The path or the listener never answeredFirewall, NAT-T forwarding, server listener
IKE runs, no IPsec associationIdentity, key, or proposal mismatchProposal and PFS set, pre-shared key, local and remote ID
Association up, no L2TP control connectionInner signalling never reached xl2tpdUDP 1701, tunnel and session sections, NAT encapsulation
Control connection up, PPP auth refusedThe user or method was rejectedCredential format, allowed auth method, account policy
PPP auth accepted, no address assignedIPCP never completedAddress pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd
Address assigned, applications failThe inner path is wrongRoutes, DNS, MTU or MSS, server forwarding

மூன்று வரிசைகள் எச்சரிக்கைக்குத் தகுதியானவை. 1701 வரிசை NAT பின்னால் உள்ள Windows கிளையன்ட்கள் பொதுவாக இறங்கும் இடம்: சங்கம் முடிகிறது, பிறகு எதுவும் வரவில்லை, காரணம் மோசமான கடவுச்சொல் அல்ல, என்காப்சுலேஷன். IPCP வரிசை வழிப்பாதைச் சிக்கலாகத் தவறாகப் படிக்கப்படுவது, ஏனெனில் Windows காணாமற்போன முகவரியை பிழை 720-இல் சுருட்டுகிறது, தட்டு சின்னம் இணைப்பு தோல்வியடைந்தது என்று மட்டும் கூறுகிறது; அந்தத் தோல்வி அங்கீகாரத்திற்குப் பிறகும் வழிப்பாதைக்கு முன்பும் உள்ளது. கடைசி வரிசை IPsec தோல்வியே அல்ல, சின்னம் துண்டிக்கப்பட்டது என்று கூறினாலும்.

அடுக்குகளைப் பிரிக்கும் கட்டளைகள்

strongSwan இயங்கும் Linux சேவையகத்தில் swanctl --list-sas நிறுவப்பட்ட சங்கங்களைச் சகாவின் அடையாளத்துடன் பட்டியலிடுகிறது, ipsec statusall பழைய strongSwan, libreswan புரவலர்களை உள்ளடக்குகிறது. அதன் கீழ் ip xfrm state கர்னலின் உண்மையான சங்கங்களைக் காட்டுகிறது, ss -lunp | grep 1701 xl2tpd எங்கே பிணைக்கப்பட்டுள்ளது என்பதை நிரூபிக்கிறது. கட்டுப்பாட்டு இணைப்புகளும் அழைப்புகளும் வருவதைப் பார்க்க xl2tpd -D-ஐ முன்னணியில் இயக்கவும், வழங்கப்படும் முறையையும் பதிலையும் காண /etc/ppp/options.xl2tpd-இல் pppd பிழைத்திருத்தத்தை இயக்கவும்.

பதிவுகள் வெற்றிகரமான அங்கீகாரத்தைக் காட்டிய பிறகு அடுத்த கேள்வி IPCP முடிந்ததா என்பது. /etc/xl2tpd/xl2tpd.conf-இன் [lns default] பிரிவில் உள்ள ip range-க்கு இன்னும் இலவச முகவரிகள் உள்ளதா, கிளையன்ட் எதிர்பார்த்தால் /etc/ppp/options.xl2tpd உண்மையில் ms-dns, ms-wins-ஐக் கொண்டுள்ளதா எனச் சரிபார்க்கவும். தீர்ந்த தொகுப்பும் காணாமற்போன DNS விருப்பமும் கம்பியில் வேறாகத் தெரிகின்றன: முதலாவது கிளையன்டை முகவரியின்றி 720-உடன் விடுகிறது, இரண்டாவது முகவரி தருகிறது ஆனால் தீர்வியைத் தரவில்லை, எனவே பெயர்கள் தோல்வியடையும், மூல முகவரிகளுக்கான ping வேலை செய்யும். இரண்டும் கடவுச்சொல்லை மீண்டும் உள்ளிடுவதால் சரிசெய்யப்படுவதில்லை.

கிளையன்டில் NetworkManager-இன் L2TP செருகுநிரல் pppd உரையாடலை இதழில் எழுதுகிறது, எனவே journalctl -u NetworkManager -b பொதுவாக சுரங்கப்பாதை மேலே, அங்கீகாரம் நிராகரிக்கப்பட்டது நிலையை சுரங்கப்பாதையே இல்லை நிலையிலிருந்து பிரிக்கிறது. Windows-இல் Get-VpnConnection சுயவிவரத்தின் உண்மையான அங்கீகார அமைப்புகளைத் தெரிவிக்கிறது, Event Viewer-இல் Application கீழ் உள்ள RasClient நிகழ்வுகள் தோல்வியடைந்த பகுதியைப் பெயரிடுகின்றன. உரையாடல் மிகவும் தெளிவற்றதாக இருந்தால் netsh ras set tracing * enable-ஐ இயக்கவும்.

பதிவுகளுக்கு ஒரு எச்சரிக்கை தேவை. போக்குவரத்து முறை IPsec-இல் உள்ளக UDP 1701 மறையாக்கப்பட்டுள்ளது, எனவே வெளி இடைமுகத்தில் உள்ள பதிவு ESP-ஐ அல்லது NAT-T கீழ் UDP 4500-ஐக் காட்டும், L2TP-ஐ சிறிதும் காட்டாது. பதிவில் 1701 இல்லாதிருப்பது எதிர்பார்க்கப்பட்டது, தடுக்கப்பட்ட துறையின் ஆதாரம் அல்ல; ESP அல்லது 4500 எண்ணிகள் நகர்கின்றனவா எனப் பாருங்கள்.

NAT, MTU மற்றும் வழிகள்: ஸ்டாக் உங்களை எங்கே தவறாக வழிநடத்துகிறது

எதுவும் அங்கீகரிக்கப்படுவதற்கு முன்பே NAT அனுமானங்களை உடைக்கிறது. ESP தனிச்சொந்த IP நெறிமுறை, எனவே மொழிபெயர்க்கும் சாதனம் சகாக்கள் உள்ளடக்காதபோது அதைத் தூக்கி எறிகிறது; UDP 4500 அதை வழங்குகிறது. தானே வீட்டு ரவுட்டர் அல்லது மேக NAT நுழைவாயிலுக்குப் பின்னால் இருக்கும் Windows சேவையகத்தில் IPsec கட்டம் பிழை 789-உடன் தோல்வியடைகிறது, PolicyAgent விசையின் கீழ் AssumeUDPEncapsulationContextOnSendRule 2 ஆக அமைக்கப்பட்டு இயந்திரம் மறுதொடக்கம் செய்யப்படும் வரை, தோல்வி மூடப்பட்ட துறையிலிருந்து வேறுபடுத்த முடியாததாகவே இருக்கும். NAT பின்னால் உள்ள கிளையன்ட்கள் எளிது: சேவையகத்தில் பொது முகவரி இருந்தால் UDP 4500-இல் NAT-T அவர்களை எடுத்துச் செல்கிறது, அந்த மதிப்பு ஈடுபடாது.

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

சான்றுகளைத் தொடுவதற்கு முன் சரிபார்ப்புப் பட்டியல்

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

  1. சங்கம் இரு முனைகளிலும் உள்ளதை உறுதிசெய்யுங்கள், இணைந்த லேபிளால் அல்ல, சகாவின் அடையாளத்தால் பொருத்தப்பட்டது.
  2. UDP 1701 xl2tpd-ஐ அடைவதை உறுதிசெய்யுங்கள்; அழைப்பில்லாத சங்கமே உங்கள் தோல்வி.
  3. கடவுச்சொல் தவறு என்று கருதும் முன் PPP-யின் தீர்ப்பையும், அங்கீகரிக்கப்பட்டால் IPCP-யின் முடிவையும் படியுங்கள்.
  4. இப்போதுதான் சேவையகம் எதிர்பார்க்கும் வடிவத்தில் சான்றுகளை மீண்டும் உள்ளிடுங்கள், ஏனெனில் களப் பூர்வொட்டு கணக்கை மாற்றுகிறது.
  5. இன்னும் தோல்வியடைந்தால் இரு முனைகளையும் சீரமைக்கப்பட்ட நேர முத்திரைகளுடன் பதிவுசெய்து கட்டம் கட்டமாக ஒப்பிடுங்கள்.

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

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