गेटवे स्वतःचे प्रशासन पृष्ठ होस्ट करतो: आतील की सार्वजनिक पत्ता

प्रशासन पृष्ठ मोबाइल डेटावरील फोनवरून उत्तर देते आणि 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/

जेव्हा आतील विनंती पृष्ठ परत करते आणि बाहेरील विनंतीची वेळ संपते, तेव्हा सेवेकडे एक जाणीवपूर्वक खाजगी मार्ग असतो आणि वाहतूक पोहोचण्यायोग्य राहते. जेव्हा बाहेरील विनंती अजूनही उत्तर देते, तेव्हा कोणीही सेवेला केवळ-आंतरिक म्हणण्यापूर्वी श्रोता किंवा प्रकाशित कंटेनर नोंद आकुंचित करावी लागते.