समर्पित 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 पत्ता रेकॉर्ड डीफॉल्टनुसार 443 वापरणाऱ्या HTTPS विनंतीला पोर्ट जोडू शकत नाही, आणि TTL बदलल्याने ते बदलत नाही.
वेब फ्रंटएंड हे अभ्यागतांना नेहमीच्या पोर्टवर स्वीकारून आणि फॉरवर्ड केलेल्या ओरिजिन पोर्टशी स्वतःचे कनेक्शन करून सोडवू शकते. मात्र Cloudflare चे डीफॉल्ट प्रॉक्सी पोर्ट ही निश्चित यादी आहे, आणि प्रॉक्सी केलेला DNS रेकॉर्ड जोडल्यामुळे कोणताही अनियंत्रित नियुक्त पोर्ट समर्थित एज पोर्ट होत नाही.
ओरिजिनचा गंतव्य पोर्ट बदलणे हे अभ्यागत पोर्ट बदलण्यापेक्षा वेगळे कार्य आहे. Cloudflare चे Origin Rules ब‍ॅकएंड कनेक्शनसाठी गंतव्य-पोर्ट ओव्हरराइडचे दस्तऐवजीकरण करतात, जे समर्थित नियम, स्कीम आणि होस्टनावापुरते मर्यादित आहे. पोर्ट ओव्हरराइड अनियंत्रित UDP किंवा इतर प्रोटोकॉलसाठी सामान्य रिले नाही.
जेव्हा फ्रंटएंड TLS संपवते, तेव्हा दोन्ही टप्पे सत्यापित करा: ब्राउझरपासून फ्रंटएंडपर्यंतचे प्रमाणपत्र आणि फ्रंटएंडपासून ओरिजिनपर्यंतचे कनेक्शन. VPN टप्पा दोन्हीपैकी कोणतीही तपासणी बदलत नाही, आणि अंतर्गत पत्ता रीडायरेक्ट किंवा कुकीजमध्ये गळणे हे दोन्हीपैकी फक्त एकच सार्वजनिक नाव लक्षात घेऊन कॉन्फिगर केले गेले होते याचे नेहमीचे लक्षण आहे.
म‍ॅपिंग जिवंत ठेवा
काही पुरवठादार पुन्हा जोडल्यानंतर वेगळा पोर्ट वाटतात, आणि भाड्याने घेतलेल्या म‍ॅपिंगला पुरवठादाराच्या बाजूच्या कृतीद्वारे नूतनीकरणाची आवश्यकता असू शकते. तुमचा पुरवठादार जे यंत्रणा दस्तऐवजीकृत करतो ती अनुसरा, आणि श्रोता, स्थानिक नियम, DNS किंवा फ्रंटएंड नियम फक्त सध्याच्या कराराने आवश्यक असेल तिथेच अद्ययावत करा.
स्थिर सार्वजनिक पत्ता पोर्ट भाड्याला स्थिर करत नाही. ड‍ॅशबोर्डवर अजूनही दिसणारा पत्ता आणि पोर्ट सक्रिय सत्र म‍ॅपिंगचे मालक आहे याचा पुरावा नाही, म्हणून चाचणी बाहेरून आलेली नवीन विनंती आहे, स्क्रीनशॉट नाही.
नंतर तुम्ही अपेक्षित असलेल्या प्रकरणांची पुनरावृत्ती करा: सामान्य पुन्हा जोडणी आणि VPN तोटा. जर तोट्यामुळे ओरिजिन अनुपलब्ध व्हायला हवे, तर अद्ययावतकर्त्याला पार्श्वभूमीवर गुपचूप थेट ISP मार्ग पुन्हा प्रकाशित करू देऊ नका. आणि जर फॉरवर्डिंग करार साइटच्या स्थिरतेच्या आवश्यकता पूर्ण करू शकत नसेल, तर दुसरे पत्ता लेबल खरेदी करून ते सर्व्हरसारखे वागेल अशी आशा करण्याऐवजी वेगळी प्रकाशन व्यवस्था निवडा.