यह रनबुक वर्कलोड प्रोफ़ाइल वाले Container Apps वातावरण को कवर करता है, जिसमें एक आंतरिक वर्चुअल-नेटवर्क प्रवेश है, जिस तक स्वीकृत पॉइंट-टू-साइट VPN के ज़रिए लैपटॉप से पहुँचा जाता है, ऐप के सीधे FQDN का उपयोग करते हुए और वातावरण-स्तर पर किसी HTTP रूट के बिना। वातावरण का प्रवेश क्लाइंट से पहुँच योग्य है, ऐप का इनग्रेस दायरा कॉलर को स्वीकार करता है, और होस्टनाम निजी प्रवेश पर रिज़ॉल्व होता है। नीचे का हर चरण सत्यापन योग्य परिणाम और ऐसा रोलबैक छोड़ता है जो उस किसी चीज़ को नहीं छूता जिसे आपने नहीं बदला। इन्हें दिए गए क्रम में पूरा करें, क्योंकि चरण 1 में गलत तरीके से लिए गए दायरे के निर्णय की भरपाई कोई भी बाद का चरण नहीं कर सकता।

DNS को छूने से पहले आंतरिक शब्द स्पष्ट करें। इस उत्पाद में यह दो अलग दायरों के लिए प्रयुक्त होता है, और इन्हें आपस में मिला देना ही वह सबसे आम कारण है कि काम करने वाला नाम भी अभी तक कुछ उपयोगी नहीं लौटाता।

चरण 1: वातावरण और ऐप का दायरा तय करें

कोई भी रिकॉर्ड बदलने से पहले ऐप का इनग्रेस कॉन्फ़िगरेशन पढ़ें:

SettingBoundary
Internal environmentThe environment entry is reached through its private network arrangement
App with internal ingressCallers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately
App with external ingress in an internal environmentThe app accepts outside traffic through the environment's private entry

आंतरिक इनग्रेस वातावरण के VNet के भीतर वातावरण के आंतरिक लोड बैलेंसर पर उजागर होता है, इसलिए सवाल यह नहीं है कि लैपटॉप कोई दूसरा कंटेनर ऐप है या नहीं, बल्कि यह है कि क्या वह उस VNet तक पहुँच सकता है। जिस VPN क्लाइंट के पास VNet में रूट है और वातावरण का डिफ़ॉल्ट डोमेन निजी ज़ोन से रिज़ॉल्व होता है, वह योग्य कॉलर है, और बाकी चरण ठीक यही बनाते हैं। सार्वजनिक प्रवेश के बिना आंतरिक वातावरण आंतरिक इनग्रेस वाले ऐप से अलग तथ्य है, और ऐप-स्तर पर बाहरी इनग्रेस वातावरण को सार्वजनिक दरवाज़ा नहीं देता। दायरा टिकट में भी लिखें और पोर्टल में भी, क्योंकि अगला इंजीनियर पहले टिकट पढ़ता है।

आगे बढ़ने से पहले कॉन्फ़िगरेशन स्वामी के साथ उस दायरे की पुष्टि करें, और द्वार संकीर्ण रखें: अगर वातावरण के VNet में कोई रूट नहीं है, या वातावरण का डिफ़ॉल्ट डोमेन निजी ज़ोन से रिज़ॉल्व नहीं होता, तो रुकें और पहले उस पथ को ठीक करें। जो कॉलर VNet तक नहीं पहुँच सकता या नाम रिज़ॉल्व नहीं कर सकता, उसका विकल्प कोई बाद का चरण नहीं दे सकता।

चरण 2: वास्तविक होस्टनाम और प्रवेश पता एकत्र करें

वातावरण का डिफ़ॉल्ट डोमेन, उसका स्थिर निजी प्रवेश पता और ऐप का कॉन्फ़िगर किया गया FQDN दर्ज करें, जो संसाधन से लिए जाएँ, पुराने स्क्रीनशॉट या विकी पृष्ठ से नहीं:

az containerapp env show -n ENV -g RG \
  --query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
  --query "properties.configuration.ingress.fqdn"

Container Apps के लिए निजी प्रवेश मार्गदर्शन ऐप के होस्टनाम को अक्षुण्ण रखते हुए वातावरण के डोमेन को उसके आंतरिक पते से मिलाने का वर्णन करता है। यह ठीक वही रूप है जो आप यहाँ हाथ से बना रहे हैं, इसलिए नई नामकरण योजना गढ़ने के बजाय ज़ोन की सामग्री को उससे संरेखित करें।

अगर आपने जो डोमेन पढ़ा है वह ऐप के बताए FQDN से मेल नहीं खाता, तो रुकें और अभी उन्हें मिलाएँ। गलत प्रत्यय पर ज़ोन बनाने से ऐसा होस्टनाम बनता है जो पूरी तरह रिज़ॉल्व होता है और फिर भी गलत वर्चुअल होस्ट पर उतरता है।

चरण 3: निजी ज़ोन को VPN के रिज़ॉल्वर पथ पर रखें

