Yo'q, ulanish satri VPN tunnelingizni ishga tushira olmaydi

Ishlab chiquvchilar hanuz ulanish satri, JDBC URL yoki tnsnames.ora yozuvi VPNni tanlaydigan joyni qidirmoqda. Bunday joy yo'q. Tunnelni virtual adapter ro'yxatdan o'tkazadigan operatsion tizim yoki sotuvchi mijozi quradi, va uning ustidagi har bir ma'lumotlar bazasi kutubxonasi shundan kelib chiqadigan soket qatlamidan foydalanadi. Ulanish satri xost, port va hisob ma'lumotini nomlaydi, va butun lug'at shu.

Afsona: ulanish satri tunnelni tanlay oladi

Drayver xost va portga TCP soket ochadi. Unda tunnel ko'tarish uchun API yo'q, tunnel profili uchun maydon yo'q va VPN shlyuziga autentifikatsiya qilish usuli yo'q.

Shuning uchun marshrut paydo bo'lgach, vositalar bir xil ishlaydi. SSMS, DBeaver, Eclipse Data Tools va oddiy sqlcmd server mahalliy tarmoqda turgandek harakat qiladi, chunki soket nuqtai nazaridan shunday. Virtual adapter ma'lumotlar bazasi quyi tarmog'ini yetib boradigan qildi, va drayver buni qanday bo'lganini hech qachon bilmaydi.

Bu ulanish satri uzilgan tunnelni nega tuzata olmasligini ham tushuntiradi. Aloqa o'lganda, drayver vaqt tugashi yoki umumiy tarmoq xatosi haqida xabar beradi, va buni so'rov muammosi deb hisoblaydigan dastur kodi abadiy noto'g'ri qatlamni takrorlaydi.

Tunnelni drayver ishga tushishidan oldin ko'taring

VPNga operatsion tizim darajasida, provayder yoki tarmoq jamoasining ko'rsatmalariga amal qilib ulaning, va shundan keyingina vositani oching. Amalda bu drayver xost nomini hal qilishidan oldin ma'lumotlar bazasi quyi tarmog'iga marshrut mavjudligini bildiradi.

Tunnel nazoratini ilovadan tashqarida saqlang. Aloqani o'zi ko'tarishga urinadigan PHP yoki Java xizmati bitta provayderning xatti-harakatini biznes kodiga yozadi, va har bir nosozlik almashinuvi ilova chiqarilishiga aylanadi. Tunnelga ega bo'lgan, uni kuzatadigan va qayta ishga tushiradigan nazoratchi so'rov yo'lidan alohida masala.

Drayverni ayblashdan oldin marshrutni tekshiring: agar xost hal qilinmasa yoki port qobiqdan javob bermasa, hech qanday ulanish satri buni o'zgartirmaydi.

Afsona: Windows autentifikatsiyasi muvaffaqiyatsizligi marshrut buzilganini bildiradi

VPN orqali Windows autentifikatsiyasi ko'pincha tarmoq nosozligiga o'xshash xato bilan tugaydi, marshrut esa joyida. Hisob boshqa domenga tegishli bo'lsa va noutbuk unga qo'shila olmasa, mijozi ish stoli seansining identifikatsiyasi o'rniga aniq hisob ma'lumotlari bilan ishga tushiring.

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

/netonly kaliti bu ma'lumotlarni faqat masofaviy autentifikatsiya uchun saqlaydi. Ulanish muloqotiga ishonish o'rniga server haqiqatda nima olganini SELECT SUSER_SNAME() bilan tasdiqlang. Server manzili uchun hisob ma'lumotini Windows Credential Managerda saqlash SSMS uchun ishlaydi, lekin boshqa hisob ostida ishlaydigan xizmat uchun har doim ham emas, shuning uchun kirishni o'zgartirishdan oldin jarayon qaysi identifikatsiyadan foydalanishini tekshiring.

Kechikish server tomonidagi kursorni vaqt tugashiga aylantiradi

Server tomonidagi kursor ma'lumotlar bazasidan natijani ushlab turishni va uni bosqichma-bosqich olib kelishni so'raydi, bu bitta katta natijani ko'plab kichik borib-kelishlarga aylantiradi. Mahalliy tarmoqda bu arzon. O'nlab millisekund qo'shimcha kechikishli tunnel orqali xuddi shu so'rov deyarli hech qanday ma'lumot uzatmasdan buyruq vaqtidan oshib ketishi mumkin.

Mijoz tomonidagi kursorga o'ting, yoki olish hajmini oshirib qatorlarni guruhlang, borib-kelishlar soni kamayadi. To'siq almashinuvlar soni, nominal aloqa tezligi emas, shuning uchun o'tkazuvchanlikni o'lchash sizni chalg'itadi, borib-kelishlarni o'lchash esa chalg'itmaydi. Foydalanuvchilaringiz haqiqatan tortadigan eng katta natija to'plami bilan sinab ko'ring, darhol qaytadigan bir qatorli so'rov bilan emas. Vaqt tugashi siljisa-yu yo'qolmasa, buyruq vaqtini va olish hajmini birga oshirib qayta o'lchang.

Xuddi shu arifmetika ko'p gapiradigan ORMlarga va har bir qatorga bitta bayonot chiqaradigan har qanday mijozga tegishli. So'rov rejasi yaxshi va uzatish kichik bo'lsa, ma'lumotlar bazasini sozlashdan oldin tarmoq almashinuvlarini sanang.

Port, nusxa va mahalliy filtrni tekshiring

Nomlangan nusxa dinamik portda tinglaydi, shuning uchun 1433 deb taxmin qilish o'rniga portni tasdiqlang. Standart nusxada qiymatni nusxaning SuperSocketNetLib kaliti ostidagi TcpPort registr qiymatidan o'qish mumkin. Oracle uchun tnsnames.ora xosti hal qilinishini, manzil javob berishini va tinglovchi portiga ruxsat berilganini tekshiring; 1521 keng tarqalgan standart, kafolat emas.

Keyin tunnelning o'z kirish ro'yxatini va nihoyat mijoz va server bir xil mashina bo'lganda ham ulanishni to'sadigan mahalliy antivirus yoki xost xavfsizlik devorini istisno qiling. Konfiguratsiyani o'zgartirishdan oldin muvaffaqiyatsiz bosqichni qayd eting, chunki nom hal qilish, TCP yetib borish va TLS yoki kirish har biri boshqa xabar bilan muvaffaqiyatsiz tugaydi.

Bosqichni chiptaga yozing. Aks holda keyingi odam bularning barchasini boshlagan o'sha ulanish satri qidiruvini takrorlaydi.