SQL Server به نشانی VPN متصل می‌شود که هنگام بوت وجود ندارد

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

از گزارش راه‌اندازی شروع کنید، نه از کلاینت

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

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

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

ترتیب اتصالی را که موتور واقعاً دنبال می‌کند مرور کنید

موتور پیکربندی شنوندهٔ خود را می‌خواند و سپس از سیستم‌عامل می‌خواهد که متصل کند. اگر نشانی در آن لحظه محلی نباشد، اتصال برای آن نشانی شکست می‌خورد در حالی که بقیهٔ نمونه ممکن است عادی ادامه یابد. به همین دلیل پروتکل‌ها یا نشانی‌های دیگر هنوز می‌توانند کار کنند، و به همین دلیل «SQL Server پایین است» خلاصهٔ نادرستی است. نقطهٔ پایانی دقیق را از گزارش نگه دارید: نشانی، درگاه و پروتکل، زیرا اصلاح بستگی دارد به اینکه کدام‌یک از این سه اشتباه است.

راه‌اندازی دوبارهٔ سرویس پس از ظاهر شدن آداپتور معمولاً شنونده را موفق می‌کند، و این دقیقاً همان تله است. این کار وابستگی را اثبات می‌کند نه اینکه آن را بردارد، و هر بار که تونل دوباره متصل شود همهٔ کاربران متصل را قطع می‌کند.

شنونده را همان‌گونه که موتور می‌خواند بخوانید

در SQL Server Configuration Manager ویژگی‌های TCP/IP نمونه را باز کنید و پیش از ویرایش نشانی‌های جداگانه به تنظیم Listen All توجه کنید. وقتی Listen All روی Yes است، مقادیر Enabled هر نشانی نادیده گرفته می‌شوند، پس ویرایش آن‌ها چیزی را که شنونده استفاده می‌کند تغییر نمی‌دهد. سه چیز را به ترتیب ثبت کنید: نشانی‌ای که قصد سرویس‌دهی به آن را دارید، درگاه، و اینکه شنونده باید همهٔ نشانی‌ها را پوشش دهد یا فقط یکی را. سپس تغییر را از طریق رویهٔ راه‌اندازی مجاز اعمال کنید و گزارش راه‌اندازی بعدی را بخوانید تا تأیید کنید موتور همان چیزی را که خواستید متصل کرده است.

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

به کلاینت مقصدی پایدار بدهید

کلاینت نیازی ندارد که میزبان پایگاه داده نشانی استخر بپوشد. طراحی مسیریابی‌شده کار می‌کند در حالی که سرور روی نشانی خصوصی پایدارش گوش می‌دهد و دروازهٔ VPN ترافیک کلاینت را به آن می‌فرستد و پاسخ را بازمی‌گرداند.

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

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

نقطهٔ پایانی‌ای را که کلاینت استفاده کرد بررسی کنید

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

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

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