आपके URL को पोर्ट 80 या 443 पर प्रवेश क्यों चाहिए, 45000 पर नहीं

ब्राउज़र में होस्टनाम लिखें और स्कीम गंतव्य पोर्ट तय करती है: http के लिए 80, https के लिए 443। DNS उत्तर में कुछ भी इसे रद्द नहीं करता, और आपकी मशीन पर कोई फ़ॉरवर्डिंग नियम प्रदाता के किनारे पर श्रोता नहीं गढ़ सकता। जब कोई VPN प्रदाता आपको 45000 जैसा ऊँचा सार्वजनिक पोर्ट देता है, तो स्पष्ट URL काम करता है और साफ़ नहीं। अंतर प्रवेश बिंदु पर है, एप्लिकेशन के अंदर नहीं।

ब्राउज़र से प्रक्रिया तक का रास्ता एक बार देखें, और तीनों प्रकाशन विकल्प रहस्यमय लगना बंद कर देंगे।

देखें कि अनुरोध वास्तव में कहाँ जाता है

ब्राउज़र नाम को पते में हल करता है, फिर उस पते से स्कीम के डिफ़ॉल्ट पोर्ट पर जुड़ता है, जब तक URL कोई दूसरा पोर्ट न बताए। आने वाले कनेक्शन का क्या होगा, यह आपके प्रदाता का किनारा तय करता है। अगर उसकी फ़ॉरवर्डिंग तालिका केवल 45000 को आपके आंतरिक पते पर मैप करती है, तो 80 पर कनेक्शन के पास जाने की कोई जगह नहीं है और आपकी मशीन शामिल होने से पहले ही उसे अस्वीकार या छोड़ दिया जाता है।

यह अस्वीकृति किनारे पर होती है, इसलिए आपके एप्लिकेशन लॉग कुछ भी नहीं दिखाते। लॉग का अभाव इस बात का सबूत है कि पैकेट कहाँ रुका, इस बात का नहीं कि एप्लिकेशन खराब है।

कोई स्थानीय नियम किनारे को क्यों ठीक नहीं कर सकता

एप्लिकेशन होस्ट पर रीडायरेक्ट या DNAT नियम उन पैकेटों पर काम करता है जो पहले ही आ चुके हैं। प्रदाता पर पोर्ट 80 पर भेजे गए पैकेट कभी नहीं पहुँचते, इसलिए नियम का मूल्यांकन कभी नहीं होता। पूरी समस्या में यह सबसे आम बर्बाद घंटा है।

DNS भी पोर्ट नहीं ढो सकता। HTTP विनिर्देश स्कीम के डिफ़ॉल्ट परिभाषित करता है, और A या AAAA रिकॉर्ड पता लौटाता है जबकि CNAME दूसरा नाम लौटाता है। ब्राउज़र फिर भी स्कीम का पोर्ट जोड़ता है, इसलिए केवल URL में स्पष्ट पोर्ट ही गंतव्य बदलता है।

विकल्प एक: स्पष्ट पोर्ट रखें

अक्सर सही उत्तर वही बिना चमक वाला होता है। पोर्ट के साथ पूरा URL प्रकाशित करें, ऐसे प्रवेश पर TLS समाप्त करें जो इसे समर्थित करता हो, और सुनिश्चित करें कि हर उत्पन्न लिंक वही मूल बनाए रखे। छोटे, नियंत्रित दर्शकों के लिए यह पूर्ण है, और दिखाई देने वाले पोर्ट नंबर के अलावा इसकी कोई कीमत नहीं है।

वहाँ रहते हुए रीडायरेक्ट और कुकी के दायरे की जाँच करें, क्योंकि अपना होस्टनाम Location हेडर में लिखने वाला बैकएंड इस व्यवस्था को रद्द कर देता है।

विकल्प दो: डिफ़ॉल्ट पोर्ट पर असली प्रवेश पाएँ

कुछ प्रदाता और होस्टिंग व्यवस्थाएँ दस्तावेज़ीकृत सेवा के रूप में साझा या समर्पित पते पर 80 और 443 फ़ॉरवर्ड करते हैं। यह मानने के बजाय कि सार्वजनिक एग्ज़िट पता मनमाने इनबाउंड पोर्ट का मतलब है, पूछें कि वास्तव में क्या शामिल है। समर्पित आउटबाउंड पता इनबाउंड फ़ॉरवर्डिंग के बारे में कुछ नहीं कहता।

स्वामित्व और उपलब्धता की लिखित पुष्टि करें, जिसमें यह भी शामिल है कि जब सुरंग किसी दूसरे पते के साथ फिर से जुड़ती है तो प्रवेश का क्या होता है। सुरंग के साथ हिलने वाला प्रवेश ऐसे व्यवधान पैदा करता है जो DNS विफलताओं जैसे दिखते हैं।

विकल्प तीन: सामने एक फ्रंटएंड रखें

पहुँच योग्य पते पर रिवर्स प्रॉक्सी 443 पर सुनना और TLS समाप्त करना और VPN के माध्यम से बैकएंड से अलग कनेक्शन खोल सकता है। आगंतुक फ्रंटएंड का नाम और डिफ़ॉल्ट पोर्ट देखते हैं, जबकि फ्रंटएंड आपकी ओर से बैकएंड के ऊँचे पोर्ट से बात करता है। यह इसलिए काम करता है क्योंकि यह प्रवेश बिंदु से लड़ने के बजाय आर्किटेक्चर बदलता है। तब बैकएंड को सार्वजनिक इंटरनेट पर कोई इनबाउंड पोर्ट चाहिए ही नहीं।

यह आपके द्वारा संचालित चीज़ें भी बदलता है। फ्रंटएंड के पास सार्वजनिक TLS, पहुँच नीति, लॉग और उपलब्धता होती है, और उसे बैकएंड चुनाव को इच्छित सेवा तक सीमित करना चाहिए। अगर फ्रंटएंड से बैकएंड तक की छलांग HTTPS का उपयोग करती है, तो उस छलांग पर प्रमाणपत्र सत्यापन रखें।

एक ही मूल रखें

फ्रंटएंड का सार्वजनिक होस्टनाम, स्कीम और पोर्ट वह मूल बनाते हैं जिसका आगंतुक उपयोग करते हैं, इसलिए एप्लिकेशन का बाहरी URL, रीडायरेक्ट और कुकी उसी मूल के लिए कॉन्फ़िगर करें। अगर एप्लिकेशन निरपेक्ष लिंक बनाता है तो मूल होस्ट और फ़ॉरवर्ड की गई स्कीम भेजें। जो प्रतिक्रिया उपयोगकर्ताओं को निजी नाम या ऊँचे पोर्ट पर वापस भेजती है, वह अभी बनाए गए साफ़ प्रवेश को रद्द कर देती है।

फिर दर्शकों को ध्यान में रखते हुए निर्णय लें। छोटा URL प्रबंधित फ्रंटएंड को उचित ठहरा सकता है, और केवल VPN के लिए बनी निजी सेवा को गलती से सार्वजनिक बनाना उचित नहीं है।