तपाईंको 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 का लागि मात्र भएको निजी सेवालाई गल्तीले सार्वजनिक बनाउनु उपयुक्त हुँदैन।