Azure वेब ॲप VPN द्वारे ऑन-प्रिमाइसेस कसे पोहोचते

वेब ॲपच्या आउटबाउंड विनंतीमुळे तुम्ही कधीही न पाहिलेला, तुम्ही निवडलेल्या स्त्रोताकडून असा कामगार सोडला जातो आणि ऑफिस फायरवॉलला ते स्वीकारावे लागते. हीच संपूर्ण समस्या एका वाक्यात आहे. प्रादेशिक VNet एकत्रीकरण विनंतीला व्हर्च्युअल नेटवर्कमध्ये एक मार्ग देते आणि साइट-टू-साइट VPN ते तेथून घेऊन जाते. नंतर जे काही चुकीचे होते ते कोणत्या स्त्रोत श्रेणी आणि पॅकेटने प्रत्यक्षात वापरलेले मार्ग याविषयी असते.

कार्यकर्ता प्रत्यक्षात काय पाठवतो

ॲप सेवा तुमचा कोड तुमच्या सदस्यत्वाच्या नेटवर्क दृश्याच्या बाहेर बसलेल्या कामगारांवर चालवते. प्रादेशिक एकत्रीकरण सक्षम केल्यामुळे, आउटबाउंड ट्रॅफिक त्याच प्रदेशातील VNet मधील प्रतिनिधी सबनेटला दिले जाते आणि ते सुरू होण्यापूर्वी पॅकेट तेथे दिसते. इंटिग्रेशन ॲपला VNet मध्ये हलवत नाही आणि त्याचा इनबाउंड पत्ता बदलत नाही. हे फक्त आउटबाउंड फ्लोला एक वेगळे फर्स्ट हॉप देते.

डिफॉल्टनुसार फक्त खाजगी पत्त्याची जागाच तो मार्ग घेते, त्यामुळे सामान्य इंटरनेट गंतव्यस्थान अजूनही कामगारांकडून थेट सोडले जातात. VNet द्वारे प्रत्येक गोष्ट राउट करणे ही एक वेगळी सेटिंग आणि वेगळा निर्णय आहे, कारण ते तुमचे सार्वजनिक अवलंबित्व देखील बोगद्यावर पाठवते.

कॉन्फिगरेशन ट्रॅफिक, जसे की स्टार्टअपवर कंटेनर इमेज पुल, स्वतःचे राउटिंग नियमांचे पालन करते आणि तुमचे API कॉल यशस्वी होत असताना अयशस्वी होऊ शकतात.

एकीकरण सबनेट हा स्त्रोत आहे ज्याला तुम्ही अनुमती दिली पाहिजे

ऑफिस इंटिग्रेशन सबनेटची ॲड्रेस रेंज पाहते, किंवा तुमचे उपकरण जे भाषांतर करते ते ॲपचे सार्वजनिक आउटबाउंड पत्ते पाहत नाही. ती श्रेणी साइट VPN च्या रहदारी निवडकांमध्ये आणि ऑन-प्रिमाइसेस फायरवॉल नियमामध्ये ठेवा. बोगदा धोरण-आधारित असल्यास, मार्ग अस्तित्वात असताना देखील निवडक ते पॅकेट टाकतात.

तुम्ही पाहिलेल्या एका कामगाराच्या पत्त्याला परवानगी देऊ नका. स्केलिंग आणि प्लॅटफॉर्म देखभालीसह उदाहरणे बदलतात आणि एका पत्त्यावर पिन केलेला नियम सर्वात वाईट क्षणी मोडतो.

गंतव्य बाजू अरुंद ठेवा: एक सेवा, एक बंदर, एक दिशा, परतीचा मार्ग स्पष्टपणे अनुमत आहे.

पीअरिंग आणि गेटवे ट्रान्झिट स्पष्ट आहेत

जर VPN गेटवे हब VNet मध्ये बसला असेल आणि स्पोकमध्ये इंटिग्रेशन सबनेट असेल तर, पाथला हब पीअरिंगवर गेटवे ट्रान्झिट आणि स्पोक पीअरिंगवर रिमोट गेटवे वापर सक्षम करणे आवश्यक आहे. स्वतःच पीअरिंग दोन VNets दरम्यान रहदारी आणि अधिक काही नाही. इंटिग्रेशन सबनेटवरील प्रभावी मार्ग आहेत जिथे तुम्ही पुष्टी करता की गेटवे नेक्स्ट हॉप खरोखर तिथे आहे.

हब-अँड-स्पोक डिझाइन ज्याचे रूट टेबल फायरवॉलला 0.0.0.0/0 पाठवते ते एक सामान्य प्रकार आहे आणि त्या फायरवॉलला नंतर ऑन-प्रिमाइसेस उपसर्गासाठी स्वतःचा नियम आवश्यक आहे.

नेटवर्क टीमसह तिकीट उघडण्यापूर्वी कागदावर मार्ग काढा, कारण तो अंदाज लावण्याचा एक दिवस वाचवतो. चित्रात परतीची दिशा समाविष्ट करा, कारण अर्धे लोक ते विसरतात.

इनबाउंड प्रायव्हेट एंडपॉइंट ही दुसरी दिशा आहे

खाजगी एंडपॉइंट ॲपला VNet मधून पोहोचण्यायोग्य बनवते. कार्यालयात ॲपच्या आउटबाउंड कॉलसाठी ते काहीही करत नाही आणि वास्तविक आवश्यकता उलट असताना संघ नियमितपणे एक कॉन्फिगर करतात.

जुने दस्तऐवज पॉइंट-टू-साइट VPN वर तयार केलेल्या गेटवे-आवश्यक एकीकरणाचे वर्णन करते, त्याच्या स्वतःच्या आवश्यकतांसह वेगळे वैशिष्ट्य. Microsoft त्या वैशिष्ट्याची सेवानिवृत्ती 31 मार्च 2027 ला शेड्यूल करते आणि त्याऐवजी प्रादेशिक एकत्रीकरणाची शिफारस करते.

जुन्या उदाहरणाने वापरलेले लेगसी पॉइंट-टू-साइट कॉन्फिगरेशन कॉपी करू नका.

ॲपच्या स्वतःच्या संदर्भासह सत्यापित करा

उपयोजित ॲपवरून चाचणी घ्या, तुमच्या लॅपटॉपवरून नाही आणि त्याच VNet मधील VM वरून नाही. निराकरण केलेला पत्ता, कनेक्शन परिणाम आणि अनुप्रयोग-स्तरीय प्रतिसाद स्वतंत्रपणे लॉग करा, कारण DNS अपयश, एक TCP कालबाह्य आणि तीन भिन्न मालकांवर प्रमाणीकरण नकार बिंदू. नावाचे रिझोल्यूशन अयशस्वी झाल्यास, बोगद्याला स्पर्श करण्यापूर्वी VNet साठी खाजगी DNS निश्चित करा.

हिरव्या बोगद्याची स्थिती केवळ गेटवे वर असल्याचे सिद्ध करते. हे निवडक, फायरवॉल नियम किंवा DNS बद्दल काहीही सांगत नाही.

विनंती शेवटी कार्य करते तेव्हा, ॲपच्या रनबुकमध्ये स्त्रोत श्रेणी, गंतव्य पोर्ट आणि DNS झोन लिहा. हे डीबग करण्यासाठी पुढील व्यक्ती गेटवेच्या स्थिति पृष्ठाऐवजी तुमच्या टिपेपासून सुरू होईल.