गेटवे आफ्नै एडमिन पृष्ठ होस्ट गर्छ: भित्री वा सार्वजनिक ठेगाना

एडमिन पृष्ठ मोबाइल डेटाको फोनबाट जवाफ दिन्छ र 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/

जब भित्री अनुरोधले पृष्ठ फर्काउँछ र बाहिरी अनुरोधको समय सकिन्छ, सेवासँग एक जानाजानी निजी मार्ग हुन्छ र यातायात पुग्न सकिने रहन्छ। जब बाहिरी अनुरोध अझै जवाफ दिन्छ, कसैले सेवालाई केवल-भित्री भन्नुअघि श्रोता वा प्रकाशित कन्टेनर प्रविष्टि साँघुरो पार्नुपर्छ।