वातावरण के वास्तविक डिफ़ॉल्ट डोमेन के लिए समर्थित निजी DNS ज़ोन बनाएँ या फिर से उपयोग करें, जिसमें दस्तावेज़ीकृत वाइल्डकार्ड और पता रिकॉर्ड स्थिर प्रवेश की ओर इशारा करें। उस ज़ोन को उपयुक्त वर्चुअल नेटवर्क से लिंक करें, और लिंक पर्याप्त है यह मानने के बजाय VPN के स्वीकृत रिज़ॉल्वर पथ से निजी प्राधिकरण को पहुँच योग्य बनाएँ।

पॉइंट-टू-साइट क्लाइंट को उस ज़ोन तक पहुँचने के लिए आम तौर पर निजी रिज़ॉल्वर का इनबाउंड एंडपॉइंट या समर्थित DNS फ़ॉरवर्डर चाहिए। ज़ोन लिंक करने से Azure लिंक किए गए नेटवर्क के लिए जो रिज़ॉल्व करता है वह बदल जाता है; यह हर बाहरी लैपटॉप के सार्वजनिक रिज़ॉल्वर को रीडायरेक्ट नहीं करता। किसी दूसरे Container Apps नेटवर्किंग मॉडल से उधार लिए गए निजी-एंडपॉइंट DNS ज़ोन से इसे न बदलें, क्योंकि रिकॉर्ड नाम और ज़ोन प्रत्यय मेल नहीं खाएँगे।

इस चरण का रोलबैक ज़ोन लिंक या आपके जोड़े गए रिकॉर्ड को हटाना है। लिख लें कि इनमें से कौन सा था, क्योंकि एक लिंक पूर्ववत करने के लिए साझा ज़ोन मिटाना दूसरा वातावरण तोड़ने का एक सुविख्यात तरीका है।

चरण 4: नाम जाँचें, फिर अस्वीकृत दर्शक

होस्टनाम और TLS पहचान साथ में जाँचें, सिर्फ़ पता नहीं। नियंत्रित नाम-मैपिंग निदान के लिए आप होस्टनाम बनाए रखते हुए पता पिन कर सकते हैं:

curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
    https://app.ENVIRONMENT_DOMAIN/

होस्टनाम को ऐप के असली FQDN से और पते को असली आंतरिक प्रवेश से बदलें। यह सिर्फ़ उस एक अनुरोध को प्रभावित करता है और DNS प्रोविज़निंग नहीं है। पहचान की विफलता को दिखता पास में बदलने के लिए -k न जोड़ें, क्योंकि प्रमाणपत्र का बेमेल होना ही संकेत है कि आप गलत श्रोता से टकरा रहे हैं।

संख्यात्मक पते को सीधे माँगने से गलत वर्चुअल होस्ट चुना जा सकता है या TCP 443 के उत्तर देने के दौरान भी सत्यापन विफल हो सकता है, इसलिए सफल IP परीक्षण को नेटवर्क के बारे में प्रमाण मानें, उससे अधिक कुछ नहीं। इच्छित लैपटॉप से सामान्य रिज़ॉल्वर पथ क्लाइंट का DNS फ़ॉरवर्डर या ज़ोन होस्ट करने वाले निजी रिज़ॉल्वर का इनबाउंड एंडपॉइंट है, और वहाँ विफलता गुम रिकॉर्ड नहीं बल्कि रिज़ॉल्वर तक पहुँच की समस्या है। पुष्टि करें कि वही अनुरोध उस पथ पर सफल होता है, फिर पुष्टि करें कि अस्वीकृत दर्शक अब भी अस्वीकृत है।

क्या दर्ज करें और क्या रोलबैक करें

कंटेनर का लक्ष्य पोर्ट और क्लाइंट का HTTPS पोर्ट अलग सेटिंग्स हैं। कंटेनर का लक्ष्य पोर्ट VPN पर प्रकाशित न करें क्योंकि कंटेनर वहीं सुनता है, और पोर्ट परीक्षण पास होने के लिए नेटवर्क नियम न बढ़ाएँ। दोनों बदलाव घटना के बाद भी रहते हैं और बाद में उन्हें श्रेय देना कठिन होता है।

इच्छित लैपटॉप से उसकी अधिकृत पहचान और सामान्य DNS का उपयोग करते हुए ताज़ा एप्लिकेशन कार्रवाई के साथ समाप्त करें, फिर जाँचें कि अनधिकृत कॉलर अब भी विफल होता है। ऐप कॉन्फ़िगरेशन में रहते हुए यह भी पुष्टि करें कि वातावरण-स्तर का HTTP रूट इस ऐप को लक्ष्य के रूप में उजागर करता है या नहीं, क्योंकि वह रूट दूसरा दरवाज़ा है जिसे इनग्रेस दायरा नहीं बताता।

पाँच मान साथ दर्ज करें: वातावरण का दायरा, ऐप का इनग्रेस दायरा, FQDN, निजी प्रवेश पता और रिज़ॉल्वर स्वामी। वे पाँच पूरा प्रवेश अनुबंध बताते हैं, और इसका डिबग करने वाला अगला व्यक्ति ठीक उन्हीं को माँगेगा।

संबंधित लेख