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 एक एक करून, त्या क्रमाने खात्री करा। तेव्हा गहाळ विचारणा कोडे राहणे थांबते आणि खरोखर काम करता येणाऱ्या यादीची दुसरी ओळ बनते। तीच यादी तुम्ही नेटवर्क टीमला देता, ज्यांना अन्यथा न सुरू झालेल्या डेमनमध्ये राहणाऱ्या दोषासाठी फायरवॉल तपासायला सांगितले जाईल।