VPN पोर्ट 53 वर अडवले आहे असे सांगणारे अहवाल वेगवेगळ्या कारणांमुळे अयशस्वी होणाऱ्या तीन निरीक्षणांची भरड धरतात। एंडपॉइंटचे नाव सोडवणे हे कोणतेही टनल अस्तित्वात येण्यापूर्वी घडते, एन्क्रिप्टेड ट्रान्सपोर्ट हा वेगळा संवाद आहे, आणि त्यानंतर केलेले DNS प्रश्न हे तिसरे आहे। प्रत्येकाची स्वतःची अयशस्वी ओळख आहे, आणि त्यापैकी एकच DNS शी संबंधित आहे।

काहीही बदलण्यापूर्वी पॅकेट्स त्यांच्या उद्देशानुसार वेगळे करा, कारण उपाय टप्प्याचे अनुसरण करतो।

तीन संवाद, एक पोर्ट क्रमांक

पहिला संवाद एंडपॉइंटसाठी नावाचा शोध आहे: तुमचे मशीन त्याच्या संरचित रिझॉल्व्हरला विचारते की vpn.example.com कुठे आहे, आणि ते उत्तर क्लायंट एकही टनल पॅकेट पाठवण्यापूर्वी सामान्य DNS वर येते। दुसरा म्हणजे OpenVPN ट्रान्सपोर्ट स्वतः, जो शोधाने दिलेल्या पत्त्याशी प्रोफाइलने नमूद केलेल्या प्रोटोकॉल आणि पोर्टवर जोडतो। तिसरा टनल उभे राहिल्यानंतर घडतो, जेव्हा ॲप्लिकेशन्स नावे मागतात आणि पाठवलेली रिझॉल्व्हर सेटिंग्ज कोण उत्तर देईल हे ठरवतात।

हे तीन स्वतंत्रपणे यशस्वी किंवा अयशस्वी होऊ शकतात। क्लायंट त्याचे एंडपॉइंट उत्तम प्रकारे सोडवू शकतो आणि तरीही श्रोत्यापर्यंत पोहोचण्यात अयशस्वी होऊ शकतो, आणि DNS सेटिंग्ज कधीही न आल्यामुळे प्रत्येक अंतर्गत नावाचा शोध अयशस्वी होत असतानाही तो टनल उभारू शकतो।

ConversationWhen it happensWhat has to be true
Endpoint lookupBefore the client contacts a hostnameAn underlying resolver path can answer for the endpoint name
OpenVPN transportDuring tunnel establishmentThe gateway listens on its configured transport, address and port, and nothing filters it
Application DNSDuring or after the protected sessionA resolver the client can reach, plus routing that carries its queries

तक्ता वर्णन म्हणून नव्हे तर तपासणी यादी म्हणून वाचा। एंडपॉइंटचे नाव सुटले नाही तर पुढे काहीही चालू शकत नाही, आणि टनल कधीही सुरू होत नाही।

पोर्ट क्रमांक ॲप्लिकेशनला नाव देत नाही

पोर्ट 53 पारंपरिकपणे DNS वाहतो, आणि OpenVPN ऑपरेटर तिथे श्रोताही प्रकाशित करू शकतो, म्हणूनच हा क्रमांक कमकुवत ओळख आहे। UDP 53 वरचे OpenVPN सत्र अजूनही OpenVPN सत्र आहे, आणि पोर्ट 53 वरच्या सर्व्हरला केलेला DNS प्रश्न टनलला परवानगी आहे की नाही याबद्दल काहीही सांगत नाही। प्रोफाइलच्या proto आणि remote ओळी बाह्य एंडपॉइंट ठरवतात; पोर्ट क्रमांक स्वतः काहीही ठरवत नाही।

निदान करताना हे दोन्ही बाजूंनी लागू होते: पोर्ट 53 वरची सामान्य UDP चाचणी हे सिद्ध करते की पोर्ट उत्तर देतो, हे नाही की VPN सेवा उत्तर देते। खऱ्या क्लायंट आणि खऱ्या प्रोफाइलसह चाचणी करा, कारण सेवा ज्या हस्तांदोलनाची अपेक्षा करते ते केवळ तेच सरावते।

नेटवर्कला दोष देण्यापूर्वी श्रोता सिद्ध करा

सर्व्हरवर ss -lunp | grep 53 ने काय बांधले आहे ते तपासा आणि प्रोफाइलच्या प्रोटोकॉल आणि पोर्टशी त्याची तुलना करा। क्लायंटच्या नेटवर्कवरून, क्लायंट अधिक तपशिलासह चालवा जेणेकरून लॉग दाखवेल की त्याने कोणता पत्ता आणि ट्रान्सपोर्ट वापरून पाहिला। सर्व्हर ऐकत असेल आणि क्लायंटचे पॅकेट पोहोचत नसतील, तर मार्ग किंवा धोरण त्यांना नाकारत आहे, आणि तो नेटवर्क मालकाशी संवाद आहे, पोर्ट बदलण्याचे कारण नाही।

वेगळा पोर्ट तेव्हाच मदत करतो जेव्हा सेवा खरोखर तिथे ऐकते आणि तैनाती त्यास परवानगी देते। व्यवस्थापित नेटवर्कचे फिल्टरिंग टाळण्यासाठी श्रोता हलवणे हा धोरणाचा निर्णय आहे, समस्या निवारणाचा टप्पा नाही। सेवा बदलण्यापूर्वी नेटवर्क मालकाला काय परवानगी आहे ते विचारा, कारण धोरण मोडणारा पर्यायी मार्ग नंतर तरी बंद होतो। ते उत्तर प्रोफाइलजवळ नोंदवा जेणेकरून पुढची व्यक्ती विनंती पुन्हा करणार नाही।

टनलनंतर DNS स्वतंत्रपणे तपासा

टनल उभे राहिल्यावर, VPN इंटरफेसवरची रिझॉल्व्हरची स्थिती पाहा आणि एक अंतर्गत नाव आणि एक सार्वजनिक नाव विचारा। टनल रहदारी वाहत असताना अंतर्गत नावे अयशस्वी झाली तर पाठवलेली DNS सेटिंग्ज लागू झाली नाहीत, हा ट्रान्सपोर्टचा नव्हे तर क्लायंट एकत्रीकरणाचा प्रश्न आहे। सार्वजनिक नावे अयशस्वी आणि अंतर्गत नावे कार्यरत असतील तर विभाजित टनल धोरण जे संरचित होते तेच करत आहे।

DNS बदल रिझॉल्व्हर मालकाकडे ठेवा। एक चाचणी उत्तीर्ण व्हावी म्हणून व्यवस्थापित रिझॉल्व्हर संरचना ओव्हरराइट केल्यास मशीनवरील बाकी सर्वांसाठी खाजगी नावे तुटू शकतात। टनल रिझॉल्व्हर पाठवत असेल आणि क्लायंट त्याकडे दुर्लक्ष करत असेल, तर दुसरीकडे स्थिर नोंद जोडण्याऐवजी क्लायंट एकत्रीकरण दुरुस्त करा। स्थिर नोंदी अयशस्वीपणा लपवतात जोपर्यंत कोणी नेटवर्क बदलत नाही। कोणत्या रिझॉल्व्हरने कोणत्या नावाच्या जागेला उत्तर द्यायचे ते नोंदवा।

संबंधित लेख