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 लोड करू शकणाऱ्या प्रत्येकापर्यंत पारदर्शक विस्तार नाही. आकृत्यात दोन्ही सारखे दिसतात, आणि ते कोणाला आत येऊ दिले जाते यात वेगळे आहेत. तो प्रश्न उपयोजनानंतर ठरवणे हाच मार्ग आहे ज्यातून अंतर्गत अॅप्लिकेशन अपघाताने सार्वजनिक होते.

दोन्हींपैकी कोणती तुम्ही बांधली आणि का ते लिहा. कॉन्फिगरेशनला हात लावणारी पुढील व्यक्ती दुसरी गृहीत धरेल. सोयीसाठी जोडलेला एकच रीडायरेक्ट मूळ बिघाड पुन्हा निर्माण करण्यासाठी पुरतो, आणि लक्षण तुम्ही नुकतेच दुरुस्त केलेल्या सारखेच दिसेल.