Không, chuỗi kết nối không thể khởi động đường hầm VPN của bạn

Các nhà phát triển vẫn tìm nơi mà một chuỗi kết nối, một URL JDBC hay một mục trong tnsnames.ora chọn VPN. Không có nơi như vậy. Đường hầm do hệ điều hành hoặc ứng dụng khách của nhà cung cấp đăng ký một bộ điều hợp ảo thiết lập, và mọi thư viện cơ sở dữ liệu bên trên đều dùng lớp socket sinh ra từ đó. Chuỗi kết nối nêu tên máy chủ, cổng và thông tin đăng nhập, và đó là toàn bộ từ vựng.

Lầm tưởng: chuỗi kết nối có thể chọn một đường hầm

Trình điều khiển mở socket TCP tới một máy chủ và cổng. Nó không có API để dựng đường hầm, không có trường cho hồ sơ đường hầm và không có cách xác thực với cổng VPN.

Đó là lý do các công cụ hành xử giống nhau khi đã có tuyến đường. SSMS, DBeaver, Eclipse Data Tools và một sqlcmd thường đều hành xử như thể máy chủ nằm trên mạng cục bộ, vì theo góc nhìn của socket thì đúng là như vậy. Bộ điều hợp ảo đã làm cho mạng con của cơ sở dữ liệu trở nên tiếp cận được, và trình điều khiển không bao giờ biết bằng cách nào.

Điều này cũng giải thích vì sao chuỗi kết nối không thể sửa một đường hầm đã rơi. Khi liên kết chết, trình điều khiển báo hết thời gian chờ hoặc lỗi mạng chung, và mã ứng dụng coi đó là vấn đề truy vấn sẽ lặp lại lớp sai mãi mãi.

Dựng đường hầm trước khi trình điều khiển chạy

Kết nối VPN ở cấp hệ điều hành, theo hướng dẫn của nhà cung cấp hoặc nhóm mạng, và chỉ sau đó mới mở công cụ. Trên thực tế điều đó có nghĩa là tuyến đường tới mạng con của cơ sở dữ liệu tồn tại trước khi trình điều khiển phân giải tên máy chủ.

Giữ việc giám sát đường hầm bên ngoài ứng dụng. Một dịch vụ PHP hoặc Java tự dựng liên kết sẽ mã hóa hành vi của một nhà cung cấp vào mã nghiệp vụ, và mỗi lần chuyển đổi khi lỗi lại thành một bản phát hành ứng dụng. Một giám sát sở hữu đường hầm, theo dõi và khởi động lại nó là vấn đề tách biệt khỏi đường đi của truy vấn.

Kiểm tra tuyến đường trước khi đổ lỗi cho trình điều khiển: nếu máy chủ không phân giải được hoặc cổng không trả lời từ shell, không chuỗi kết nối nào thay đổi được điều đó.

Lầm tưởng: xác thực Windows thất bại nghĩa là tuyến đường hỏng

Xác thực Windows qua VPN thường thất bại với lỗi trông như sự cố mạng, trong khi tuyến đường vẫn tốt. Khi tài khoản thuộc miền khác và máy tính xách tay không thể tham gia miền đó, hãy khởi động ứng dụng khách với thông tin đăng nhập rõ ràng thay vì danh tính của phiên máy tính để bàn.

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

Công tắc /netonly chỉ giữ thông tin đó cho xác thực từ xa. Xác nhận những gì máy chủ thực sự nhận được bằng SELECT SUSER_SNAME() thay vì tin vào hộp thoại kết nối. Có báo cáo rằng lưu thông tin đăng nhập cho địa chỉ máy chủ trong Windows Credential Manager hoạt động với SSMS nhưng không phải lúc nào cũng hoạt động với dịch vụ chạy dưới tài khoản khác, vì vậy hãy kiểm tra tiến trình dùng danh tính nào trước khi đổi đăng nhập.

Độ trễ biến con trỏ phía máy chủ thành hết thời gian chờ

Con trỏ phía máy chủ yêu cầu cơ sở dữ liệu giữ kết quả và lấy dần từng phần, biến một kết quả lớn thành nhiều vòng khứ hồi nhỏ. Trong mạng LAN điều đó rẻ. Qua một đường hầm có thêm hàng chục mili giây độ trễ, cùng truy vấn đó có thể vượt quá thời gian chờ của lệnh mà gần như không truyền dữ liệu.

Chuyển sang con trỏ phía máy khách, hoặc tăng kích thước lấy dữ liệu và gom các hàng thành lô, số vòng khứ hồi sẽ giảm. Nút thắt là số lần trao đổi, không phải tốc độ danh nghĩa của liên kết, nên đo thông lượng sẽ đánh lừa bạn trong khi đo vòng khứ hồi thì không. Hãy thử với tập kết quả lớn nhất mà người dùng của bạn thực sự kéo về, không phải với truy vấn một hàng trả về ngay lập tức. Nếu thời gian chờ dịch chuyển mà không biến mất, hãy tăng đồng thời thời gian chờ của lệnh và kích thước lấy dữ liệu rồi đo lại.

Cùng phép tính đó áp dụng cho các ORM lắm lời và cho mọi ứng dụng khách phát ra một câu lệnh cho mỗi hàng. Nếu kế hoạch truy vấn tốt và việc truyền tải nhỏ, hãy đếm số lần trao đổi mạng trước khi tinh chỉnh cơ sở dữ liệu.

Kiểm tra cổng, phiên bản và bộ lọc cục bộ

Một phiên bản có tên lắng nghe trên cổng động, nên hãy xác nhận cổng thay vì giả định 1433. Trên phiên bản mặc định, giá trị đọc được từ giá trị đăng ký TcpPort dưới khóa SuperSocketNetLib của phiên bản đó. Với Oracle, hãy kiểm tra máy chủ trong tnsnames.ora phân giải được, địa chỉ trả lời và cổng của trình lắng nghe được phép; 1521 là giá trị mặc định phổ biến, không phải bảo đảm.

Sau đó loại trừ danh sách truy cập của chính đường hầm và cuối cùng là phần mềm diệt virus cục bộ hoặc tường lửa máy chủ chặn kết nối ngay cả khi máy khách và máy chủ cùng một máy. Ghi lại giai đoạn thất bại trước khi đổi cấu hình, vì phân giải tên, khả năng tiếp cận TCP và TLS hoặc đăng nhập đều thất bại với thông báo khác nhau.

Viết giai đoạn đó vào phiếu. Nếu không, người tiếp theo sẽ lặp lại đúng việc tìm chuỗi kết nối đã khởi đầu mọi thứ.