एकाच राउटरमागे फक्त एकच VPN क्लायंट का जोडला जातो

दोन लॅपटॉप एकाच घरगुती नेटवर्कवर आहेत, आणि कार्यालयाचा VPN त्यातील नेमका एकच स्वीकारतो। दुसरा एकतर वेळ संपतो किंवा पहिला जोडणी तोडेपर्यंत थांबतो, आणि दोन्ही प्रयत्नांमध्ये कुणीही क्लायंट सेटिंगला हात लावला नाही। लॉगिन तपशील तेच आहेत जे एक मिनिटापूर्वी चालले होते, आणि हाच प्रमाणीकरण ही अयशस्वीता नाही याचा सुगावा आहे। तीन यंत्रणा हा नमुना निर्माण करतात, आणि तुम्हाला कोणाचा सामना करावा लागत आहे हे सर्व्हरचाच लॉग सांगतो।

क्लायंटला हात लावण्यापूर्वी गेटवेचा लॉग वाचा

दोन्ही प्रयत्नांची सर्व्हरची नोंद पहिल्या प्रश्नाचे उत्तर देते, आणि तीनपैकी एका पद्धतीने उत्तर देते। दुसरा प्रयत्न त्या लॉगमध्ये कधीही दिसत नसेल, तर पॅकेट श्रोत्यापर्यंत पोहोचलेच नाही, आणि समस्या घरगुती राउटरची किंवा पुरवठादाराच्या मार्गाची आहे। लॉग एखादा प्रयत्न नोंदवून तो नाकारत असेल, तर बोगदा पोहोचला आहे, म्हणजे प्रश्न ओळख, परवाना किंवा सत्र मर्यादेचा आहे, तारेवरच्या कशाचाही नाही। लॉग यशस्वी सत्र नोंदवत असताना क्लायंट अजूनही अयशस्वीता कळवत असेल, तर परतीचा मार्ग किंवा दोन क्लायंटना एकच बोगदा पत्ता दिला जातो का ते पाहा।

फोनचा हॉटस्पॉट ती कुटुंबे स्वस्तात वेगळी करतो: पहिला जोडलेला असताना दुसरा क्लायंट मोबाइल डेटावर चालवा। तिथले यश घरगुती नेटवर्ककडे निर्देश करते, आणि तिथली तीच अयशस्वीता गेटवेकडे निर्देश करते, ज्यामुळे राउटर निर्दोष राहतो। कोणताही निकाल एकटा निर्णायक नाही, पण प्रत्येक एका प्रयत्नात शोधक्षेत्राचा अर्धा भाग काढून टाकतो।

काहीही बदलण्यापूर्वी निकाल लिहून ठेवा, कारण लॉगचे तीन निकाल तीन संबंध नसलेल्या दुरुस्त्यांकडे नेतात। तीनपैकी कोणता पाहिला हे सांगणारी टिप क्लायंट त्रुटीच्या स्क्रीनशॉटपेक्षा जास्त मूल्यवान आहे।

राउटर GRE आणि NAT-T सोबत काय करतो

PPTP हा नेहमीचा गुन्हेगार आहे: नियंत्रण वाहिनी TCP 1723 आहे तर माहितीचा मार्ग GRE, म्हणजे IP प्रोटोकॉल 47। अनेक ग्राहक राउटर एकच नियंत्रण जोडणी पाहणाऱ्या PPTP सहाय्यकासह येतात, त्यामुळे त्याच NAT मागील दुसरा क्लायंट आपली नियंत्रण वाहिनी उघडतो आणि नंतर माहितीचा मार्ग अजिबात मिळत नाही। 47 क्रमांकाचा TCP पोर्ट फॉरवर्ड केल्याने GRE साठी काहीही होत नाही, कारण GRE हा पोर्ट नाही, प्रोटोकॉल क्रमांक आहे।

L2TP IPsec वर रचनेमुळेच वेगळे वर्तन करते: IKE UDP 500 वापरते, NAT ओलांडणी संरक्षित पेलोड UDP 4500 वर हलवते, आणि एन्कॅप्स्युलेशन एका पत्त्यामागील अनेक क्लायंटना त्याच गेटवेपर्यंत पोहोचता यावे म्हणूनच आहे। ती रचना गेटवे किंवा मधल्या पेटीला प्रत्येक पत्त्यासाठी सत्र मर्यादा लादण्यापासून थांबवत नाही, आणि सोफ्यावरून दोन्ही अयशस्वीता सारख्याच दिसतात। SoftEtherच्या स्वतःच्या प्रोटोकॉलमध्येही हाच प्रकारचा प्रश्न आहे: चालणाऱ्या पास-थ्रूशिवाय राउटर स्थानिक नेटवर्कमधून पहिल्या क्लायंटला आत घेतो आणि दुसऱ्याला टाकून देतो। राउटरचा ALG किंवा पास-थ्रू स्विच दोन्ही स्थितींमध्ये तपासा, कारण जुन्या क्लायंटसाठी लिहिलेला सहाय्यक आजचा क्लायंट पाठवत असलेली पॅकेट खराब करू शकतो।

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

