VPN से जुड़े सर्वर के लिए DNS में कौन-सा पता जाता है?
होस्ट किए गए सर्वर के पास तीन पते होते हैं और वे एक-दूसरे के बदले नहीं आ सकते। हर सेवा को जो मान चाहिए उसे चुनें, फिर उसे मशीन के बाहर से सत्यापित करें।
VPN स्थापित होस्ट किए गए सर्वर के पास अंततः तीन पते होते हैं, और उनमें से केवल एक ही हर उस जगह से जुड़ता है जिसे आप अभी कॉन्फ़िगर करने वाले हैं। प्रदाता के पैनल से नंबर को DNS में, किसी श्रोता में या अनुमति सूची में कॉपी करना वह रास्ता है जिस पर एक काम करता टनल ऐसी सेवा बन जाता है जिस तक कोई नहीं पहुँच सकता। यह मार्गदर्शिका काम को इस क्रम में रखती है कि हर पता किसी बताए गए उद्देश्य के लिए चुना जाए। यह उन कमांडों की भी सूची देती है जो पुष्टि करते हैं कि आपने वास्तव में क्या प्रकाशित किया।
कुछ भी प्रकाशित करने से पहले तीनों पतों का नक्शा बनाएँ
उन्हें कार्य के अनुसार नाम दें। underlay पता वह है जिसका उपयोग मशीन इंटरनेट के जरिए VPN के अंतिम बिंदु तक पहुँचने के लिए करती है, और यह अकसर प्रदाता के NAT के पीछे निजी होता है। टनल का पता VPN के भीतर रहता है और उत्पाद के अनुसार सर्वर या क्लाइंट देता है। सार्वजनिक निकास वह पता है जिसे कोई दूरस्थ वेबसाइट अनुवाद के बाद दर्ज करती है, और उसे किसी ऐसे इंटरफ़ेस पर मौजूद होने की जरूरत नहीं जिससे आप पूछ सकें।
एक पैनल जो किसी मशीन के लिए एक सार्वजनिक पता दिखाता है, बाकी दो भूमिकाओं के बारे में बहुत कम बताता है। underlay की पहुँच एक आवश्यकता है, खरीद नहीं: घरेलू राउटर के पीछे का लैपटॉप सार्वजनिक IPv4 पता रखे बिना होस्ट किए गए VPN अंतिम बिंदु तक पहुँच सकता है। जो आप नहीं कर सकते वह यह है कि ऐसा नाम लिखकर प्रवेश का रास्ता गढ़ लें जो ऐसे पते पर हल हो जिसे कोई आगे नहीं भेजता।
पता सेवा के अनुसार चुनें, लेबल के अनुसार नहीं
नंबर चुनने से पहले लिख लें कि सर्वर को क्या करना है। बाहर जाने वाले API कॉल को स्थिर निकास चाहिए जब दूसरा पक्ष अनुमति सूची रखता है। निजी पहुँच को ऐसा टनल पता चाहिए जिसकी ओर क्लाइंट रूट कर सकें और उससे जुड़ा श्रोता। सार्वजनिक होस्टिंग को ऐसा प्रवेश मैपिंग चाहिए जो प्रदाता वास्तव में देता हो, और केवल निकास का पता यह नहीं देता।
एक ही मशीन तीनों उद्देश्य पूरे कर सकती है और फिर भी तीन अलग पते इस्तेमाल कर सकती है। जो टूटता है वह यह मान्यता है कि एक मान इन सबको ढक लेता है:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
प्रवेश वाली पंक्ति वही है जिस पर लोग बहस करते हैं। निकास के पते की ओर इशारा करने वाला रिकॉर्ड न कोई श्रोता बनाता है, न फ़ायरवॉल में छेद, न पोर्ट मैपिंग, और प्रतीक्षा करने से यह नहीं बदलता। जब प्रदाता समर्पित पता प्रवेश नियम के साथ बेचता है, तो वही बंडल वह क्षमता है जो आपने खरीदी; केवल पता अपने आप में अधिकार नहीं है।
वे कमांड जो दिखाते हैं कौन-सा पता कौन-सा है
मशीन पढ़ें, पैनल नहीं। इंटरफ़ेस के नाम सिस्टम के अनुसार अलग होते हैं, इसलिए पतों को उपकरणों से मिलाएँ, किसी लेबल पर भरोसा करने के बजाय।
पहली पंक्ति हर IPv4 पते और उसके उपकरण की सूची देती है, और दूसरी कर्नेल से पूछती है कि किसी ज्ञात बाहरी गंतव्य के लिए वह कौन-सा उपकरण लेगा:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'अगर रूट खोज सार्वजनिक ट्रैफ़िक के लिए टनल उपकरण के साथ उत्तर दे, तो आपकी पूरी टनल लागू है। श्रोता की जाँच भी उतनी ही महत्वपूर्ण है, क्योंकि केवल 127.0.0.1 से बँधी प्रक्रिया टनल पते पर कभी उत्तर नहीं देगी, चाहे आप कोई भी नाम प्रकाशित करें।
इसे प्रकाशित करें, फिर बाहर से सत्यापित करें
केवल वह मान प्रकाशित करें जो सेवा को चाहिए और उससे अधिक कुछ नहीं: होस्टिंग के लिए A या AAAA रिकॉर्ड, बाहर जाने वाले कॉल के लिए अनुमति सूची प्रविष्टि, निजी पहुँच के लिए क्लाइंट प्रोफ़ाइल। फिर उस स्थिति से परखें जो मायने रखती है, और वह कभी वह मशीन नहीं होती जिसे आपने अभी संपादित किया।
दो जाँचें अधिकांश हिस्सा ढक लेती हैं, और दोनों इतनी सस्ती हैं कि स्क्रिप्ट में रह सकें:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthऐसा DNS उत्तर जो साबित करता है कि आपका रिकॉर्ड मौजूद है, इस बात का प्रमाण नहीं कि कोई अनुरोध पहुँचता है, और एक सफल अनुरोध केवल यह साबित करता है कि एक रास्ता एक नेटवर्क से काम करता है। जब अनुमति सूची बीच में हो तो जाँच को मोबाइल कनेक्शन से दोहराएँ, क्योंकि जो निकास आप देखते हैं वह पता परिवार और तय किए गए रास्ते पर निर्भर हो सकता है। लिख लें कि आपने कौन-सा परिवार सत्यापित किया; काम करता IPv4 रास्ता IPv6 के बारे में बिल्कुल कुछ नहीं कहता।
अगर सेवा प्रवेश वाली है, तो निकास का पता काफ़ी नहीं है
प्रवेश पहुँच के लिए चार चीजें एक सीध में चाहिए: ऐसा नाम या पता जहाँ तक क्लाइंट पहुँच सके, ऐसा रास्ता जो पैकेट मशीन तक पहुँचाए, ऐसा श्रोता जो उसे स्वीकार करे, और ऐसी नीति जो उसे गिराए नहीं। VPN दूसरे तत्व को बदलता है और कभी पहले को, और तीसरे व चौथे के लिए कुछ नहीं करता। जब टनल ही डिलीवरी का रास्ता हो, तो क्लाइंट निकास के बजाय टनल पते से जुड़ते हैं।
लिख लें कि हर सेवा किस पते पर निर्भर है, फिर जब भी प्रदाता अपना रूटिंग मॉडल बदले उस नोट को दोबारा देखें। जो सर्वर निजी रूप से उत्तर देता है और सार्वजनिक रूप से विफल होता है वह आमतौर पर टूटा नहीं होता; वह गलत पहचान के साथ उत्तर दे रहा होता है, और मरम्मत एक मैपिंग निर्णय है न कि फ़ायरवॉल बदलाव।