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 लोड कर सकते हैं। आरेख में दोनों एक जैसे दिखते हैं, और वे इसमें भिन्न हैं कि अंदर किसे आने दिया जाता है। तैनाती के बाद वह प्रश्न तय करना ही वह तरीका है जिससे कोई आंतरिक एप्लिकेशन संयोगवश सार्वजनिक हो जाता है।

लिखें कि आपने दोनों में से कौन-सा बनाया और क्यों। कॉन्फ़िगरेशन को छूने वाला अगला व्यक्ति दूसरे को मान लेगा। सुविधा के लिए जोड़ा गया एक रीडायरेक्ट ही मूल विफलता दोबारा बनाने के लिए काफी है, और लक्षण ठीक वैसा ही दिखेगा जैसा आपने अभी ठीक किया।