आपका 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 पैकेट को उन नेटवर्क के बीच ले जाता है जिनके उपयोग की अनुमति आपको पहले से थी; वह कोई सेवा प्रकाशित नहीं करता और लैपटॉप को इंटरनेट की ओर खुले होस्ट में नहीं बदलता। तीन परतों में से कौन-सी बदलनी है यह तय करना ही काम है, और टनल उनमें से शायद ही कभी एक होता है।