वाहतूक मर्यादेसारख्या दिसणाऱ्या ओळख मर्यादा

राउटर हा एकमेव संशयित नाही, आणि लॉग त्याला पर्यायापासून वेगळा करतो। OpenVPN सर्व्हर सामाईक नाव एका बोगदा पत्त्याला जोडतो तेव्हा दोन्ही उपकरणांना तो पत्ता मिळतो, आणि duplicate-cn शिवाय नवीन सत्र जुन्याला बाहेर ढकलते। तो पर्याय सुरू केल्याने दोन्ही जोडलेली राहतात पण त्यांच्याकडे एक ओळख, एक प्रमाणपत्र आणि एक रद्द करण्याचा निर्णय उरतो, जे दिसते त्यापेक्षा वाईट आहे। मग दुसरे उपकरण कधीही स्वतंत्रपणे रद्द करता येत नाही, त्यामुळे सोयीचा स्विच पुढे लागू शकेल असे नियंत्रण शांतपणे काढून टाकतो।

सर्व्हरची जर्नल आणि त्याची स्थिती फाइल एकत्र वाचा, कारण एक प्रमाणीकरणाचा निर्णय दाखवते आणि दुसरी आता कोण जोडलेले आहे ते। एकच सामाईक नाव आणि एक व्हर्च्युअल पत्ता वाटून घेणाऱ्या दोन नोंदी राउटर मर्यादा नव्हे, तर ओळखीची टक्कर सिद्ध करतात। व्यापारी गेटवे स्वतःच्या मर्यादा जोडतात, जसे एकाच वेळी एकच सत्र परवानगी देणारी योजना, परवान्यांची संख्या, किंवा प्रत्येक सार्वजनिक पत्त्याला एक सत्र परवानगी देणारा नियम, आणि राउटरची कोणतीही सेटिंग यातले काहीही बदलत नाही।

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

दुरुस्ती लॉग नोंदीशी जुळवा

लॉगमधील नकारासाठी प्रत्येक उपकरणाचे वेगळे लॉगिन तपशील, सेवा चालवणाऱ्याकडून अधिक मर्यादा, किंवा एका मशीनसाठी दुसरा गेटवे टोक आवश्यक असतो। कोणताही दुसरा प्रयत्न कधीही सर्व्हरपर्यंत पोहोचत नसेल, तर टिकाऊ दुरुस्ती म्हणजे प्रोटोकॉल फॉरवर्ड करणारा आणि एकापेक्षा जास्त सत्र ठेवणारा राउटर, किंवा राउटर चांगल्या प्रकारे हाताळत असलेली वाहतूक, जसे एकच TCP किंवा UDP प्रवाह। यातून निवडणे हा हार्डवेअरच्या आयुष्याचा निर्णय आहे, क्लायंट सेटिंगचा नाही।

चालणाऱ्या उपकरणाची प्रोफाइल दुसऱ्या मशीनवर कॉपी करून काम संपले असे मानू नका। त्यामुळे जोडणीचा प्रश्न प्रवेश नियंत्रणाचा प्रश्न बनतो, कारण हरवलेला लॅपटॉप आता वापरात असलेल्या प्रतीपासून वेगळा ओळखता येत नाही। त्यामुळे मूळ दोषही लपतो, जो तिसरे उपकरण दिसते त्या क्षणी परत येतो।

दोन जिवंत सत्रांची पडताळणी

दोन्ही उपकरणे एकाच वेळी जोडा, प्रत्येकावर इच्छित ॲप चालवा, मग त्यातील एक पुन्हा जोडा आणि पुन्हा करा। क्षणभर दिसणारा दुसरा चिन्ह ट्रॅफिकबद्दल काहीही सिद्ध करत नाही, आणि दहा मिनिटांनी पडणारे सत्र हे वेगळ्या मालकाचे वेगळे दोष आहे। सर्व्हर शेवटी जे कळवतो त्याची वापरकर्त्यांनी जे पाहिले त्याशी तुलना करा, कारण ही दोन वर्णने बहुतेक वेळा जुळत नाहीत।

दोन्ही सत्रे टिकली आणि ट्रॅफिक वाहून नेले, तर उपाय टिकतो, आणि सुरुवातीला लिहिलेली टिप काय चुकले होते याची नोंद बनते। फक्त एकच टिकले, तर पहिल्या पायरीवर परत जाऊन आता तीन लॉग निकालांपैकी कोणता आहे ते तपासा, कारण उत्तर बदलले असू शकते। राउटरचे सहाय्यक दुसऱ्या नेटवर्कवर पुन्हा दिसणारी समस्या लपवू शकतात, तर प्रत्येक पत्त्यासाठीची मर्यादा उपकरणाचा नव्हे, वापरकर्त्याचा पाठलाग करते। दुसऱ्या नेटवर्कवरून चाचणी करणे म्हणजे यातील तुम्ही खरोखर काय दुरुस्त केले हे जाणून घेण्याचा सर्वात स्वस्त मार्ग।