खाजगी एंडपॉइंट, तेच सर्व्हर नाव: 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 नाही, ज्याचे स्वतःचे कनेक्टिव्हिटी मॉडेल आहे आणि समतुल्य खाजगी एंडपॉइंटची कथा नाही। दोन्ही बाबतीत तीन गोष्टी वेगळ्या लेबल करा: नाव, नेटवर्क नोंद आणि क्रेडेन्शियल। कनेक्शन कुठे प्रवास करते हे बदलल्याने क्लायंट कोणत्या सेवेशी बोलत आहे असे वाटते ते कधीही बदलू नये।