HAProxy 302 बाट निजी एपमा: दोस्रो हप कसले खोल्छ?

कसैले सार्वजनिक HAProxy होस्टलाई आन्तरिक एप्लिकेसनतर्फ औंल्याउँछ र ब्राउजर किन पछ्याउन सक्दैन भनी सोध्छ। प्रोक्सी आफ्नो VPN मार्फत एपसम्म पुग्छ, रिडिरेक्टले Location हेडर फर्काउँछ, र ब्राउजरले त्यसपछि सुरुङभित्र मात्र रहेको ठेगाना प्रयास गर्छ। बाहिरबाट पृष्ठ यत्तिकै अड्किन्छ। दोस्रो जडान कुन पक्षले खोल्छ भन्ने निर्णय हो, र त्यहीले रिडिरेक्टलाई ब्याकएन्डबाट अलग गर्छ।

कन्फिगरेसनमा उस्तै देखिने दुई मार्ग

रिडिरेक्टले प्रतिक्रियासँग आदानप्रदान अन्त्य गर्छ। क्लाइन्टले Location पढ्छ र जहाँ छ त्यहींबाट नयाँ अनुरोध सुरु गर्छ, अर्थात् त्यो सञ्जालबाट जुन तपाईंले कहिल्यै नियन्त्रण गर्नुभएन। प्रोक्सी अब संलग्न छैन। त्यसपछिको सबै क्लाइन्टको आफ्नै DNS, मार्ग र विश्वासमा निर्भर छ, त्यसैले प्रयोगकर्ताले ब्राउजर कहाँ खोल्यो त्यसअनुसार नतिजा फरक पर्छ:

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

प्रोक्सीको ब्याकएन्डले दोस्रो चरण सर्भरतर्फ राख्छ। प्रोक्सीले यो पहिले नै भएको मार्गबाट खोल्छ, र क्लाइन्ट एउटै सार्वजनिक नामसँग बोलिरहन्छ। सुरुङ खस्यो भने क्लाइन्टले पछ्याउन नसक्ने URL को सट्टा त्रुटि पाउँछ। यही भिन्नताले गडबडीलाई निदानयोग्य बनाउँछ, किनकि त्रुटि लगहरू भएको ठाउँमै देखिन्छ:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

HAProxy को रिडिरेक्ट कागजात ले ठ्याक्कै यही रेखा तान्छ: क्लाइन्टलाई रिडिरेक्टले जवाफ दिनु अनुरोध ब्याकएन्डमा पठाउनुभन्दा फरक कार्य हो। दुई निर्देशन कन्फिगरेसन फाइलमा केही हरफको दूरीमा छन् र पूर्ण रूपमा फरक व्यवहार गर्छन्। एउटाले अनुरोध अन्त्य गर्छ, अर्कोले प्रोक्सीको स्वामित्वको दोस्रो सुरु गर्छ।

ब्राउजरलाई के चाहिन्छ र सर्भरको VPN ले के दिँदैन

ब्राउजरको आफ्नै अनुरोधलाई चार कुरा चाहिन्छ जोसँग नहुन सक्छ: निजी नामका लागि DNS जवाफ, त्यो ठेगानासम्म मार्ग, सुनिरहेको सेवासम्म पुग्ने अनुमति, र त्यो सेवाले प्रस्तुत गर्ने प्रमाणपत्रमा विश्वास। प्रोक्सी होस्टसँग आफ्नो सुरुङमार्फत चारै छन्। तीमध्ये कुनै पनि त्यस्तो क्लाइन्टमा जाँदैन जो कहिल्यै त्यो सुरुङमा थिएन, किनकि सुरुङ होस्टको गुण हो, URL को होइन।

यही अन्तरले लगभग-चल्छ लक्षण व्याख्या गर्छ। पहिलो अनुरोध सफल हुन्छ, ठेगाना पट्टी बदलिन्छ, र त्यसपछि प्रोक्सी सधैं स्वस्थ रहँदा पनि जडान अड्किन्छ वा असफल हुन्छ। प्रोक्सी कन्फिगरेसनमा केही बिग्रेको छैन, र त्यसलाई मिलाउँदा 10.40.0.20 सम्म मार्ग नभएको क्लाइन्टलाई मद्दत गर्दैन। या त क्लाइन्टले मार्ग पाउँछ, वा प्रोक्सीले उसको तर्फबाट जडान गर्नुपर्छ।

जब मात्र प्रोक्सीले एपसम्म पुग्न सक्छ

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

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

त्यो ब्लकलाई प्रोक्सीको राउटिङ तालिकाबारेको भनाइका रूपमा पढ्नुहोस्: 10.40.0.20 प्रोक्सी होस्टबाटै पुग्न सकिने हुनुपर्छ, जसको अर्थ यहाँ पूर्वनिर्धारित मार्गबाट होइन, VPN इन्टरफेसबाट हो। check शब्दले त्यो मार्गले के गर्छ मात्र जनाउँछ, र स्वास्थ्य मार्ग एपमा हुनैपर्छ, नभए प्रत्येक जाँचले सर्भरलाई डाउन चिन्ह लगाउँछ। सफल जाँचले क्लाइन्टबारे केही प्रमाणित गर्दैन र ब्याकएन्ड कसले प्रयोग गर्न पाउँछ भन्ने नीतिको ठाउँ लिँदैन।

यो अंश पूरा फ्रन्टएन्ड होइन। श्रोता, प्रमाणीकरण, अनुमति दिइएको होस्ट र मार्ग छनोट, र एपसम्म कसले पुग्न सक्छ भन्ने नियम राख्नुहोस्। ब्याकएन्ड प्रोटोकल पनि मिलाउनुहोस्, किनकि HTTPS ब्याकएन्डलाई प्रमाणपत्र प्रमाणीकरण र सर्भर पहिचान कन्फिगरेसन चाहिन्छ, र त्यो जाँच छोड्दा निजी जडान अप्रमाणित हुन्छ।

