Phiên bản có tên của SQL Server qua VPN: khám phá, không phải cổng 1433
Một phiên bản có tên hỏi SQL Browser về cổng trước khi kết nối. Nếu tên thất bại qua VPN nhưng tcp:host,port hoạt động, khám phá là khoảng trống.
Hầu hết mọi người coi tên máy chủ của SQL Server là một địa chỉ đầy đủ, và VPN là thứ hoặc được cho phép hoặc không. Trên thực tế, một phiên bản có tên buộc máy khách phải thực hiện tra cứu thứ hai sau DNS, và chính tra cứu đó là phần mà đường hầm hay phá vỡ nhất. Một điểm cuối rõ ràng sẽ tránh được nó, vì vậy tcp:host,port có thể hoạt động trong khi host\INSTANCE hết thời gian. Sự khác biệt nằm giữa việc tìm thấy dịch vụ và việc được phép sử dụng nó.
Huyền thoại: một tên máy chủ nghĩa là một cổng
Tên máy chủ được phân giải thành một địa chỉ, và công việc của nó kết thúc ở đó. Một phiên bản có tên thêm một tên phiên bản mà máy chủ phải dịch thành cổng TCP, và máy khách không thể đoán được. Cổng 1433 là mặc định cho phiên bản mặc định, không phải thuộc tính của mọi phiên bản trên máy. Coi hai thứ là một sẽ tạo ra triệu chứng kinh điển: ping hoạt động, DNS hoạt động, quét 1433 không cho thấy gì, và kết luận là mạng chặn SQL.
Giả định thứ hai cũng thất bại theo cách tương tự: rằng mở TCP 1433 là đủ. Nếu phiên bản lắng nghe ở nơi khác, một cổng 1433 mở chỉ chứng minh rằng có thứ khác ở đó. Cổng phải khớp với trình lắng nghe, và rằng trình lắng nghe là một chi tiết cấu hình phía máy chủ điều đó nên được hỏi thay vì đoán.
Máy khách thực sự làm gì với một phiên bản có tên
Sau khi phân giải máy chủ, máy khách gửi yêu cầu khám phá đến SQL Browser qua UDP 1434 và hỏi phiên bản có tên dùng cổng nào. Dịch vụ trình duyệt trả lời từ sổ đăng ký của chính máy chủ, sau đó máy khách mở kết nối TCP đến cổng đó. Hai giao thức và hai cổng được liên quan trước khi một lần đăng nhập được thử.
nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser
Đó là lý do tại sao chặn chỉ UDP tạo ra thời gian chờ trông giống như một máy chủ chết. Nếu dịch vụ trình duyệt bị dừng hoặc bị vô hiệu hóa, yêu cầu khám phá vẫn không có câu trả lời dù công cụ cơ sở dữ liệu đang chạy và cổng TCP của nó đang mở. Nếu phiên bản được cấu hình với cổng tĩnh, máy khách vẫn hỏi trừ khi được cung cấp điểm cuối trực tiếp. Mỗi lỗi đó trông giống hệt nhau trong thông báo lỗi của ứng dụng, và chúng cần các bản sửa khác nhau.
Dịch vụ trình duyệt là một tiện ích khám phá, không phải cơ sở dữ liệu. Dừng nó không dừng công cụ, và khởi động nó không mở cổng TCP của phiên bản.
Tại sao điểm cuối rõ ràng hoạt động khi tên không hoạt động
Một điểm cuối rõ ràng loại bỏ tra cứu khỏi trình tự: máy khách kết nối trực tiếp đến địa chỉ và cổng bạn đã nêu. Đó trước hết là chẩn đoán, không tự động là bản sửa vĩnh viễn, vì cổng có thể thay đổi nếu phiên bản sau đó được cấu hình lại thành động. Hãy so sánh hai dạng với cùng một máy khách và cùng một tài khoản trước khi kết luận.
sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433
Nếu dạng rõ ràng thành công và dạng có tên thất bại, khám phá là khoảng trống, và bạn có thể chọn cách đóng nó: cho phép UDP 1434 qua đường hầm, hoặc yêu cầu quản trị viên ghim một cổng tĩnh và ghi lại điểm cuối. Cả hai đều là quyết định có chủ đích với chi phí bảo trì khác nhau. Mở mọi cổng trong dải không phải là cả hai, và đó là tùy chọn thường được đề xuất vào cuối một ngày dài. Ghi lại lựa chọn ở nơi các chuỗi kết nối sống.
Nếu không dạng nào hoạt động, vấn đề nằm phía trên khám phá. Kiểm tra trình lắng nghe, tuyến và quy tắc truy cập cho cổng mà phiên bản thực sự dùng trước khi đổ lỗi cho dịch vụ trình duyệt.
Sau khi khám phá: xác thực và danh tính là riêng biệt
Lỗi đăng nhập là một sự kiện khác với thời gian chờ, và danh tính VPN không trở thành đăng nhập SQL nhờ có đường hầm. Khi máy khách đến đúng cổng, công cụ cơ sở dữ liệu áp dụng xác thực và quyền riêng của nó. Trộn hai giai đoạn vào một phiếu là cách một vấn đề khám phá bị giao cho nhóm sai. Đọc số lỗi trước khi thay đổi bất cứ điều gì.
Giữ tên máy chủ đã ghi lại nếu trình điều khiển xác thực chứng chỉ của máy chủ, vì kết nối bằng địa chỉ số có thể thay đổi việc kiểm tra đó thay vì giải quyết vấn đề ban đầu. Các trình điều khiển Microsoft gần đây mã hóa theo mặc định, vì vậy tên không khớp xuất hiện dưới dạng lỗi chứng chỉ sau một kết nối TCP thành công. Đó là tiến bộ, không phải thất bại mới.
Huyền thoại cần từ bỏ là tên máy chủ SQL Server là một địa chỉ đầy đủ. Đó là một máy chủ cộng thêm, đối với phiên bản có tên, một tra cứu mà đường hầm có thể không mang. Hãy nêu tên cổng, nêu tên đường khám phá, và thất bại tiếp theo sẽ cho bạn biết cần sửa lớp nào.