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