SQL Server-ის დასახელებული ინსტანცია VPN-ით: აღმოჩენა და არა პორტი 1433

ადამიანების უმეტესობა 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-ის ჰოსტის სახელი სრული მისამართია. ეს ჰოსტია და დამატებით, დასახელებული ინსტანციისთვის, ძიება, რომელსაც გვირაბმა შეიძლება არ გადაიტანოს. დაასახელეთ პორტი, დაასახელეთ აღმოჩენის გზა და შემდეგი ხარვეზი გეტყვით, რომელი ფენა უნდა გამოსწორდეს.