बहुतेक लोक SQL Server च्या होस्टनावाला पूर्ण पत्ता मानतात आणि VPN ला एकतर परवानगी आहे किंवा नाही असे मानतात। प्रत्यक्षात नामांकित इन्स्टन्स क्लायंटला DNS नंतर दुसरा शोध करायला भाग पाडतो आणि टनेल सर्वात जास्त वेळा तोच शोध तोडते। स्पष्ट एंडपॉइंट त्याला टाळतो, म्हणून tcp:host,port चालू शकते तर host\INSTANCE वेळ संपते। फरक सेवा शोधणे आणि ती वापरण्याची परवानगी मिळणे यात आहे।

गैरसमज: एक होस्टनाव म्हणजे एक पोर्ट

होस्टनाव एका पत्त्यात सोडवले जाते आणि तिथे त्याचे काम संपते। नामांकित इन्स्टन्स एक इन्स्टन्स नाव जोडतो जे सर्व्हरला TCP पोर्टमध्ये भाषांतरित करावे लागते आणि क्लायंट ते अंदाजू शकत नाही। पोर्ट 1433 हा डीफॉल्ट इन्स्टन्ससाठी डीफॉल्ट आहे, मशीनवरील प्रत्येक इन्स्टन्सचा गुणधर्म नाही। दोन्हींना एकच गोष्ट मानल्यास क्लासिक लक्षण तयार होते: ping चालते, DNS चालते, 1433 चे स्कॅन काही दाखवत नाही आणि निष्कर्ष असा निघतो की नेटवर्क SQL ला ब्लॉक करते।

दुसरे गृहीतही त्याच पद्धतीने अयशस्वी होते: TCP 1433 उघडणे पुरेसे आहे हे। इन्स्टन्स दुसरीकडे ऐकत असेल तर उघडा 1433 फक्त तिथे दुसरे काही आहे हे सिद्ध करतो। पोर्ट श्रोत्याशी जुळला पाहिजे आणि की श्रोता सर्व्हर बाजूचा कॉन्फिगरेशन तपशील आहे हे अंदाज न लावता विचारले पाहिजे।

क्लायंट नामांकित इन्स्टन्ससोबत प्रत्यक्षात काय करतो

होस्ट सोडवल्यानंतर क्लायंट UDP 1434 वर SQL Server Browser ला शोध विनंती पाठवतो आणि नामांकित इन्स्टन्स कोणता पोर्ट वापरतो हे विचारतो। ब्राउझर सेवा सर्व्हरच्याच नोंदणीतून उत्तर देते आणि नंतर क्लायंट त्या पोर्टवर TCP कनेक्शन उघडतो। लॉगिनचा प्रयत्न होण्यापूर्वीच दोन प्रोटोकॉल व दोन पोर्ट सहभागी होतात।

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

म्हणूनच फक्त UDP ब्लॉक झाल्यास मृत होस्टसारखा वाटणारा टाइमआउट होतो। ब्राउझर सेवा थांबली किंवा बंद असेल तर डेटाबेस इंजिन चालू असूनही आणि त्याचा TCP पोर्ट उघडा असूनही शोध विनंती उत्तराशिवाय राहते। इन्स्टन्स स्थिर पोर्टवर कॉन्फिगर असेल तर एंडपॉइंट थेट दिला नसेल तर क्लायंट तरीही विचारतो। यातील प्रत्येक अपयश अ‍ॅप्लिकेशनच्या त्रुटी संदेशात सारखेच दिसते आणि त्यांना वेगळ्या दुरुस्त्या लागतात।

ब्राउझर सेवा शोधासाठी सोय आहे, डेटाबेस नाही। ती थांबवल्याने इंजिन थांबत नाही आणि ती सुरू केल्याने इन्स्टन्सचा TCP पोर्ट उघडत नाही।

नाव चालत नसताना स्पष्ट एंडपॉइंट का चालते

स्पष्ट एंडपॉइंट शोध क्रमातून काढून टाकते: क्लायंट तुम्ही सांगितलेल्या पत्त्या व पोर्टवर थेट जोडतो। हे प्रथम निदान आहे, आपोआप कायमचा उपाय नाही, कारण इन्स्टन्स नंतर गतिशील पोर्टवर पुन्हा कॉन्फिगर झाल्यास पोर्ट बदलू शकतो। निष्कर्ष काढण्यापूर्वी दोन्ही स्वरूप एकाच क्लायंट आणि एकाच खात्यासह तुलना करा।

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

स्पष्ट स्वरूप यशस्वी होऊन नामांकित स्वरूप अयशस्वी झाल्यास तूट शोधात आहे आणि ती कशी बंद करावी हे तुम्ही निवडू शकता: टनेलमधून UDP 1434 ला परवानगी द्या, किंवा प्रशासकाला स्थिर पोर्ट निश्चित करून एंडपॉइंटचे दस्तऐवजीकरण करायला सांगा। दोन्ही वेगळ्या देखभाल खर्चासह जाणीवपूर्वक घेतलेले निर्णय आहेत। श्रेणीतील प्रत्येक पोर्ट उघडणे यापैकी एकही नाही आणि दीर्घ दिवसाच्या शेवटी सहसा हाच पर्याय सुचवला जातो। कनेक्शन स्ट्रिंग जिथे राहतात तिथे निवड नोंदवा।

कोणतेही स्वरूप चालत नसेल तर समस्या शोधाच्या वर आहे। ब्राउझर सेवेला दोष देण्यापूर्वी श्रोता, मार्ग आणि इन्स्टन्स प्रत्यक्षात वापरत असलेल्या पोर्टचा प्रवेश नियम तपासा।

शोधानंतर: प्रमाणीकरण आणि ओळख वेगळी आहे

लॉगिन अपयश ही टाइमआउटपेक्षा वेगळी घटना आहे आणि टनेलमुळे VPN ओळख SQL लॉगिन होत नाही। क्लायंट योग्य पोर्टवर पोहोचल्यावर डेटाबेस इंजिन त्याचे स्वतःचे प्रमाणीकरण व परवानग्या लागू करते। दोन टप्पे एका तिकिटात मिसळणे हाच शोध समस्या चुकीच्या टीमला दिली जाण्याचा मार्ग आहे। काहीही बदलण्यापूर्वी त्रुटी क्रमांक वाचा।

ड्रायव्हर सर्व्हरचे प्रमाणपत्र पडताळत असेल तर दस्तऐवजीकृत होस्टनाव ठेवा, कारण संख्यात्मक पत्त्याने जोडणे मूळ समस्या सोडवण्याऐवजी ती तपासणी बदलू शकते। अलीकडील Microsoft ड्रायव्हर डीफॉल्टने एन्क्रिप्ट करतात, म्हणून नावाची विसंगती यशस्वी TCP कनेक्शननंतर प्रमाणपत्र त्रुटी म्हणून दिसते। हे नवीन अपयश नाही, प्रगती आहे।

सोडावयाचा गैरसमज म्हणजे SQL Server चे होस्टनाव पूर्ण पत्ता आहे हा। ते एक होस्ट आहे आणि नामांकित इन्स्टन्ससाठी टनेल वाहून नेणार नाही अशी शोध जोडली जाते। पोर्टचे नाव द्या, शोध मार्गाचे नाव द्या आणि पुढील अपयश कोणता स्तर दुरुस्त करावा हे सांगेल।

संबंधित लेख