समर्पित VPN IP आपकी वेबसाइट प्रकाशित नहीं करता
समर्पित एग्ज़िट पता इनबाउंड डिलीवरी के बारे में कुछ नहीं बताता। फ़ॉरवर्डिंग अनुबंध जाँचें, ओरिजिन पक्ष पूरा करें और फिर ऊँचा पोर्ट प्रकाशित करें।
VPN प्रदाता से समर्पित IP खरीदना सामने का दरवाज़ा खरीदने जैसा लगता है। पता स्थिर है, टनल चालू है, और वेबसाइट फिर भी बाहर के किसी के लिए लोड नहीं होती। आपने जो खरीदा है वह एक आवंटन है, इनबाउंड फ़ॉरवर्डिंग नियम नहीं। दोनों एक ही दुकान में बिकते हैं और पूरी तरह अलग जगहों पर कॉन्फ़िगर होते हैं।
पता एक आवंटन है, फ़ॉरवर्डिंग नियम नहीं
इनबाउंड सार्वजनिक पता या होस्टनेम, अनुमत ट्रांसपोर्ट, आवंटित बाहरी पोर्ट और वह क्लाइंट-साइड गंतव्य जहाँ प्रदाता डिलीवर करता है, दर्ज करें। फिर पुष्टि करें कि आपने जो सर्वर, प्रोटोकॉल और खाता सुविधा चुनी है वह वास्तव में फ़ॉरवर्डिंग का समर्थन करती है और प्रदाता उस पर होस्टिंग की अनुमति देता है।
समर्पित शब्द पते के आवंटन का वर्णन करता है। इसका अर्थ यह नहीं है कि बिना माँगे आने वाला इनबाउंड ट्रैफ़िक अनुमत है, और एक ही ऑपरेटर के अलग-अलग ऐड-ऑन की क्षमताएँ अलग हो सकती हैं। समर्पित पता और समर्पित सर्वर उत्पाद वे दो लेबल हैं जिन्हें लोग सबसे ज़्यादा मिला देते हैं, और सहायता पृष्ठ आमतौर पर स्पष्ट करते हैं कि कौन-सा फ़ॉरवर्ड करता है।
| What you have | What it gives you | What it does not |
|---|---|---|
| Dedicated exit address | A stable source address for outbound traffic | Any inbound delivery at all |
| Port-forwarding add-on | A provider-side mapping to your session | Permanence across reconnects |
| Local DNAT rule | Handling for packets that arrive | Making packets arrive |
एक उदाहरण अनुबंध ऐसा दिखता है: प्रदाता TCP 203.0.113.60:45000 आपके जुड़े डिवाइस की HTTPS सेवा तक पोर्ट 8443 पर पहुँचाता है। यह किसी और द्वारा कॉन्फ़िगर किए गए मैपिंग का वर्णन है, ऐसा नियम नहीं जिसे आप उनके एज पर अपने फ़ायरवॉल में लिखकर बना सकें।
ओरिजिन पक्ष पूरा करें
यदि वेब एप्लिकेशन VPN क्लाइंट पर ही चलता है, तो उसे डिलीवर किए गए पोर्ट पर एक श्रोता और उस पोर्ट के लिए सीमित स्थानीय-इनपुट अनुमति चाहिए। यदि क्लाइंट मैप किए गए कनेक्शन को किसी अन्य होस्ट पर फ़ॉरवर्ड करता है, तो उसे गंतव्य अनुवाद, फ़ॉरवर्डिंग नीति और आने-जाने में टिकने वाला उत्तर पथ चाहिए।
एक्सेस नियम उस स्रोत पते के आसपास बनाएँ जो प्रदाता का पथ वास्तव में प्रस्तुत करता है। यह हमेशा मूल आगंतुक नहीं होता, और हमेशा VPN सर्वर भी नहीं होता, जो तब मायने रखता है जब आप ऐसा नियम लिखते हैं जिससे केवल उनमें से एक पता मेल खाएगा।
पोर्ट अनुवाद भी HTTP को HTTPS में नहीं बदलता। सार्वजनिक पोर्ट और स्थानीय एप्लिकेशन पोर्ट स्वतंत्र रूप से अलग हो सकते हैं, लेकिन स्कीम, प्रमाणपत्र की पहचान और रीडायरेक्ट अभी भी उस सेवा से मेल खाने चाहिए जहाँ लोग वास्तव में पहुँचते हैं। यदि प्रमाणपत्र सार्वजनिक होस्ट का नाम देता है, तो हर चरण पर वही नाम रखें। यहाँ असंगति राउटिंग विफलता के बजाय ब्राउज़र चेतावनी के रूप में दिखती है, जो लोगों को एक घंटे के लिए गलत लॉग तक भेज देती है।
ऊँचे पोर्ट को ईमानदारी से प्रकाशित करें
यदि आगंतुक सीधे जुड़ते हैं और प्रदाता ने ऊँचा पोर्ट आवंटित किया है, तो उन्हें पूरा URL दें। एक साधारण DNS पता रिकॉर्ड HTTPS अनुरोध में पोर्ट नहीं जोड़ सकता, जो डिफ़ॉल्ट रूप से 443 उपयोग करता है, और TTL बदलने से यह नहीं बदलता।
एक वेब फ़्रंटएंड इसे आगंतुकों को सामान्य पोर्ट पर स्वीकार करके और फ़ॉरवर्ड किए गए ओरिजिन पोर्ट से अपना कनेक्शन बनाकर हल कर सकता है। हालाँकि Cloudflare के डिफ़ॉल्ट प्रॉक्सी पोर्ट एक निर्धारित सूची हैं, और मनमाने ढंग से आवंटित पोर्ट केवल इसलिए समर्थित एज पोर्ट नहीं बन जाता कि आपने प्रॉक्सी किया हुआ DNS रिकॉर्ड जोड़ा है।
ओरिजिन का गंतव्य पोर्ट बदलना आगंतुक पोर्ट बदलने से भिन्न क्रिया है। Cloudflare के Origin Rules बैकएंड कनेक्शन के लिए गंतव्य-पोर्ट ओवरराइड का दस्तावेज़ीकरण करते हैं, जो समर्थित नियम, स्कीम और होस्टनेम तक सीमित है। पोर्ट ओवरराइड मनमाने UDP या अन्य प्रोटोकॉल के लिए सामान्य रिले नहीं है।
जब कोई फ़्रंटएंड TLS समाप्त करता है, तो दोनों चरणों को सत्यापित करें: ब्राउज़र से फ़्रंटएंड तक का प्रमाणपत्र और फ़्रंटएंड से ओरिजिन तक का कनेक्शन। VPN चरण इन दोनों जाँचों में से किसी की जगह नहीं लेता, और आंतरिक पता का रीडायरेक्ट या कुकी में रिसना इस बात का सामान्य संकेत है कि दोनों में से केवल एक ही सार्वजनिक नाम को ध्यान में रखकर कॉन्फ़िगर किया गया था।
मैपिंग को जीवित रखें
कुछ प्रदाता पुनः कनेक्ट के बाद अलग पोर्ट आवंटित करते हैं, और पट्टे पर लिया गया मैपिंग प्रदाता-पक्ष की क्रिया से नवीनीकरण माँग सकता है। अपने प्रदाता द्वारा दस्तावेज़ित तंत्र का पालन करें, और श्रोता, स्थानीय नियम, DNS या फ़्रंटएंड नियम केवल वहीं अपडेट करें जहाँ मौजूदा अनुबंध इसकी माँग करता है।
स्थिर सार्वजनिक पता पोर्ट पट्टे को स्थिर नहीं बनाता। डैशबोर्ड में अब भी दिखने वाला पता और पोर्ट इस बात का प्रमाण नहीं है कि सक्रिय सत्र मैपिंग का मालिक है, इसलिए परीक्षण बाहर से एक नया अनुरोध है, स्क्रीनशॉट नहीं।
फिर उन स्थितियों को दोहराएँ जिनकी आप अपेक्षा करते हैं: सामान्य पुनः कनेक्ट, और VPN का गिरना। यदि गिरना ओरिजिन को अनुपलब्ध बनाना चाहिए, तो किसी अपडेटर को पृष्ठभूमि में चुपचाप सीधा ISP पथ दोबारा प्रकाशित करने न दें। और यदि फ़ॉरवर्डिंग अनुबंध साइट की स्थिरता आवश्यकताओं को पूरा नहीं कर सकता, तो दूसरा पता लेबल खरीदकर उसके सर्वर जैसा व्यवहार करने की आशा रखने के बजाय कोई दूसरी प्रकाशन व्यवस्था चुनें।