نه، رشته اتصال نمی‌تواند تونل VPN شما را راه‌اندازی کند

توسعه‌دهندگان همچنان به دنبال جایی هستند که یک رشته اتصال، یک JDBC URL یا یک ورودی tnsnames.ora، VPN را انتخاب کند. چنین جایی وجود ندارد. تونل را سیستم‌عامل یا کلاینت یک فروشنده که یک آداپتور مجازی ثبت می‌کند برپا می‌کند، و هر کتابخانه پایگاه داده بالای آن از لایه سوکتی که حاصل می‌شود استفاده می‌کند. رشته اتصال یک میزبان، یک پورت و یک اعتبارنامه را نام می‌برد، و کل واژگان همین است.

افسانه: رشته اتصال می‌تواند تونل را انتخاب کند

درایور یک سوکت TCP به یک میزبان و پورت باز می‌کند. هیچ API برای بالا آوردن تونل ندارد، هیچ فیلدی برای پروفایل تونل ندارد و هیچ راهی برای احراز هویت در دروازه VPN ندارد.

به همین دلیل است که ابزارها به‌محض وجود یک مسیر یکسان رفتار می‌کنند. SSMS، DBeaver، Eclipse Data Tools و یک sqlcmd ساده همه طوری عمل می‌کنند که گویی سرور در شبکه محلی است، چون از دید سوکت چنین است. آداپتور مجازی زیرشبکه پایگاه داده را قابل دسترس کرد، و درایور هرگز نمی‌داند چگونه.

این همچنین توضیح می‌دهد که چرا رشته اتصال نمی‌تواند یک تونل قطع‌شده را تعمیر کند. وقتی پیوند می‌میرد، درایور یک وقفه زمانی یا خطای عمومی شبکه گزارش می‌کند، و کد برنامه‌ای که آن را مشکل پرس‌وجو می‌داند تا ابد لایه اشتباه را تکرار می‌کند.

تونل را پیش از اجرای درایور بالا بیاورید

VPN را در سطح سیستم‌عامل، طبق دستورهای ارائه‌دهنده یا تیم شبکه وصل کنید و تنها پس از آن ابزار را باز کنید. در عمل این یعنی پیش از آنکه درایور نام میزبان را تفکیک کند، مسیری به زیرشبکه پایگاه داده وجود دارد.

نظارت بر تونل را بیرون از برنامه نگه دارید. سرویس PHP یا Java که خودش می‌کوشد پیوند را بالا بیاورد، رفتار یک ارائه‌دهنده را در کد کسب‌وکار کدگذاری می‌کند و هر جابه‌جایی در صورت خرابی به یک انتشار برنامه تبدیل می‌شود. ناظری که تونل را در اختیار دارد، آن را می‌پاید و دوباره راه‌اندازی می‌کند، موضوعی جدا از مسیر پرس‌وجو است.

پیش از سرزنش درایور، مسیر را بررسی کنید: اگر میزبان تفکیک نمی‌شود یا پورت از پوسته پاسخ نمی‌دهد، هیچ رشته اتصالی آن را تغییر نمی‌دهد.

افسانه: خطای احراز هویت Windows یعنی مسیر خراب است

احراز هویت Windows از طریق VPN اغلب با خطایی شکست می‌خورد که شبیه خرابی شبکه است، در حالی که مسیر درست است. وقتی حساب به دامنه دیگری تعلق دارد و لپ‌تاپ نمی‌تواند به آن بپیوندد، کلاینت را با اعتبارنامه صریح اجرا کنید، نه با هویت نشست دسکتاپ.

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 کار می‌کند اما همیشه برای سرویسی که زیر حساب دیگری اجرا می‌شود کار نمی‌کند، پس پیش از تغییر ورود بررسی کنید که فرایند از کدام هویت استفاده می‌کند.

تأخیر یک نشانگر سمت سرور را به وقفه زمانی تبدیل می‌کند

نشانگر سمت سرور از پایگاه داده می‌خواهد نتیجه را نگه دارد و آن را تدریجی بگیرد، که یک نتیجه بزرگ را به رفت‌وبرگشت‌های کوچک بسیاری تبدیل می‌کند. در یک LAN این ارزان است. از طریق تونلی با ده‌ها میلی‌ثانیه تأخیر افزوده، همان پرس‌وجو می‌تواند بدون انتقال داده زیاد از وقفه زمانی فرمان فراتر رود.

به نشانگر سمت کلاینت بروید، یا اندازه واکشی را بالا ببرید و ردیف‌ها را دسته‌بندی کنید، و شمار رفت‌وبرگشت‌ها کاهش می‌یابد. گلوگاه شمار تبادل‌هاست، نه سرعت اسمی پیوند، پس اندازه‌گیری توان عملیاتی شما را گمراه می‌کند در حالی که اندازه‌گیری رفت‌وبرگشت‌ها نه. با بزرگ‌ترین مجموعه نتیجه‌ای که کاربرانتان واقعاً می‌کشند آزمایش کنید، نه با پرس‌وجوی یک‌ردیفی که فوراً برمی‌گردد. اگر وقفه زمانی جابه‌جا می‌شود اما از بین نمی‌رود، وقفه زمانی فرمان و اندازه واکشی را با هم بالا ببرید و دوباره اندازه بگیرید.

همین حساب برای ORMهای پرحرف و برای هر کلاینتی که به ازای هر ردیف یک دستور صادر می‌کند صدق می‌کند. اگر طرح پرس‌وجو خوب است و انتقال کوچک است، پیش از تنظیم پایگاه داده تبادل‌های شبکه را بشمارید.

پورت، نمونه و فیلتر محلی را بررسی کنید

یک نمونه نام‌دار روی پورت پویا گوش می‌دهد، پس پورت را تأیید کنید نه اینکه 1433 را فرض کنید. در یک نمونه پیش‌فرض می‌توان مقدار را از مقدار رجیستری TcpPort زیر کلید SuperSocketNetLib همان نمونه خواند. برای Oracle بررسی کنید که میزبان در tnsnames.ora تفکیک می‌شود، نشانی پاسخ می‌دهد و پورت شنونده مجاز است؛ 1521 یک پیش‌فرض رایج است، نه تضمین.

سپس فهرست دسترسی خود تونل و در نهایت یک آنتی‌ویروس محلی یا دیوار آتش میزبان را که اتصال را حتی وقتی کلاینت و سرور یک ماشین هستند مسدود می‌کند کنار بگذارید. مرحله شکست را پیش از تغییر پیکربندی ثبت کنید، چون تفکیک نام، دسترس‌پذیری TCP و TLS یا ورود هر یک با پیام متفاوتی شکست می‌خورند.

مرحله را در تیکت بنویسید. وگرنه نفر بعدی همان جست‌وجوی رشته اتصال را که همه‌چیز با آن شروع شد تکرار می‌کند.