VPN पोर्ट शांत? लिसनर, बाइंड पत्ता किंवा होस्ट फायरवॉल
थांबलेली सेवा आणि फायरवॉलचा ड्रॉप वेगळ्या दुरुस्तीची मागणी करतात. आधी स्थानिक सॉकेट तपासा, नंतर एका अधिकृत बाह्य प्रयत्नाची लॉगशी जुळणी करा.
VPN त्याच्या पोर्टवर काहीच उत्तर देत नाही, आणि दोन संभाव्य कारणांना विरुद्ध दुरुस्ती लागते: एकतर कोणत्याही प्रक्रियेने सॉकेट उघडले नाही, किंवा सॉकेट आहे आणि मशीनच्या मध्ये काहीतरी पॅकेट थांबवत आहे. एकच आदेश त्या प्रश्नाचा पहिला अर्धा भाग निकाली काढतो, म्हणूनच तो कोणत्याही फायरवॉल नियमाला हात लावण्यापूर्वी येतो. खालील क्रम प्रत्येक टप्प्यावर एक स्पष्टीकरण काढून टाकतो, दुसरी शक्यता जोडत नाही. या दोन्हींमध्ये अंदाज लावणे हेच दहा मिनिटांचे निदान संपूर्ण संध्याकाळ बनवते.
तुम्ही सर्व्हरवर लॉग इन करू शकता आणि क्लायंट स्कॅनर नसून खरा प्रोफाइल आहे असे गृहीत धरा. दोन्ही गृहीतके महत्त्वाची आहेत, कारण सामान्य प्रोब प्रोटोकॉल-विशिष्ट प्रश्नाचे उत्तर देऊ शकत नाही.
सॉकेट अस्तित्वात आहे का
सेवा स्वतःबद्दल काय सांगते त्यापासून सुरुवात करा: ती वर आली का आणि, अधिक उपयुक्त, तिची पहिली स्टार्टअप त्रुटी काय होती. पार्स अपयश, गहाळ की किंवा बाइंड त्रुटी लिसनरला कधीच अस्तित्वात येऊ देत नाही, आणि प्रक्रिया इतक्या शांतपणे बाहेर पडू शकते की स्थिती ओळ संदिग्ध वाचली जाते. स्वतःला सक्रिय म्हणणारे युनिट एकटे पुरावा नाही, कारण मुख्य प्रक्रिया जिवंत असू शकते तर पोर्ट बाइंड करायचे असलेले घटक आधीच हार मानून गेले असू शकते.
systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp
सॉकेटची यादी हीच ती वस्तुस्थिती आहे जिच्यावर उर्वरित निदान उभे आहे. फक्त पोर्ट नाही तर स्थानिक पत्त्याचा स्तंभ वाचा, कारण त्याच स्तंभात लूपबॅक बाइंड आणि चुकीच्या इंटरफेसवरील बाइंड दिसतात. 127.0.0.1 वर असलेला लिसनर अगदी व्यवस्थित चालत आहे आणि तरीही तुमच्या लॅपटॉपला अदृश्य आहे.
सॉकेट कोणत्या पत्त्यावर आणि कोणत्या कुटुंबावर उत्तर देतो
दोन चुका क्लायंटकडून सारख्याच दिसतात आणि बहुतेक "पोहोचत नाही" अहवालांचे स्पष्टीकरण देतात. लूपबॅक पत्त्यावर बांधलेला सर्व्हर दुसऱ्या मशीनकडून रहदारी कधीही घेत नाही, आणि फक्त IPv4 पत्त्यावर बांधलेला सर्व्हर त्याच होस्टच्या IPv6 पत्त्यावर डायल करणाऱ्या क्लायंटला कधीही उत्तर देत नाही. धोरणाबद्दल काहीही गृहीत धरण्यापूर्वी सॉकेट तक्त्यातील पत्ता क्लायंट प्रत्यक्षात डायल करत असलेल्या पत्त्याशी अक्षरशः तुलना करा.
यादी एका पोर्टपुरती मर्यादित ठेवल्यास होस्टवर अनेक सेवा चालत असतानाही ती वाचनीय राहते. sport फिल्टर पोर्ट तुम्ही तपासत असलेल्या वाहतुकीसह घेतो:
ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'
प्रोटोकॉल स्तंभ संपूर्ण उत्तर बदलतो
सॉकेट तक्ता पोर्टसोबतच प्रोटोकॉलवरही किल्लीबद्ध आहे, आणि ह्या दोन स्वतंत्र नोंदी आहेत. 1194 वर TCP ला उत्तर देणारी सेवा UDP 1194 वर काही ऐकत आहे का याबद्दल काहीही सांगत नाही, आणि क्लायंट नेहमी यापैकी एकच वापरेल. सर्व्हर कॉन्फिगरेशन कोणती वाहतूक निवडते आणि क्लायंट प्रोफाइल कोणती पाठवते याची खात्री करा, मग तीच ओळ शोधा.
UDP ला दुसरा पट आहे: अनुमत न केलेला प्रोब ही अशी त्रुटी नाही जिचे उत्तर सेवेला द्यावे लागते. पोर्ट शांत असल्याचे नोंदवणारे स्कॅन सेवेची उपलब्धता नव्हे तर तिची संयमशीलता मोजते, म्हणून खऱ्या क्लायंट आणि प्रोफाइलने तपासा.
एक प्रयत्न, पाहण्यासाठी तीन जागा
मंजूर क्लायंटवरून नेमका एक प्रयत्न करा आणि वेळ सेकंदापर्यंत लिहून ठेवा. मग त्या कालावधीसाठी तीन स्रोत वाचा: पुरवठादाराचा नेटवर्क नियम किंवा कन्सोल, होस्टचे फायरवॉल काउंटर किंवा लॉग, आणि सेवेचा स्वतःचा लॉग. एकदाच हे करणे हेच तीन वृत्तांत तुलनीय बनवते, आणि ज्याची वेळमुद्रा कोणीही नोंदवली नाही अशा प्रयत्नाची पुनरावृत्ती करण्यापेक्षा ते स्वस्त पडते.
दोन निकाल विरुद्ध दिशांना निर्देश करतात. जर एकही पॅकेट होस्टपर्यंत पोहोचले नाही, तर मार्ग ते टाकून देत आहे आणि लिसनर अप्रस्तुत आहे. जर पॅकेट सॉकेटपर्यंत पोहोचले आणि सेवेने ते नाकारले, तर मार्ग ठीक आहे आणि उत्तर प्रोटोकॉल, क्रिप्टोग्राफी किंवा ओळखपत्रांमध्ये आहे. आधीच जोडणी स्वीकारलेल्या सेवेसाठी पोर्ट उघडल्यास पुढील निदान सोपे नव्हे, कठीण होते.
नियम बदलण्यापूर्वी टप्प्याला नाव द्या
सुरू होणारी चर्चा आणि अयशस्वी होणारे प्रमाणीकरण ही एकच बिघाड आहे, आणि अग्रेषण थांबत असताना उभा राहणारा बोगदा पूर्णपणे दुसरा आहे. आधी टप्प्याला नाव दिल्यास दुरुस्ती अरुंद राहते: ओळखपत्रांची अडचण फायरवॉल नियमाने सुटत नाही, आणि डेटा-मार्गाची अडचण रीस्टार्टने सुटत नाही.
प्रश्नाचे उत्तर देणारे सर्वात अरुंद निदान वापरा. प्रशासकाच्या नियंत्रणाखाली एका पोर्टवर तात्पुरते पॅकेट निरीक्षण हे योग्य साधन आहे; संपूर्ण फायरवॉल बंद करणे नाही, कारण निकालाला जबाबदार धरणे अशक्य होते. ss चे दस्तऐवज वर वापरलेल्या फिल्टरांचा समावेश करते, आणि हे कोणत्याही कॅप्चरपेक्षा स्वस्त पहिले पाऊल आहे. दोन शाखांपैकी कोणती सिद्ध केली ते नोंदवा, आणि पुढील घटना ज्ञात उत्तरापासून सुरू होते.