رفع خطای 233 SQL Server: راهنمای جامع مشکل اتصال Pre-login Handshake

رفع خطای 233 SQL Server: راهنمای جامع مشکل اتصال Pre-login Handshake

خطای 233 در SQL Server با پیغام “The client was unable to establish a connection because of an error during pre-login handshake” یکی از مشکلات رایج است که مدیران پایگاه داده و توسعه‌دهندگان با آن مواجه می‌شوند. این خطا نشان‌دهنده‌ی عدم توانایی کلاینت (برنامه کاربردی یا ابزار مدیریت) در برقراری ارتباط با سرور SQL Server در مراحل اولیه اتصال است، یعنی حتی پیش از مرحله احراز هویت. “Pre-login handshake” یا “مذاکره پیش از ورود” فرآیندی حیاتی است که در آن کلاینت و سرور پروتکل‌ها، گزینه‌های رمزگذاری (مانند SSL/TLS) و سایر تنظیمات لازم برای برقراری ارتباط ایمن و کارآمد را قبل از شروع هرگونه تبادل اطلاعات کاربری، با یکدیگر هماهنگ می‌کنند. این خطا می‌تواند به دلایل مختلفی از جمله مشکلات شبکه، پیکربندی نادرست سرور SQL، فایروال‌ها یا مسائل مربوط به گواهینامه‌های امنیتی رخ دهد و مانع از دسترسی برنامه‌ها به داده‌ها شود. درک عمیق علت این خطا و مراحل رفع آن برای حفظ پایداری و در دسترس بودن سیستم‌های مبتنی بر SQL Server ضروری است.

علل رایج خطای 233 در SQL Server

خطای 233 معمولاً به دلیل یکی از مشکلات زیر در فرآیند مذاکره اولیه بین کلاینت و سرور SQL رخ می‌دهد:

1. مشکلات شبکه و اتصال

* **فایروال (Firewall):** یکی از شایع‌ترین دلایل، مسدود شدن پورت‌های SQL Server توسط فایروال ویندوز یا فایروال شبکه است. اگر فایروال مانع از رسیدن بسته‌های اولیه اتصال به سرور SQL شود، فرآیند مذاکره هرگز کامل نخواهد شد.
* **پیکربندی نادرست آدرس IP یا نام سرور:** تایپ اشتباه آدرس IP سرور، نام میزبان (hostname) یا نام نمونه (instance name) SQL Server (به عنوان مثال، هنگام استفاده از نمونه‌های نام‌گذاری شده مانند `SERVERNAME\INSTANCENAME`) می‌تواند منجر به عدم یافتن سرور توسط کلاینت شود.
* **مسائل DNS:** اگر DNS قادر به ترجمه نام سرور به آدرس IP صحیح نباشد، کلاینت نمی‌تواند به سرور متصل شود.
* **مشکلات زیرساخت شبکه:** کابل‌های قطع شده، پیکربندی اشتباه روترها یا سوئیچ‌ها و سایر مشکلات فیزیکی یا منطقی شبکه نیز می‌توانند باعث این خطا شوند.

2. سرویس SQL Server متوقف شده یا غیرفعال

* **سرویس SQL Server (MSSQLSERVER) متوقف شده:** اگر سرویس اصلی SQL Server روی سرور در حال اجرا نباشد، هیچ پاسخی به درخواست‌های اتصال کلاینت نخواهد داد و handshake شکست می‌خورد.
* **سرویس SQL Server Browser متوقف شده (برای نمونه‌های نام‌گذاری شده):** برای اتصال به نمونه‌های نام‌گذاری شده (named instances) SQL Server، سرویس SQL Server Browser ضروری است. این سرویس به کلاینت‌ها کمک می‌کند تا شماره پورت دینامیک (dynamic port) نمونه نام‌گذاری شده را پیدا کنند. اگر این سرویس متوقف باشد، کلاینت نمی‌تواند نمونه را پیدا کند و اتصال برقرار نمی‌شود.

3. پیکربندی پروتکل‌های شبکه در SQL Server

