गेटवे अपना ही एडमिन पेज होस्ट करता है: भीतरी या सार्वजनिक पता

एडमिन पेज मोबाइल डेटा वाले फ़ोन से जवाब देता है और VPN से जुड़े लैपटॉप से समय समाप्त हो जाता है। सुरंग में कुछ टूटा नहीं है, क्योंकि अनुरोध कभी उसमें प्रवेश ही नहीं करता। होस्टनाम गेटवे के सार्वजनिक पते पर हल होता है, और वह पता केवल उस सुरंग के बाहर से पहुँचने योग्य है जिसे वह समाप्त करता है। इसे ठीक करने का अर्थ है सेवा को निजी प्रवेश देना, बाहरी अंतिम बिंदु को इधर-उधर खिसकाना नहीं।

पेज बाहर से लोड होता है, सुरंग से नहीं

दो अलग अनुरोधों की तुलना की जा रही है। मोबाइल डेटा से ब्राउज़र सीधे सार्वजनिक पते तक पहुँचता है। सुरंग के भीतर से वही नाम उसी सार्वजनिक पते पर हल होता है, और पैकेट को अब सुरंग के अपने दूर वाले हिस्से के पते तक पहुँचने के लिए सुरंग से बाहर निकलना पड़ता है। वही नाम, वही पता, दो बिल्कुल अलग स्थितियाँ।

गंतव्य मार्ग पता चुनता है, पोर्ट नहीं। रूटिंग तालिका में कुछ भी नहीं जानता कि पोर्ट 443 प्रशासन के लिए है और पोर्ट 1194 परिवहन है, इसलिए दोनों को एक ही गंतव्य माना जाता है।

इसलिए पेज कभी काम करता है और कभी नहीं, इस पर निर्भर करता है कि क्लाइंट ने कौन सा नाम और कौन सा नेटवर्क इस्तेमाल किया। यह पथ की समस्या है, प्रमाणीकरण की समस्या नहीं. दोनों क्लाइंट पूरी तरह प्रमाणीकरण करते हैं।

बाहरी अंतिम बिंदु को पहुँचने योग्य रखें

पूर्ण-सुरंग प्रोफ़ाइल को VPN अंतिम बिंदु के लिए अपवाद मार्ग चाहिए, और OpenVPN का redirect-gateway विकल्प ठीक यही दर्ज करता है: दूरस्थ अंतिम बिंदु पहले से मौजूद गेटवे के ज़रिए मार्ग रखता है ताकि सुरंग अपने भीतर मार्ग न बने। वह अपवाद हटाएँ और एन्क्रिप्टेड परिवहन सुरंग का अनुसरण करेगा, जिससे सत्र लूप में समाप्त हो जाता है। वही अपवाद कारण है कि अंतिम बिंदु का पता सुरंग के भीतर से पहुँचने योग्य रहता है।

परिणाम यह है कि सार्वजनिक पता क्लाइंट से पहुँचने योग्य रहता है, इसीलिए उस पते पर ब्राउज़र अनुरोध भी वही अपवाद अपनाकर सुरंग में प्रवेश किए बिना बाहर निकल सकता है। अपवाद अपना काम कर रहा है, और नुकसान नाम कर रहा है।

कुछ भी बदलने से पहले इंटरफ़ेस सूची नहीं, मार्ग का निर्णय पढ़ें। नीचे दिए आदेश इन्वेंटरी नहीं, निर्णय छापते हैं। उन्हें उस क्लाइंट से चलाएँ जो विफल हुआ।

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

अगर लुकअप अंतिम बिंदु का मार्ग भौतिक गेटवे से दिखाता है, तो व्यवहार सही है और एडमिन पेज बस गलत रास्ते पर भेजा जा रहा है। यही वह बिंदु है जहाँ नाम हल करना समाधान बन जाता है।

सेवा को निजी नाम दें

