निजी एंडपॉइंट, वही सर्वर नाम: Azure SQL कनेक्शन स्ट्रिंग

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