არა, კავშირის სტრიქონი ვერ გაუშვებს თქვენს VPN გვირაბს

დეველოპერები კვლავ ეძებენ ადგილს, სადაც კავშირის სტრიქონი, JDBC URL ან tnsnames.ora-ს ჩანაწერი ირჩევს VPN-ს. ასეთი ადგილი არ არსებობს. გვირაბს ქმნის ოპერაციული სისტემა ან მომწოდებლის კლიენტი, რომელიც ვირტუალურ ადაპტერს არეგისტრირებს, და მის ზემოთ ყველა მონაცემთა ბაზის ბიბლიოთეკა იმ სოკეტის შრეს იყენებს, რომელიც ამით მიიღება. კავშირის სტრიქონი ასახელებს ჰოსტს, პორტს და სერტიფიკატს, და ეს არის მთელი ლექსიკა.

მითი: კავშირის სტრიქონს შეუძლია გვირაბის არჩევა

დრაივერი ხსნის TCP სოკეტს ჰოსტისა და პორტისკენ. მას არ აქვს API გვირაბის ასაწევად, არ აქვს ველი გვირაბის პროფილისთვის და არ აქვს გზა VPN კარიბჭესთან ავტორიზაციისთვის.

ამიტომ იარაღები იდენტურად იქცევიან, როცა მარშრუტი არსებობს. SSMS, DBeaver, Eclipse Data Tools და ჩვეულებრივი sqlcmd ისე იქცევიან, თითქოს სერვერი ლოკალურ ქსელშია, რადგან სოკეტის თვალსაზრისით ასეცაა. ვირტუალურმა ადაპტერმა მონაცემთა ბაზის ქვექსელი ხელმისაწვდომი გახადა, და დრაივერმა არასოდეს იცის როგორ.

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

გვირაბი ასწიეთ დრაივერის გაშვებამდე

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

გვირაბზე ზედამხედველობა აპლიკაციის გარეთ შეინახეთ. PHP ან Java სერვისი, რომელიც თავად ცდილობს კავშირის აწევას, ერთი მომწოდებლის ქცევას ბიზნეს კოდში წერს, და ყოველი მარცხის გადართვა აპლიკაციის გამოშვებად იქცევა. ზედამხედველი, რომელიც ფლობს გვირაბს, აკვირდება და ხელახლა უშვებს, მოთხოვნის გზისგან ცალკე საკითხია.

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

მითი: Windows-ის ავტორიზაციის მარცხი ნიშნავს, რომ მარშრუტი გატეხილია

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

runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

/netonly გადამრთველი ინახავს ამ სერტიფიკატებს მხოლოდ დისტანციური ავტორიზაციისთვის. დაადასტურეთ, რა მიიღო სერვერმა სინამდვილეში, SELECT SUSER_SNAME()-ით, ნაცვლად იმისა, რომ კავშირის დიალოგს ენდოთ. ვრცელდება ინფორმაცია, რომ სერვერის მისამართის სერტიფიკატის Windows Credential Manager-ში შენახვა მუშაობს SSMS-ისთვის, მაგრამ არა ყოველთვის სხვა ანგარიშით მომუშავე სერვისისთვის, ამიტომ შესვლის შეცვლამდე შეამოწმეთ, რომელ იდენტობას იყენებს პროცესი.

დაყოვნება სერვერის მხარის კურსორს დროის ამოწურვად აქცევს

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

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

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

შეამოწმეთ პორტი, ეგზემპლარი და ლოკალური ფილტრი

სახელდებული ეგზემპლარი დინამიურ პორტზე უსმენს, ამიტომ დაადასტურეთ პორტი და ნუ ჩათვლით 1433-ს. ნაგულისხმევ ეგზემპლარზე მნიშვნელობა იკითხება TcpPort რეესტრის მნიშვნელობიდან ეგზემპლარის SuperSocketNetLib გასაღების ქვეშ. Oracle-ისთვის შეამოწმეთ, რომ tnsnames.ora-ს ჰოსტი იხსნება, მისამართი პასუხობს და მსმენელის პორტი დაშვებულია; 1521 გავრცელებული ნაგულისხმევია და არა გარანტია.

შემდეგ გამორიცხეთ თავად გვირაბის წვდომის სია და, ბოლოს, ლოკალური ანტივირუსი ან ჰოსტის ფაირვოლი, რომელიც კავშირს ბლოკავს მაშინაც, როცა კლიენტი და სერვერი ერთი მანქანაა. ჩაწერეთ წარუმატებელი ეტაპი კონფიგურაციის შეცვლამდე, რადგან სახელის ამოხსნა, TCP ხელმისაწვდომობა და TLS ან შესვლა თითოეული სხვადასხვა შეტყობინებით მარცხდება.

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