विजय घोषणा गर्नुअघि दुवै दिशामा फर्कने मार्ग पुष्टि गर्नुहोस्। एप्लिकेसनले अब प्रोक्सीबाट आउने जडान देख्छ, त्यसैले यसका लग र क्लाइन्ट ठेगानाका कुनै पनि मेटाडाटाले प्रोक्सीलाई वर्णन गर्छ, जबसम्म तपाईं अर्कै व्यवस्था गर्नुहुन्न। पहिचान र पठाइएका ठेगाना कसरी ह्यान्डल गरिन्छ निर्णय गर्नुहोस्, र अनुमान गर्नुको सट्टा निर्णय परीक्षण गर्नुहोस्।

एपका आफ्नै रिडिरेक्टहरू अझै भित्रतिर देखाउँछन्

पहिलो अनुरोध पठाउनु एकीकरणको आधा मात्र हो। एप्लिकेसनले निरपेक्ष रिडिरेक्ट, कडा कोड गरिएका एसेट URL, वा भित्र थाहा भएको नाममा सीमित कुकीहरू दिन सक्छ, र तीमध्ये प्रत्येकले ब्राउजरलाई पुग्न नसकिने ठेगानामा फर्काउँछ। आन्तरिक नामतर्फ देखाउने Location हेडर मूल समस्यासँग उस्तै देखिन्छ, त्यसैले यसलाई गल्तीले प्रोक्सी गडबडीका रूपमा निदान गरिन्छ।

एपको कागजात गरिएको बाह्य URL र यसका प्रोक्सी विकल्प सेट गर्नुहोस्, त्यसपछि Host हेडरलाई भर्चुअल होस्ट र प्रमाणपत्रको अपेक्षासँग मिलाउनुहोस्। आन्तरिक नाममा सीमित कुकी सार्वजनिक नामबाट फर्केर आउँदैन, र त्यसपछिको साइन-इन लुप प्रमाणीकरण बगका रूपमा पढिन्छ। पहिले बाह्य URL बदल्नुहोस्, सफा ब्राउजर प्रोफाइलबाट फेरि परीक्षण गर्नुहोस्, र आधा स्थानान्तरित सेटिङले सफल लगइन र तुरुन्तै मर्ने सत्र उत्पन्न गर्ने अपेक्षा गर्नुहोस्।

पठाइएका मेटाडाटामा मात्र तोकिएको प्रोक्सीबाट विश्वास गर्नुहोस्। कुनै पनि क्लाइन्टले सेट गर्न सक्ने हेडर कहिल्यै अधिकार मान हुनुहुँदैन, नभए प्रोक्सी कल गर्नेका लागि अर्काको पहिचान दाबी गर्ने बाटो बन्छ। त्यो नियम रिडिरेक्ट प्रश्नबाट स्वतन्त्र छ र पछिको कुनै पनि पुनर्संरचनामा टिक्छ।

तपाईंसँग वास्तवमा कुन डिजाइन छ निर्णय गर्नुहोस्

यदि प्रत्येक प्रयोगकर्तासँग पहिले नै अधिकृत VPN पहुँच छ भने, निजी URL मा रिडिरेक्ट जानाजान गरिएको डिजाइन हुन सक्छ। त्यो आवश्यकता अनुमान नगरी स्पष्ट रूपमा पुष्टि गर्नुहोस्, किनकि दुई डिजाइनले पूर्ण रूपमा फरक समूहलाई सेवा दिन्छन्। तीमध्ये एउटा होटेल सञ्जालबाट बिल्कुल चल्दैन, र अर्कोले एपलाई सार्वजनिक URL लोड गर्न सक्ने सबैसामु खोल्छ। त्यो भेद डिजाइन टिप्पणीमा पर्छ।

प्रयोगकर्ताको सञ्जालको मेसिनबाट जाँच चलाउनुहोस् र ब्राउजरले गर्ने प्रत्येक हप पछ्याउनुहोस्, पहिलो प्रतिक्रिया मात्र होइन। ठेगाना पट्टी र प्रत्येक पछिल्लो अनुरोधमा नजर राख्नुहोस्, किनकि एसेट ट्यागमा एउटा निरपेक्ष URL ले पहिलो हप पार गरेको प्रवाह तोड्न पर्याप्त छ। साइन-इन सार्वजनिक नामबाट चल्नुपर्छ, र अस्वीकार गर्नुपर्ने स्रोत अस्वीकृत नै रहनुपर्छ।

रिभर्स प्रोक्सी प्रकाशित गर्नु छुट्टै पहुँच निर्णय हो, प्रोक्सीको आफ्नै VPN लाई यसको सार्वजनिक URL लोड गर्न सक्ने सबैसम्म पारदर्शी विस्तार होइन। रेखाचित्रमा दुवै उस्तै देखिन्छन्, र तिनीहरू कोलाई भित्र पस्न दिइन्छ भन्नेमा फरक छन्। त्यो प्रश्न तैनाथीपछि निर्णय गर्नु नै आन्तरिक एप्लिकेसन दुर्घटनावश सार्वजनिक हुने बाटो हो।

दुईमध्ये कुन बनाउनुभयो र किन लेख्नुहोस्। कन्फिगरेसन छुने अर्को व्यक्तिले अर्को अनुमान गर्नेछ। सुविधाका लागि थपिएको एउटा रिडिरेक्टले मूल गडबडी पुनः सिर्जना गर्न पर्याप्त छ, र लक्षण तपाईंले भर्खरै सुधारेको जस्तै देखिनेछ।