Xeyr, bağlantı sətri VPN tunelinizi başlada bilməz

Tərtibatçılar hələ də bağlantı sətrinin, JDBC URL-inin və ya tnsnames.ora qeydinin VPN-i seçdiyi yeri axtarırlar. Belə bir yer yoxdur. Tunel virtual adapter qeydiyyatdan keçirən əməliyyat sistemi və ya təchizatçı müştərisi tərəfindən qurulur və onun üstündəki hər verilənlər bazası kitabxanası yaranan soket qatından istifadə edir. Bağlantı sətri host, port və etimad göstəricisi adlandırır və bütün lüğət budur.

Mif: bağlantı sətri tuneli seçə bilər

Sürücü host və porta TCP soketi açır. Onun tunel qaldırmaq üçün API-si, tunel profili üçün sahəsi və VPN şlüzuna autentifikasiya üsulu yoxdur.

Buna görə marşrut yarandıqdan sonra alətlər eyni cür davranır. SSMS, DBeaver, Eclipse Data Tools və adi sqlcmd sanki server yerli şəbəkədədir kimi işləyir, çünki soketin nöqteyi-nəzərindən elədir. Virtual adapter verilənlər bazası alt şəbəkəsini əlçatan etdi və sürücü bunun necə olduğunu heç vaxt bilmir.

Bu həm də izah edir ki, bağlantı sətri qopmuş tuneli bərpa edə bilməz. Əlaqə kəsiləndə sürücü timeout və ya ümumi şəbəkə xətası bildirir və bunu sorğu problemi kimi qəbul edən tətbiq kodu əbədi olaraq yanlış qatı təkrar yoxlayır.

Tuneli sürücü işləməzdən əvvəl qaldırın

VPN-ə əməliyyat sistemi səviyyəsində, provayderin və ya şəbəkə komandasının təlimatlarına uyğun qoşulun və yalnız sonra aləti açın. Təcrübədə bu, sürücü host adını həll etməzdən əvvəl verilənlər bazası alt şəbəkəsinə marşrutun mövcud olması deməkdir.

Tunel nəzarətini tətbiqdən kənarda saxlayın. Əlaqəni özü qaldırmağa çalışan PHP və ya Java xidməti bir provayderin davranışını biznes koduna kodlaşdırır və hər failover tətbiq buraxılışına çevrilir. Tunelə sahib olan, onu izləyən və yenidən başladan nəzarətçi sorğu yolundan ayrı bir məsələdir.

Sürücünü günahlandırmadan əvvəl marşrutu yoxlayın: əgər host həll olunmursa və ya port qabıqdan cavab vermirsə, heç bir bağlantı sətri bunu dəyişməyəcək.

Mif: Windows autentifikasiya xətası marşrutun pozulduğunu bildirir

VPN üzərindən Windows autentifikasiyası çox vaxt şəbəkə nasazlığına bənzəyən xəta ilə uğursuz olur, halbuki marşrut qaydasındadır. Hesab başqa domenə aid olduqda və noutbuk ona qoşula bilmədikdə, müştərini masaüstü sessiyasının kimliyi əvəzinə açıq etimadlarla başladın.

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

/netonly açarı bu etimadları yalnız uzaqdan autentifikasiya üçün saxlayır. Bağlantı dialoquna güvənmək əvəzinə serverin həqiqətən nə aldığını SELECT SUSER_SNAME() ilə təsdiqləyin. Server ünvanı üçün etimadın Windows Credential Manager-də saxlanması SSMS ilə işlədiyi, lakin başqa hesab altında işləyən xidmət üçün həmişə işləmədiyi bildirilir, ona görə girişi dəyişməzdən əvvəl prosesin hansı kimlikdən istifadə etdiyini yoxlayın.

Gecikmə server tərəfli kursu timeout-a çevirir

Server tərəfli kursor verilənlər bazasından nəticəni saxlamağı və onu tədricən götürməyi xahiş edir, bu da bir böyük nəticəni çoxlu kiçik gediş-gəlişə çevirir. Yerli şəbəkədə bu ucuzdur. Onlarla millisaniyə əlavə gecikməsi olan tunel üzərindən eyni sorğu çox az verilən ötürmədən əmr timeout-unu aşa bilər.

Müştəri tərəfli kursora keçin və ya fetch ölçüsünü artırın və sətirləri dəstələyin, gediş-gəliş sayı azalır. Darboğaz mübadilələrin sayıdır, nominal əlaqə sürəti deyil, ona görə ötürmə qabiliyyətini ölçmək sizi yanıldacaq, gediş-gəlişləri ölçmək isə yox. İstifadəçilərinizin həqiqətən çəkdiyi ən böyük nəticə dəsti ilə sınaqdan keçirin, dərhal qayıdan bir sətirlik sorğu ilə deyil. Timeout yerini dəyişir amma yox olmursa, əmr timeout-unu və fetch ölçüsünü birlikdə artırın və yenidən ölçün.

Eyni hesablama söhbətcil ORM-lərə və hər sətir üçün bir ifadə göndərən hər müştəriyə aiddir. Sorğu planı yaxşıdırsa və ötürmə kiçikdirsə, verilənlər bazasını tənzimləməzdən əvvəl şəbəkə mübadilələrini sayın.

Portu, instansı və yerli filtri yoxlayın

Adlandırılmış instans dinamik portda dinləyir, ona görə 1433-ü fərz etmək əvəzinə portu təsdiqləyin. Defolt instansda dəyəri instansın SuperSocketNetLib açarı altındakı TcpPort qeyd dəyərindən oxumaq olar. Oracle üçün tnsnames.ora-dakı hostun həll olunduğunu, ünvanın cavab verdiyini və listener portuna icazə verildiyini yoxlayın; 1521 ümumi defoltdur, zəmanət deyil.

Sonra tunelin öz giriş siyahısını və nəhayət, müştəri ilə server eyni maşın olsa belə bağlantını bloklayan yerli antivirus və ya host firewall-u istisna edin. Konfiqurasiyanı dəyişməzdən əvvəl uğursuz mərhələni tutun, çünki ad həlli, TCP əlçatanlığı və TLS və ya giriş hər biri fərqli mesajla uğursuz olur.

Mərhələni bilete yazın. Əks halda növbəti şəxs bunu başladan eyni bağlantı sətri axtarışını təkrarlayacaq.