* **پروتکل TCP/IP غیرفعال:** SQL Server برای ارتباطات شبکه از پروتکل‌های مختلفی مانند TCP/IP و Named Pipes استفاده می‌کند. اگر پروتکل TCP/IP در SQL Server Configuration Manager غیرفعال باشد، کلاینت‌ها نمی‌توانند از طریق شبکه به سرور متصل شوند.
* **پورت‌های اشتباه یا دینامیک:** SQL Server به صورت پیش‌فرض از پورت 1433 برای نمونه‌های پیش‌فرض (default instances) استفاده می‌کند. اما نمونه‌های نام‌گذاری شده ممکن است از پورت‌های دینامیک استفاده کنند. اگر کلاینت تلاش کند به پورت اشتباهی متصل شود یا اگر سرویس Browser برای حل پورت‌های دینامیک در دسترس نباشد، خطای 233 رخ می‌دهد.

4. مشکلات مربوط به TLS/SSL و گواهینامه‌ها

* **گواهینامه SSL/TLS نامعتبر یا منقضی شده:** در صورتی که SQL Server برای رمزگذاری اتصالات از SSL/TLS استفاده کند، گواهینامه سرور باید معتبر باشد. اگر گواهینامه منقضی شده، نامعتبر باشد، یا توسط کلاینت قابل اعتماد نباشد، فرآیند handshake SSL/TLS قبل از ورود شکست می‌خورد.
* **تنظیمات TLS/SSL نامنطبق:** کلاینت و سرور باید بتوانند یک نسخه (مثلاً TLS 1.2) و الگوریتم رمزگذاری مشترک را برای برقراری ارتباط امن مذاکره کنند. اگر تنظیمات در هر دو طرف با هم سازگار نباشند، handshake با خطا مواجه می‌شود.

5. درایورهای کلاینت قدیمی یا ناسازگار

* **درایورهای قدیمی:** استفاده از درایورهای قدیمی SQL Server Native Client یا ADO.NET در برنامه کلاینت ممکن است با نسخه‌های جدیدتر SQL Server یا تنظیمات امنیتی TLS ناسازگار باشد و منجر به خطای handshake شود.

راهکارهای عملی برای رفع خطای 233 SQL Server

برای رفع خطای 233 SQL Server، لازم است یک رویکرد سیستماتیک را دنبال کنید و هر یک از علل احتمالی را بررسی و برطرف کنید.

مرحله 1: بررسی وضعیت سرویس SQL Server

اولین گام این است که اطمینان حاصل کنید که سرویس SQL Server در حال اجرا است.

