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 एक-एक गरी, त्यही क्रममा पुष्टि गर्नुहोस्। तब अनुपस्थित सोधपुछ रहस्य रहन छोड्छ र साँच्चै काम गर्न सकिने सूचीको दोस्रो पङ्क्ति बन्छ। त्यही सूची तपाईंले नेटवर्क टोलीलाई दिनुहुन्छ, जसलाई अन्यथा नचलेको डेमनमा बस्ने त्रुटिका लागि फायरवाल जाँच्न भनिने थियो।