SQL VPN-ით: პირდაპირი კლიენტი თუ შიდა სამუშაო სადგური?

გუნდებს სურთ SSMS თავიანთ ლეპტოპებზე, და სწრაფი გადაწყვეტა SQL პორტის VPN აუზში გამოქვეყნებაა. უფრო ნელი პასუხი კითხულობს, სად უნდა მუშაობდეს კლიენტის პროცესი, რადგან პირდაპირი წვდომა და შიდა სამუშაო სადგური სხვადასხვა წყაროს მისამართებს, ბოლო წერტილის ნდობას და მონაცემთა ბილიკებს ქმნის. არც ერთი არ არის ავტომატურად უსაფრთხო, და მხოლოდ VPN-ის წევრობა არაფერს წყვეტს. შეადარეთ დიზაინები ნებართვის წესის არსებობამდე.

ორი ბილიკი, ორი წყაროს მისამართი

პირდაპირი წვდომისას ლეპტოპი ატარებს კლიენტის კონფიგურაციას და თავად ხსნის მონაცემთა ბაზის კავშირს. დისტანციური სამუშაო სადგურისას ლეპტოპი ხსნის სამუშაო მაგიდის სესიას, და სამუშაო სადგური SQL კავშირს საკუთარი მისამართიდან ამყარებს. ამიტომ მონაცემთა ბაზა პირველ დიზაინში ხედავს VPN აუზს ან თარგმნილ კარიბჭეს, ხოლო მეორეში სამუშაო სადგურის მისამართს. სწორედ ეს განსხვავება წყვეტს, რომელი firewall წესი და რომელი SQL ნებართვა მოქმედებს სინამდვილეში.

ლეპტოპი კვლავ აკონტროლებს დისტანციურ სესიას, ამიტომ სამუშაო სადგური არ ცვლის მომხმარებლის აუთენტიფიკაციას ან სესიის პოლიტიკას.

შეამოწმეთ, რას ხედავს მონაცემთა ბაზა სინამდვილეში

წყაროს მისამართი გასაზომია და არა დიაგრამიდან გამოსაყვანი. წაიკითხეთ ის აქტიური კავშირის სერვერის მხარეს.

Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"

კავშირის ტესტი ამტკიცებს, რომ მსმენელი იღებს TCP-ს ამ ქსელიდან, ხოლო მოთხოვნა ამტკიცებს, რომელ შესვლასა და მონაცემთა ბაზას მიაღწია სესიამ. სერვერის მიერ ჩაწერილი მისამართის სანახავად მოითხოვეთ sys.dm_exec_connections მიმდინარე სესიისთვის, რაც აბრუნებს კლიენტის მისამართს ნებისმიერი თარგმანის შემდეგ. თუ ეს მნიშვნელობა კარიბჭეა და არა ლეპტოპი, მომხმარებლის მიხედვით ჰოსტის წესი ვერ იმუშავებს მონაცემთა ბაზის მანქანაზე. ჩაწერეთ დაკვირვებული მნიშვნელობა არჩეული დიზაინის გვერდით, რადგან ხელახალი კავშირები და აუზის ცვლილებები აადგილებს მას.

გახსენით მსმენელი და მეტი არაფერი

გახსენით მხოლოდ ის სერვისი, რომელიც განლაგებას სჭირდება. ნაცნობი 1433 ნაგულისხმევი ინსტანციის პორტია და არა უნივერსალური მუდმივა.

Get-NetTCPConnection -State Listen -LocalPort 1433

სახელდებული ინსტანციები ხშირად დინამიკურ პორტზე უსმენენ, SQL Server Browser კი აღმოჩენას UDP 1434-ზე პასუხობს, და ეს დამოკიდებულება ცალკე გამოვლენაა, რომელიც უნდა გამართლდეს. ინსტანციისთვის ფიქსირებული პორტის მიბმა აშორებს Browser-ის საჭიროებას და firewall წესებს სტაბილურს ხდის. შეინარჩუნეთ დაშიფვრისა და სერტიფიკატის შემოწმებები, რომლებსაც კლიენტი უკვე ასრულებს, ნაცვლად იმისა, რომ გამორთოთ ისინი ტესტის გასავლელად. შემდეგ მიეცით მონაცემთა ბაზის როლები დატვირთვას, ნაცვლად იმისა, რომ მთელი VPN ჯგუფი დაამატოთ სერვერის როლს.

დაამტკიცეთ დაშვებული ბილიკი და უარყოფილი

გახსენით ახალი სესია როგორც ჩვეულებრივი დამტკიცებული მომხმარებელი, და დაადასტურეთ სერვერის იდენტობა, მონაცემთა ბაზა და საჭირო ოპერაცია. შემდეგ დაადასტურეთ გამონაკლისი: პოლიტიკის გარეთ არსებული წყარო ან ანგარიში იმავე ტესტზე უნდა ჩავარდეს. სამუშაო სადგურის დიზაინისთვის დაადასტურეთ, რომ ლეპტოპი ვერ გვერდს აუვლის საზღვარს მონაცემთა ბაზასთან პირდაპირ მისვლით. პირდაპირი წვდომისთვის დაადასტურეთ, რომ მარშრუტი და წყაროს წესი კვლავ ძალაშია ხელახალი კავშირის შემდეგ.

ჩაწერეთ, სად იმუშავა კლიენტმა, რომელი წყარო დააკვირდა მონაცემთა ბაზამ და რომელმა წესმა დაუშვა. ეს არის ის მტკიცებულება, რომელსაც შემდეგი განხილვა მოითხოვს.