1. **باز کردن Services Manager:** در ویندوز، `services.msc` را در کادر جستجو تایپ کرده و Enter را فشار دهید.
2. **یافتن سرویس SQL Server:** به دنبال سرویس‌هایی باشید که با “SQL Server (” شروع می‌شوند. برای نمونه پیش‌فرض، معمولاً “SQL Server (MSSQLSERVER)” است. برای نمونه‌های نام‌گذاری شده، نام نمونه در پرانتز قرار دارد (مثلاً “SQL Server (SQLEXPRESS)”).
3. **اطمینان از اجرای سرویس:** مطمئن شوید که “Status” سرویس “Running” است. اگر متوقف شده است، روی آن کلیک راست کرده و “Start” را انتخاب کنید.

همچنین، اگر از نمونه‌های نام‌گذاری شده استفاده می‌کنید، سرویس “SQL Server Browser” را نیز بررسی کنید و مطمئن شوید که در حال اجراست. اگر متوقف است، آن را Start کنید و نوع Startup Type را روی “Automatic” تنظیم کنید.

مرحله 2: بررسی اتصال شبکه و فایروال

این مرحله شامل اطمینان از دسترسی کلاینت به سرور از طریق شبکه و عدم مسدود شدن پورت‌ها توسط فایروال است.

1. **آزمایش Ping:** از خط فرمان (Command Prompt) در سیستم کلاینت، سرور SQL Server را پینگ کنید تا مطمئن شوید که قابل دسترس است.

ping YourSQLServerName

یا

ping YourSQLServerIPAddress

اگر پینگ موفقیت‌آمیز نبود، مشکل از زیرساخت شبکه است و باید توسط تیم شبکه بررسی شود (مانند کابل‌کشی، تنظیمات IP، DNS).

2. **آزمایش Telnet به پورت SQL Server:** از خط فرمان در کلاینت، تلاش کنید به پورت SQL Server تلنت کنید. این کار نشان می‌دهد که آیا پورت توسط فایروال مسدود شده است یا خیر.

telnet YourSQLServerName 1433

اگر از نمونه‌های نام‌گذاری شده یا پورت‌های سفارشی استفاده می‌کنید، پورت صحیح را جایگزین `1433` کنید. اگر پنجره Command Prompt پاک شد (یا یک صفحه سیاه نمایش داده شد)، اتصال موفقیت‌آمیز است. اگر پیام خطا “Could not open connection to the host” یا مشابه آن را دریافت کردید، به احتمال زیاد فایروال (یا شبکه) پورت را مسدود کرده است.

3. **تنظیمات فایروال ویندوز (روی سرور SQL):**
* در سرور SQL Server، “Windows Defender Firewall with Advanced Security” را باز کنید.
* به “Inbound Rules” بروید.
* یک قانون جدید (New Rule) برای پورت TCP اضافه کنید:
* Rule Type: `Port`
* Protocols and Ports: `TCP`, `Specific local ports: 1433` (یا پورت سفارشی خودتان)
* Action: `Allow the connection`
* Profile: همه پروفایل‌ها را انتخاب کنید (Domain, Private, Public)
* Name: یک نام مناسب (مثلاً `SQL Server Port 1433`)

اگر از نمونه‌های نام‌گذاری شده و پورت‌های دینامیک استفاده می‌کنید، باید برای `sqlservr.exe` نیز یک قانون Inbound ایجاد کنید تا فایروال آن را مجاز کند. مسیر معمولاً `C:\Program Files\Microsoft SQL Server\MSSQLXX.InstanceName\MSSQL\Binn\sqlservr.exe` است.

مرحله 3: پیکربندی پروتکل‌های SQL Server

اطمینان حاصل کنید که SQL Server برای گوش دادن به اتصالات شبکه پیکربندی شده است.

1. **باز کردن SQL Server Configuration Manager:** در ویندوز، “SQL Server Configuration Manager” را جستجو و باز کنید.
2. **بررسی پروتکل‌های کلاینت:** در قسمت “SQL Native Client Configuration” یا “SQL Server Network Configuration” (بسته به نسخه SQL Server)، “Protocols for MSSQLSERVER” (یا نام نمونه شما) را باز کنید.
3. **فعال‌سازی TCP/IP:** مطمئن شوید که پروتکل “TCP/IP” فعال (Enabled) است. اگر غیرفعال است، روی آن راست کلیک کرده و “Enable” را انتخاب کنید.

(Protocol Name: TCP/IP, Status: Enabled)

4. **پورت‌های TCP/IP:** روی “TCP/IP” راست کلیک کرده و “Properties” را انتخاب کنید. به تب “IP Addresses” بروید.
* پیمایش کنید تا بخش “IPAll” را پیدا کنید.
* مطمئن شوید که “TCP Dynamic Ports” خالی است (اگر می‌خواهید از پورت ثابت استفاده کنید) و “TCP Port” روی `1433` (یا پورت ثابت مورد نظر شما) تنظیم شده است.
* اگر از پورت‌های دینامیک برای نمونه‌های نام‌گذاری شده استفاده می‌کنید، مطمئن شوید که “SQL Server Browser” فعال و در حال اجرا است.
* پس از هرگونه تغییر، سرویس SQL Server را ریستارت کنید.

مرحله 4: بررسی نام سرور و رشته اتصال (Connection String)

اطمینان حاصل کنید که کلاینت شما از نام سرور و اطلاعات اتصال صحیح استفاده می‌کند.

1. **نام سرور:** بررسی کنید که نام سروری که در رشته اتصال یا ابزار مدیریتی (مانند SSMS) وارد می‌کنید، دقیقاً با نام سرور SQL Server یا آدرس IP آن مطابقت دارد.
* برای نمونه پیش‌فرض: `YourSQLServerName` یا `YourSQLServerIPAddress`
* برای نمونه نام‌گذاری شده: `YourSQLServerName\InstanceName` یا `YourSQLServerIPAddress\InstanceName`
* **مثال:**

Server=localhost;Database=myDataBase;User Id=myUsername;Password=myPassword;

یا

Server=YourSQLServerName\SQLEXPRESS;Database=AdventureWorks;Integrated Security=True;

2. **بررسی Connection String:** اگر از یک برنامه کاربردی متصل می‌شوید، رشته اتصال (connection string) را بررسی کنید تا مطمئن شوید که صحیح است. استفاده از نام سرور کامل (FQDN) نیز می‌تواند مفید باشد.

Data Source=your_server_name.your_domain.com,1433;Initial Catalog=your_database;Integrated Security=SSPI;

یا

Server=tcp:your_server_name,1433;Initial Catalog=your_database;Persist Security Info=False;User ID=your_user;Password=your_password;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=True;Connection Timeout=30;

نکته: پارامتر `Encrypt=True` به SQL Server دستور می‌دهد تا ترافیک را رمزگذاری کند. اگر سرور شما گواهینامه معتبری ندارد و شما `TrustServerCertificate=False` را تنظیم کرده‌اید، این می‌تواند باعث شکست handshake شود. برای آزمایش، می‌توانید `Encrypt=False` را موقتاً امتحان کنید، اما برای محیط تولید توصیه نمی‌شود.

مرحله 5: بررسی مشکلات TLS/SSL و گواهینامه‌ها

اگر سرور SQL Server شما برای رمزگذاری اتصال (Encryption) پیکربندی شده است، گواهینامه‌های امنیتی نقش حیاتی ایفا می‌کنند.

1. **بررسی گواهینامه سرور:**
* در SQL Server Configuration Manager، به “SQL Server Network Configuration” بروید و روی “Protocols for MSSQLSERVER” (یا نمونه شما) راست کلیک کرده و “Properties” را انتخاب کنید.
* به تب “Certificate” بروید.
* مطمئن شوید که یک گواهینامه معتبر (Valid Certificate) انتخاب شده است و منقضی نشده باشد. اگر نیاز به انتخاب گواهینامه جدید دارید، آن را از لیست انتخاب کرده و سرویس SQL Server را ریستارت کنید.

2. **بررسی تنظیمات TLS:**
* مطمئن شوید که نسخه‌های TLS فعال روی سرور و کلاینت با یکدیگر سازگار هستند. گاهی اوقات غیرفعال کردن نسخه‌های قدیمی TLS (مانند TLS 1.0 یا 1.1) در سرور، بدون به‌روزرسانی درایورهای کلاینت یا سیستم‌عامل، می‌تواند منجر به این خطا شود.
* می‌توانید از ابزارهایی مانند `IIS Crypto` (برای ویندوز سرور) برای مدیریت آسان تنظیمات TLS/SSL استفاده کنید.

3. **TrustServerCertificate:** در برخی سناریوها، اگر گواهینامه سرور توسط کلاینت قابل اعتماد نباشد (مثلاً گواهینامه خود امضا شده یا CA نامعتبر)، تنظیم پارامتر `TrustServerCertificate=True` در رشته اتصال می‌تواند به کلاینت اجازه دهد بدون اعتبار سنجی دقیق گواهینامه به سرور متصل شود. این روش برای محیط‌های توسعه و تست مفید است اما برای محیط‌های تولید توصیه نمی‌شود، زیرا مسائل امنیتی را نادیده می‌گیرد.

مرحله 6: به‌روزرسانی درایورهای کلاینت

اطمینان حاصل کنید که درایورهای SQL Server Native Client یا ADO.NET شما به‌روز هستند.

1. **بررسی و به‌روزرسانی:** اگر از درایورهای قدیمی استفاده می‌کنید، به خصوص با نسخه‌های جدیدتر SQL Server یا پیکربندی‌های امنیتی TLS، ممکن است نیاز به به‌روزرسانی داشته باشید. جدیدترین نسخه درایور SQL Server Native Client یا Microsoft.Data.SqlClient (برای .NET) را نصب کنید.
2. **مثال نصب درایور برای .NET:**

Install-Package Microsoft.Data.SqlClient

این فرمان (در کنسول Package Manager در Visual Studio) جدیدترین درایور ADO.NET را برای اتصال به SQL Server نصب می‌کند.

مرحله 7: بررسی Event Logs سرور

Event Viewer در سرور SQL Server می‌تواند اطلاعات مفیدی درباره دلیل شکست اتصال ارائه دهد.

1. **باز کردن Event Viewer:** در ویندوز، `eventvwr.msc` را جستجو و باز کنید.
2. **بررسی Application and System Logs:**
* به `Windows Logs` -> `Application` بروید.
* به دنبال رویدادهایی با منبع “MSSQLSERVER” یا “SQL Browser” بگردید که در زمان تلاش برای اتصال رخ داده‌اند.
* به `Windows Logs` -> `System` بروید و به دنبال خطاهای مربوط به شبکه یا SSL/TLS بگردید.

این لاگ‌ها می‌توانند پیام‌های خطای دقیق‌تری مانند مشکلات گواهینامه، خطاهای پروتکل یا مشکلات شبکه را نشان دهند که به شما در تشخیص دقیق‌تر مشکل کمک می‌کنند.

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