तुमच्या VPN बोगद्याचा पत्ता इनबाउंड पोर्ट का उघडत नाही
बोगद्याचा पत्ता तुमच्या क्लायंटला अशा सहकाऱ्यांसमोर ओळखतो जे तिथे मार्गक्रमण करू शकतात, आणि कधीही श्रोता तयार करत नाही. बाइंड, परतीचा मार्ग आणि नंतर धोरण तपासा.
कार्यालयीन VPN ला जोडा, पोर्ट 8443 वर एक छोटी सेवा सुरू करा, बोगद्याचा पत्ता सहकाऱ्याला पाठवा आणि क्लायंट अजूनही जोडलेला असल्याचे सांगत असताना कनेक्शन अयशस्वी होताना पहा। बोगद्यात काहीच तुटलेले नाही: पत्ता दिला गेला आहे, सत्र सुरू आहे, आणि उत्तर वाहून नेणारे पॅकेट कधीही स्वीकारले जात नाहीत। खालील तीन तपासण्या क्रमाने करा आणि जी अयशस्वी होते तिथे थांबा, कारण प्रत्येकाचा उपाय वेगळा आहे आणि त्यापैकी फक्त एकच VPN शी संबंधित आहे।
सॉकेट प्रत्यक्षात कुठे बाइंड झाले आहे यापासून सुरुवात करा
काहीही मार्गक्रमण होण्यापूर्वी, कॉलर ज्या पत्त्यावर पोहोचू शकतो तिथे काहीतरी ऐकत असले पाहिजे। विकास सर्व्हर हे नेहमीचे दोषी असतात, कारण त्यापैकी अनेक डीफॉल्टनुसार loopback वर बाइंड होतात आणि त्याच मशीनवरून येणारी कनेक्शनच स्वीकारतात। बोगद्याचा पत्ता ते बाइंडिंग बदलत नाही, आणि ऑपरेटिंग सिस्टम VPN गुंतण्यापूर्वीच कनेक्शन नाकारेल।
ss -ltnp | grep 8443
netstat -ano | findstr 8443स्थिती नाही, स्थानिक पत्ता स्तंभ वाचा। 127.0.0.1:8443 म्हणजे फक्त loopback, आणि उपाय म्हणजे 0.0.0.0 किंवा बोगद्याच्या पत्त्यावरच बाइंड करणे। 0.0.0.0:8443 सर्व इंटरफेसवर स्वीकारते, जे मशीनकडे सार्वजनिक पत्ताही असताना बहुतेक लोकांना अपेक्षित असण्यापेक्षा विस्तृत आहे; 10.64.7.15:8443 ही अरुंद आवृत्ती आहे जी फक्त तिथेच ऐकते जिथे सहकारी पोहोचू शकतो। त्याच आउटपुटमधील प्रक्रियेचे नावही लक्षात घ्या, कारण पूर्वीच्या चाचणीतील भटकलेली प्रत सामान्य कारण आहे की पोर्ट उघडा दिसतो आणि चुकीच्या सामग्रीसह उत्तर देतो।
मग त्या पत्त्यावर काहीतरी मार्गक्रमण करू शकते का असे विचारा
बोगद्याच्या पत्त्याचा अर्थ फक्त त्या उपसर्गाला बोगद्यात पाठवण्यासाठी संरचित सहकाऱ्यांसाठी असतो। सहकाऱ्याच्या मशीनचे स्वतःचे तक्ते आहे, आणि बोगद्याच्या उपजाळासाठी मार्ग नसेल तर पॅकेट डीफॉल्ट गेटवेकडे जाते आणि पत्ता अस्तित्वात आहे हे न कळणाऱ्या ठिकाणी मरते। हा कॉलरच्या बाजूचा मार्गक्रमणाचा प्रश्न आहे, तुमच्या बाजूची परवानगी नाही।
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
दोन क्लायंटमधील सर्व्हरही तितकाच महत्त्वाचा आहे। नेहमीच्या दूरस्थ प्रवेश रचनेत प्रत्येक क्लायंट गेटवेकडे बाहेर जाणारे कनेक्शन उघडतो आणि गेटवे त्या प्रवाहांची स्थिती ठेवतो, त्यामुळे उत्तरे त्याला आधीच माहीत असलेल्या मार्गाने परत येतात। एका क्लायंटकडून दुसऱ्याकडे जाणारे कनेक्शन हा गेटवेने स्वीकारून पुढे पाठवायचा नवीन प्रवाह आहे, आणि अनेक तैनाती क्लायंटना एकमेकांपासून वेगळे ठेवण्यासाठी ते जाणूनबुजून बंद ठेवतात। ग्राहक VPN सेवा सामान्यतः डीफॉल्टनुसार वेगळे ठेवतात; कॉर्पोरेट गेटवे कधीकधी गटानुसार परवानगी देतात।
होस्टवर काहीही बदलण्यापूर्वी दिशा तपासा। बोगद्याचा पत्ता गेटवेकडूनच उत्तर देत असेल पण सहकाऱ्याकडून देत नसेल, तर फरक गेटवेचे क्लायंट-ते-क्लायंट सेटिंग आहे, आणि स्थानिक फायरवॉलचे कोणतेही संपादन त्याची जागा घेऊ शकत नाही।
शेवटी, प्रवाहाला परवानगी देणारे धोरण शोधा
मार्गक्रमण केलेल्या पॅकेट आणि उत्तर देणाऱ्या सेवेमध्ये धोरणाचे तीन स्तर असतात: VPN सर्व्हरचा अग्रेषण निर्णय, होस्ट फायरवॉल, आणि इन्स्टन्ससमोरील कोणताही क्लाउड सुरक्षा गट। तीनही एकमताने असले पाहिजेत, आणि ते वेगवेगळ्या पद्धतीने अयशस्वी होतात, म्हणूनच वरील तक्त्यातील लक्षण ब्राउझरमधील त्रुटी संदेशापेक्षा उपयुक्त आहे।
यशस्वी बाइंडनंतर लोक जो स्तर विसरतात तो होस्ट फायरवॉल आहे, कारण LAN इंटरफेसवर पोर्टला परवानगी देणारा नियम तो बोगद्याच्या इंटरफेसवर आपोआप देत नाही। इंटरफेस-मर्यादित नियम योग्य रचना आहेत आणि कार्यालयातून चालणाऱ्या पण घरून न चालणाऱ्या सेवेचे नेहमीचे कारणही आहेत। नियमाचा पोर्ट क्रमांक नाही, त्याची व्याप्ती वाचा।
स्थिती-आधारित गाळणी उलटी परिस्थिती स्पष्ट करते। तुमच्या लॅपटॉपवरून बाहेर जाणारे कनेक्शन स्थिती निर्माण करते, आणि त्याला येणारी उत्तरे इनबाउंड नियमाशिवाय स्वीकारली जातात। सहकाऱ्याचे कनेक्शन मागे स्थिती नसलेला पूर्णपणे नवीन प्रवाह आहे, म्हणून त्याला स्पष्ट परवानगी हवी। ही विषमताच तुमच्या स्वतःच्या मशीनवर चालणारे ब्राउझर सत्र सेवा बाहेरून पोहोचण्यायोग्य आहे का याबद्दल काहीही न सांगण्याचे संपूर्ण कारण आहे।
एक तपासणी अयशस्वी झाल्यास बोगदा नाही, रचना बदला
जर आवश्यकता अशी असेल की सहकाऱ्याने तुमची स्थानिक सेवा उघडावी, तर प्रामाणिक उत्तर सामान्यतः इनबाउंड प्रवेशासाठी बांधलेली यंत्रणा असते। उलटा SSH बोगदा सर्वात लहान आहे: तुमचे मशीन बाहेरच्या दिशेने अशा होस्टशी जोडते जिथे सहकारी आधीच पोहोचू शकतो, आणि श्रोता त्या होस्टवर असतो।
ssh -N -R 8443:127.0.0.1:8443 [email protected]रिलेला त्याच्या SSH सर्व्हर संरचनेत GatewayPorts clientspecified आवश्यक आहे, अन्यथा पुढे पाठवलेला श्रोता रिलेवर loopback ला बांधला जातो आणि सहकाऱ्याला पूर्वीप्रमाणेच तोच नकार मिळतो। दुपारपेक्षा जास्त काळ टिकणाऱ्या कशासाठीही आरोग्य तपासणी आणि प्रकाशित नावासाठी प्रमाणपत्र असलेला लोड बॅलन्सर किंवा ingress हे चांगले साधन आहे, आणि दोन नेटवर्कना खरोखर बोलायचे असेल तेव्हा दोन्ही उपजाळांसाठी मार्ग असलेला साइट-टू-साइट बोगदा हे योग्य उत्तर आहे।
यापैकी प्रत्येक रचना उघडपणा स्पष्ट करते, आणि तोच मुद्दा आहे। VPN पॅकेटना तुम्हाला आधीच अधिकृत असलेल्या नेटवर्कमध्ये हलवते; ते सेवा प्रकाशित करत नाही आणि लॅपटॉपला इंटरनेटकडे तोंड करणाऱ्या होस्टमध्ये बदलत नाही। तीन स्तरांपैकी कोणता बदलायचा हे ठरवणे हे काम आहे, आणि बोगदा त्यापैकी क्वचितच एक असतो।