तुमच्या 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 साठी असलेल्या खाजगी सेवेचे चुकून सार्वजनिक सेवेत रूपांतर करणे योग्य नाही।