Private Link ले जडान कहाँ पुग्छ भन्ने परिवर्तन गर्छ, जडानलाई के भनिन्छ भन्ने होइन। Azure SQL Database का लागि त्यो भिन्नता नै सम्पूर्ण डिजाइन हो: तार्किक सर्भरले आफ्नो नाम राख्छ, र निजी एन्डपोइन्टले नाम हल हुने सञ्जाल प्रविष्टि दिन्छ। नामलाई IP ठेगानाले बदल्नु नै TLS, प्रमाणहरू र उपकरणहरूलाई एकैचोटि तोड्ने एउटै परिवर्तन हो। दुई जडान स्ट्रिङहरू समान देखिन सक्छन् र पूर्ण रूपमा फरक व्यवहार गर्न सक्छन्।

orders-db.database.windows.net राख्नुहोस् र क्लाइन्टलाई यसका लागि निजी उत्तर दिनुहोस्।

नाम र ठेगानाका काम फरक छन्

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

Azure SQL का लागि Microsoft को मार्गदर्शनले क्लाइन्टबाट सामान्य सर्भर नाम माग्छ। सिधा IP, र त्यसैगरी privatelink उपसर्ग भएको नाम, अदलबदल गर्न मिल्ने लगइन लक्ष्य होइन। IP स्वीकार गर्ने उपकरणहरूले त्यो स्वीकार गरेर पछि TLS वा प्रमाणीकरणमा असफल हुन्छन्, जसले साँचो गल्ती लुकाउँछ। ती असफलताहरू त्रुटिभित्रको होस्टनाम नहेर्दासम्म प्रमाण समस्याजस्तै पढिन्छन्।

निजी क्षेत्रले वास्तवमा के परिवर्तन गर्छ

निजी DNS क्षेत्रले privatelink नाम स्थानभित्र सर्भरका लागि एउटा ठेगाना अभिलेख गर्छ, र क्षेत्र त्यसलाई प्रयोग गर्नुपर्ने भर्चुअल सञ्जालसँग जोडिएको हुन्छ। रिजोल्युसन सर्छ; जडान स्ट्रिङ सर्दैन। तलको आकार उदाहरण हो, सार्वजनिक क्षेत्रमा टाँस्ने अभिलेख होइन।

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

त्यो अभिलेख र यसको क्षेत्र लिङ्कलाई मालिक र समीक्षा मितिसहित पूर्वाधारका रूपमा कायम राख्नुहोस्।

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

Azure बाहिरका क्लाइन्टहरूलाई त्यो क्षेत्रमा प्रवेश मार्ग चाहिन्छ

VPN क्लाइन्ट Azure को रिजोल्भरबाहिर बस्छ, त्यसैले निजी क्षेत्र हाइब्रिड मार्गबाट पुग्न सकिने हुनुपर्छ। Azure DNS फर्वार्डर वा Azure DNS Private Resolver ले त्यो सञ्जालबाट आउने क्वेरीहरू सेवा गर्न सक्छ। Microsoft को मार्गदर्शन भनेको क्लाइन्टहरूले सिधै privatelink नाम सोध्छन् भनी मान्नुको सट्टा सम्बन्धित सार्वजनिक सेवा क्षेत्रलाई त्यो व्यवस्थाबाट फर्वार्ड गर्नु हो। निजी उत्तर हल गर्न नसक्ने क्लाइन्टहरू उजुरी नगरी सार्वजनिक उत्तरमा फर्किन्छन्।

फर्वार्डिङको दायरा जानाजान राख्नुहोस्, किनकि प्रयोगमा रहेको सार्वजनिक क्षेत्र बदल्दा प्रतिस्थापनमा नभएका नामहरू टुट्छन्।

पहिचान स्थिर राख्ने क्रममा व्यवस्था गर्नुहोस्

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

जोडिएको VPN आइकनले आफैँ निजी गन्तव्य छान्दैन।

निजी एन्डपोइन्टले के बन्द गर्दैन

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

सर्भरले कुन जडान नीति प्रयोग गर्छ त्यो पनि जाँच्नुहोस्।

Redirect ले सुरुको गेटवे जडानपछि क्लाइन्टलाई नोडको पोर्टमा पठाउँछ, जसले क्लाइन्ट सञ्जालले के अनुमति दिनुपर्ने हो त्यो बदल्छ। Proxy ले ट्राफिक गेटवेमा राख्छ। एउटा पोर्टमा सफल TCP ह्यान्डशेक सम्पूर्ण लगइन कार्यप्रवाह होइन।

यो Azure SQL Database हो, SQL Managed Instance होइन, जसको आफ्नै जडान मोडेल छ र समान निजी एन्डपोइन्ट कथा छैन। दुवै अवस्थामा तीन चीजहरू छुट्टै लेबल गर्नुहोस्: नाम, सञ्जाल प्रविष्टि र प्रमाण। जडान कहाँ यात्रा गर्छ भन्ने बदल्दा क्लाइन्टले कुन सेवासँग बोलिरहेको छ भन्ने सोचाइ कहिल्यै बदल्नु हुँदैन।

सम्बन्धित लेखहरू