सेवा को ऐसा नाम चाहिए जो सुरंग के भीतर गेटवे के पते पर हल हो, साथ ही वह प्रमाणपत्र और होस्टनाम अर्थ बना रहे जिसकी अनुप्रयोग अपेक्षा करता है। प्रशासनिक नाम के लिए निजी ज़ोन रिकॉर्ड सामान्य उत्तर है, और यह परिवहन नाम को अछूता छोड़ता है।

परिवहन नाम को भीतरी पते पर पुनर्निर्देशित न करें, क्योंकि अगली सुरंग स्थापना तब ऐसे पते तक पहुँचने का प्रयास करेगी जो केवल सुरंग के भीतर मौजूद है। वह गलती ऐसा VPN बनाती है जो ठीक एक बार काम करता है।

दोनों पता परिवार भी जाँचें, क्योंकि पीछे छूटा AAAA रिकॉर्ड ब्राउज़र को कहीं भेज सकता है जहाँ निजी योजना कभी नहीं पहुँची।

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

नीति को उस जगह के अनुरूप बनाएँ जहाँ प्रक्रिया चलती है

गेटवे पर सुनने वाली मूल प्रक्रिया तक स्थानीय-इनपुट पथ से पहुँचा जाता है, इसलिए इनपुट श्रृंखला और सॉकेट बाइंडिंग तय करते हैं कि अनुरोध स्वीकार होगा या नहीं। फ़ॉर्वर्डिंग नियम और IP फ़ॉर्वर्डिंग स्थानीय श्रोता को उत्तर देने पर बाध्य नहीं करते। इनपुट नीति में सुरंग के स्रोतों को अनुमति दें और पुष्टि करें कि प्रक्रिया ऐसे पते से बंधी है जहाँ सुरंग पहुँच सके।

होस्ट पोर्ट पर प्रकाशित कंटेनर अलग पथ अपनाता है, क्योंकि पैकेट गंतव्य-अनुवादित होकर फ़ॉर्वर्ड होता है। वह अनुरोध होस्ट की फ़ॉर्वर्डिंग नीति और Docker के अपने नियमों से मिलता है, इसीलिए काम करने वाला मूल श्रोता ऐसे कंटेनर के साथ रह सकता है जो वही पोर्ट अस्वीकार करता है।

दोनों मामलों में स्टार्टअप क्रम मायने रखता है, क्योंकि सुरंग ऊपर आने के बाद ही दिखने वाले पते से बाइंडिंग बूट पर चुपचाप विफल हो जाती है।

निजी पहुँच और अस्वीकृत सार्वजनिक पथ जाँचें

अनुप्रयोग की अपनी पहचान जाँच अक्षुण्ण रखते हुए अधिकृत क्लाइंट से नया नामित अनुरोध करें। फिर सुरंग के बाहर से वही सेवा आज़माएँ और पुष्टि करें कि वह जवाब नहीं देती। निजी नाम सुविधा है, प्रतिबंध नहीं, और सार्वजनिक पते से अभी भी बंधा श्रोता अभी भी खुला है। वही अंतिम जाँच है जिसे अधिकांश समीक्षाएँ छोड़ देती हैं।

उपयोगकर्ताओं को मिला होस्टनाम नहीं, बाइंडिंग और फ़िल्टर स्थिति पढ़ें। उजागर होना सॉकेट का गुण है, नाम का नहीं। वह अंतर हर DNS परिवर्तन में बचा रहता है।

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

जब भीतरी अनुरोध पेज लौटाता है और बाहरी अनुरोध का समय समाप्त हो जाता है, तो सेवा के पास एक जानबूझकर बनाया निजी पथ है और परिवहन पहुँचने योग्य रहता है। जब बाहरी अनुरोध अभी भी जवाब देता है, तो किसी के द्वारा सेवा को केवल-आंतरिक बताने से पहले श्रोता या प्रकाशित कंटेनर प्रविष्टि को सीमित करना होगा।