VPN को कुन चरण असफल भयो: IPsec, L2TP नियन्त्रण वा PPP प्रमाणीकरण
अन्तिम सफल चरण पत्ता लगाउनुहोस् र केवल त्यही तह सुधार्नुहोस्: IPsec, L2TP नियन्त्रण च्यानल, PPP प्रमाणीकरण वा ठेगाना बाँडफाँट।
तपाईंले पासवर्ड बदल्नुभयो र केही सर्यो, किनकि समस्या कहिल्यै 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 missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, 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 कस्नुहोस्। विभाजित सुरुङ राउटिङ अर्को ठग हो; गलत मास्कसँग पठाइएको सबनेटले सुरुङ स्वस्थ र एउटा अनुप्रयोग अगम्य राख्छ। निजी होस्टनामले आफ्नै पाइला थप्छ: क्वेरी स्थानीय समाधानकर्ताबाट बाहिर जान्छ भने कुनै पनि राउट परीक्षण हुनुअघि नै नाम समाधान हुन असफल हुन्छ।
प्रमाणहरू छुनुअघिको जाँचसूची
सूची क्रमैसँग काम गर्नुहोस् र पहिलो असफल वस्तुमा रोकिनुहोस्। प्रत्येक पाइला सस्तो छ, र प्रत्येकले सम्पादनको एउटा पूरा वर्ग बाहिर राख्छ।
- संलग्नता दुवै छेउमा छ भनी पुष्टि गर्नुहोस्, जोडिएको लेबल होइन, साझेदारको ओळखले मिलाएर।
- UDP 1701 xl2tpd सम्म पुग्छ भनी पुष्टि गर्नुहोस्; कल नभएको संलग्नता नै तपाईंको विफलता हो।
- पासवर्ड गलत छ भन्ने मान्नुअघि PPP को निर्णय, र प्रमाणित भए IPCP को नतिजा पढ्नुहोस्।
- अब मात्र सर्भरले अपेक्षा गर्ने ढाँचामा प्रमाणहरू फेरि हाल्नुहोस्, किनकि डोमेन उपसर्गले खाता बदल्छ।
- अझै असफल भए दुवै छेउ संरेखित समय-छापसहित क्याप्चर गरी चरणैपिच्छे तुलना गर्नुहोस्।
दोस्रो पाइलामा रोकिनु भनेको पथ वा इन्क्याप्सुलेशन समस्या, र पासवर्डको कुनै सम्पादनले त्यसलाई सार्दैन। तेस्रो पाइलामा रोकिनु भनेको लगले सुधार्नुपर्ने विधि वा ठेगाना-पूल पहिले नै नाम लिएको छ। जसरी भए पनि अर्को परिवर्तन तपाईंले न्यायोचित ठहराउन सक्ने हुन्छ, र कहिल्यै संलग्न नभएका सेटिङमा घुम्न छोड्नुहुन्छ।