PPTP மற்றும் L2TP/IPsec பயனர் பெயர் கேட்பதற்கு முன்பே நிற்பது ஏன்?
பயனர் பெயர் கேட்பு வராதது PPP ஒருபோதும் தொடங்கவில்லை என்பதாகும், எனவே பிழை போக்குவரத்து, விசை பரிமாற்றம் அல்லது சுரங்கப்பாதை அமைப்பில் உள்ளது. மீண்டும் நிறுவுவதற்கு முன் நிலைகளின் வரிசையைச் சரிபார்க்கவும்.
பயனர் பெயர் கேட்பு வராதது ஒரு கண்டறியும் பரிசு: PPP இன்னும் தொடங்கவில்லை, எனவே கணக்கு, கடவுச்சொல் மற்றும் களக் கொள்கை இன்னும் கேட்கப்படவில்லை. PPTP அல்லது L2TP/IPsec இணைப்பில் சுரங்கப்பாதை உள்ளதாகவும் சேவையகம் PPP அமர்வைத் தொடங்கியதாகவும் இருந்த பிறகே வாடிக்கையாளர் சான்றுகளைக் கேட்கிறது. அந்தத் தருணத்திற்கு முன் தோல்வியடையக்கூடிய அனைத்தும் போக்குவரத்து, விசை பரிமாற்றம் அல்லது சுரங்கப்பாதை அமைப்பு ஆகும், இது «VPN கெட்டுப்போய்விட்டது» என்பதை விட மிகச் சிறிய பகுதி.
இல்லாத கேட்பு பிழையை மூன்று நிலைகளாகக் குறைக்கிறது
கண்ணுக்குத் தெரியும் வகையில் வெற்றியடைந்த கடைசி நிலையை எழுதுங்கள், ஏனெனில் ஒவ்வொன்றுக்கும் வேறு உரிமையாளரும் வேறு தீர்வும் உள்ளன. இரண்டு நிலைகள் முன்பே சிக்கியிருக்கும்போது கணக்கு அமைப்புகளை ஊகிப்பது ஒரு மதியம் காணாமல் போகும் வழியாகும்.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
கேட்பு இல்லாமல் காலாவதியாகும் வாடிக்கையாளருக்கு ஒருபோதும் IPsec சங்கமைப்பு கிடைக்கவில்லை, எனவே பிழை IKE இல் உள்ளது அல்லது உங்கள் பொதிகள் நுழைவாயிலை அடைகின்றனவா என்பதில் உள்ளது. சான்றுகளைச் சரிபார்ப்பதாகத் தெரிவித்து பின்னர் விழும் வாடிக்கையாளர், செய்தி குறிப்பதை விட முன்னேறியுள்ளது. கேட்பைத் தொடர்ந்து மறுப்பு வந்தால் அது PPP அங்கீகாரம், அதன் இடம் கணக்கு பற்றிய கட்டுரையில், இந்தக் கட்டுரையில் அல்ல.
முதல் நிலை: தீர்வரிசை அமைதியாகக் கைவிடும் நெறிமுறை
PPTP அதன் கட்டுப்பாட்டு வழித்தடத்திற்கு TCP 1723 மற்றும் தரவு பாதைக்கு IP நெறிமுறை 47 தேவைப்படுகிறது, இரண்டும் தனித்தனியாகப் பயணிக்கின்றன. பல வலையமைப்புகள் 1723 ஐ முன்னனுப்பி நெறிமுறை 47 ஐக் கைவிடுகின்றன, இதனால் பேச்சுவார்த்தை நடத்தி பின்னர் எதையும் சுமக்காத சுரங்கப்பாதை உருவாகிறது. NAT செய்யும் திசைவியருக்கு GRE ஆதரவுள்ள கடந்து செல்லும் வழியும் தேவை, IPv6 மட்டுமே கொண்ட அணுகல் பாதை எந்த அமைப்பிலும் PPTP ஐச் சுமக்க முடியாது.
IPsec மேலான L2TP IKE க்கு துறை 500 ஐயும் NAT கடக்க துறை 4500 ஐயும் செலவிடுகிறது, பின்னர் L2TP போக்குவரத்தையே 1701 இல் சுருட்டுகிறது, சங்கமைப்பு உருவானதும் ESP பாதுகாக்கப்பட்ட சுமையைக் காவுகிறது. கட்டுப்பாட்டுத் துறைகள் இரண்டை அனுமதித்து ESP ஐ அனுமதிக்காவிட்டால், தலைப்பில் உள்ள அறிகுறியே கிடைக்கும்: தெரியும் முன்னேற்றம், பின்னர் எந்தச் சான்று உரையாடலுக்கும் முன் இறந்த வாடிக்கையாளர். தொலைபேசி ஹாட்ஸ்பாட்டில் இருந்து சோதிப்பது வாடிக்கையாளர் சிக்கலைப் பாதைச் சிக்கலில் இருந்து பிரிக்கும் மலிவான வழி.
இரண்டாம் நிலை: விசை அல்லாத விசை, வழங்கப்படாத முன்மொழிவு
பொருந்தாத முன்பங்கு விசை விரைவாகவும் அமைதியாகவும் தோல்வியடைகிறது, வழக்கமான வடிவம் திரையில் சரியாகத் தெரியும் ஆனால் ஒட்டப்பட்ட வரி முறிவு அல்லது இறுதியில் இடைவெளி கொண்ட விசையாகும். Linux வாடிக்கையாளரில் உரையாடல் கட்டாயம் உண்மையின் மூலமாக இருக்க வேண்டியதில்லை: NetworkManager இன் L2TP செருகுநிரல் ரகசியங்களை /etc/ipsec.d/ கீழ் உள்ள கோப்புகளில் வைத்திருக்கிறது, /etc/ipsec.secrets இன்னும் சேர்க்கும் பழைய இணைப்பு கோப்பு நீங்கள் இப்போது தட்டச்சு செய்ததற்குப் பதிலாகப் பயன்படுத்தப்படும். அந்தக் கோப்பைப் பாதுகாப்பான இடத்திற்கு நகலெடுத்து, சேர்ப்புப் பாதையிலிருந்து அகற்றி, பின்னர் விசையைக் கையால் மீண்டும் தட்டச்சு செய்யுங்கள்.
இந்த நிலையின் மறு பாதி முன்மொழிவு. இரு முனைகளும் ஒரே 1ஆம் கட்ட அல்காரிதம் தொகுப்பிலும் — மறையாக்கம், நேர்மை மற்றும் Diffie-Hellman குழு — 2ஆம் கட்டத்திற்குப் பொருந்தும் ESP மாற்றங்களிலும் உடன்பட வேண்டும், இல்லையெனில் சங்கமைப்பே உருவாகாது. 3DES, SHA1 மற்றும் MODP1024 மட்டும் வழங்கும் நுழைவாயில் வலுவான அல்காரிதங்களுக்கு அமைக்கப்பட்ட வாடிக்கையாளரை மறுக்கும், அதன் பதிவு மறுக்கப்பட்ட மாற்றத்தின் பெயரைக் கூறும். சேவையை மீண்டும் தொடங்குவதற்குப் பதிலாகப் பதிவைப் படித்தால் பதிவே முரண்பாட்டின் பெயரைக் கூறும். மன்ற இழையிலிருந்து அல்காரித வரிசையை நகலெடுப்பதற்குப் பதிலாக, நுழைவாயிலை எந்த மாற்றங்களில் உண்மையில் பேச்சுவார்த்தை நடத்தும் என்று கேளுங்கள்: அதன் முகவரிக்கு இலக்கு வைக்கப்பட்ட ike-scan அது பேச்சுவார்த்தை நடத்தும் மாற்றங்களைத் திருப்பித் தரும். ஒரே வழங்கல் உங்கள் கொள்கை இனி அனுமதிக்காத மறையாக்கமாக இருந்தால், திருத்தம் வாடிக்கையாளரைத் தாழ்த்துவதில் அல்ல, நுழைவாயிலில் உள்ளது.
Windows இல் விசையும் அங்கீகார முறையும் VPN சுயவிவரத்தில் உள்ளன, முரண்பாடு சான்று கேட்புக்குப் பின்னர் அல்ல, முன்னரே தெரியும். பெறுநர் Windows Server ஆக இருக்கும்போது, தொலை அணுகல் பங்கு நிறுவப்பட்டிருப்பதையும், சான்றிதழ் வாடிக்கையாளர்கள் இணைக்கும் பெயருடன் பொருந்துவதையும், எந்தத் துறை வடிகட்டியும் மேலே உள்ள நெறிமுறைகளை விடக் குறுகலாக இல்லாததையும் உறுதிசெய்யுங்கள்.
மூன்றாம் நிலை: சுரங்கப்பாதை உள்ளது, PPP தொடங்குவதில்லை
IKE முடிந்த பிறகும் கேட்பு வரவில்லை என்றால் தீர்வரிசை அல்ல, சுரங்கப்பாதை டீமனைப் பாருங்கள். L2TP க்கு UDP 1701 இல் கேட்கும் ஒன்று தேவை — Linux இல் xl2tpd அல்லது kl2tpd, Windows இல் தொலை அணுகல் சேவை — நிறுவப்பட்டு நிறுத்தப்பட்ட சேவை வாடிக்கையாளர் பக்கத்திலிருந்து வீசப்பட்ட பொதி போலவே தெரியும். நீங்கள் ஏற்கனவே சரிபார்த்த விதிகளை மீண்டும் திறப்பதற்கு முன் கேட்பவரைச் சரிபார்க்கவும். பின்னர் PPP பேச்சுவார்த்தை நடத்த வேண்டும், முதல் LCP பரிமாற்றமே அமைதியான தோல்வி பொதுவாக இறங்கும் இடம்.
இந்த நிலையில் ஒரு பொறி வலையமைப்புப் பிழையே அல்ல: Windows ஒரு குறிப்பிட்ட VPN வகையின் ஒரு இணைப்பை மட்டுமே ஒரே நேரத்தில் அனுமதிக்கிறது, எனவே இரண்டாவது முயற்சி பிழை 937 ஐத் திருப்பித் தரும், «இந்த வகையின் மற்றொரு இணைப்பு பயன்பாட்டில் உள்ளது». இது உள்ளூர் விதி, அதைத் தவிர்க்கும் வழி வேறு சாதனம், வேறு சுரங்கப்பாதை வகை, அல்லது ஏற்கனவே உள்ள ஒரே இணைப்பைப் பகிர்வது.
ஊகிப்பதற்குப் பதிலாக நிலைகளின் வரிசையில் பதிவைப் படியுங்கள்
வாடிக்கையாளரை நிறுத்தி, மீண்டும் தொடங்கி, கூறுகள் பதிவு எழுதும் வரிசையில் படியுங்கள். அதாவது முதலில் IPsec டீமன் — strongSwan அல்லது Libreswan, எது என்பதை ipsec --version கூறும் — பின்னர் L2TP டீமன், பின்னர் pppd. தோல்விக்கு முன் இறுதியாக எழுதிய கூறே ஆராய வேண்டிய நிலையைக் குறிக்கிறது, ஏனெனில் வரிசையில் அதற்குப் பின் வருவது எதுவும் இயங்கவே இல்லை.
சேமித்த அமர்வுக்குப் பதிலாகப் புதிய இணைப்பில் சரிபார்க்கவும், ஏனெனில் தேக்கத்திலிருந்து மீண்டும் இணையும் வாடிக்கையாளர் பரிமாற்றத்தின் பகுதிகளைத் தவிர்த்து பழைய முடிவை மீண்டும் உருவாக்கலாம். அணுகல், விசை பரிமாற்றம், சுரங்கப்பாதை மற்றும் PPP ஆகியவற்றை ஒவ்வொன்றாக, அதே வரிசையில் உறுதிசெய்யுங்கள். அப்போது இல்லாத கேட்பு புதிராக இருப்பதை நிறுத்தி, உண்மையில் செயல்படுத்தக்கூடிய பட்டியலின் இரண்டாம் வரியாகிறது. அந்தப் பட்டியலே நீங்கள் வலையமைப்புக் குழுவிடம் தருவது, இல்லையெனில் தொடங்கப்படாத டீமனில் வாழும் பிழைக்காகத் தீர்வரிசையைச் சரிபார்க்கச் சொல்லப்பட்டிருப்பார்கள்.