Máy tính để bàn từ xa qua VPN: bạn đang ở lỗi nào?

Đường hầm của bạn đang hoạt động, wiki nội bộ tải được, nhưng Máy tính để bàn từ xa vẫn từ chối kết nối. Sự kết hợp đó là bình thường, vì VPN cung cấp tuyến đến máy chủ trong khi dịch vụ máy tính để bàn phải đang lắng nghe, được tường lửa của chính nó cho phép và sẵn sàng xác thực tài khoản. Bốn giai đoạn lỗi nằm giữa một đường hầm hoạt động và một phiên dùng được, và mỗi giai đoạn thất bại với một thông báo khác nhau. Hãy đọc thông báo trước, vì nó nêu tên giai đoạn.

Bốn lỗi trông như một

Các giai đoạn được sắp xếp: tên phân giải thành địa chỉ riêng mà thiết kế dự kiến, cổng trả lời bắt tay TCP, máy chủ chấp nhận kết nối theo chính sách của nó, và đăng nhập phiên thành công. Mỗi giai đoạn làm giai đoạn sau không thể kiểm tra, vì vậy thay đổi cài đặt RDP trước khi mạng ổn định chỉ tạo ra nhiễu. Triệu chứng trông giống hệt nhau từ phía người dùng trong cả bốn trường hợp. Chỉ thông báo của ứng dụng khách phân biệt chúng.

Một trang web nội bộ hoạt động không chứng minh được điều nào trong bốn điều. Nó chứng minh rằng một máy chủ trên cùng mạng đã trả lời trên cổng khác với dịch vụ khác. Hãy coi đó là bằng chứng về định tuyến và không hơn.

Kiểm tra theo thứ tự và ghi lại kết quả. Nhảy đến màn hình đăng nhập vì cổng đã trả lời là cách tiêu cả buổi chiều cho một vấn đề tường lửa mà bước đầu tiên đã xác định được.

Có gì đang lắng nghe trên 3389 không?

Bắt đầu bằng tên, vì một tên phân giải thành địa chỉ sai làm vô hiệu mọi kiểm tra sau đó. Hỏi trình phân giải của đường hầm xem tên có nghĩa gì, sau đó so sánh câu trả lời với địa chỉ riêng mà thiết kế dự kiến, không phải với một phản hồi thành công. Một tên phân giải thành địa chỉ công cộng chính là toàn bộ vấn đề, và không thay đổi RDP nào sửa được nó:

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

Sau đó kiểm tra cổng chứ không phải máy chủ. Một bắt tay TCP hoàn tất trên 3389 tách khả năng tiếp cận khỏi mọi thứ bên trên:

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

Chạy thử nghiệm đó từ LAN và từ đường hầm, vì sự khác biệt giữa hai kết quả khoanh vùng lỗi trên tuyến VPN. Có hai tường lửa trên tuyến và dễ nhầm chúng: mạng phải cho phép địa chỉ đường hầm của ứng dụng khách đến được máy chủ, và tường lửa của chính máy chủ phải cho phép cùng nguồn đó trên cổng đang lắng nghe. Một quy tắc giới hạn ở mạng con LAN không bao phủ nhóm ứng dụng khách VPN, và đó là nguyên nhân phổ biến nhất của thời gian chờ mà chỉ người dùng từ xa báo cáo. Hãy kiểm tra phạm vi, không phải sự tồn tại của quy tắc.

Tuyến quay về cũng đáng được kiểm tra như vậy. Các phản hồi cần tuyến quay về nhóm ứng dụng khách chứ không phải về LAN, và một phép dịch trước máy chủ thay đổi nguồn mà nhật ký của bạn sẽ hiển thị. Nếu cổng trả lời một chiều mà không trả lời chiều kia, nửa còn thiếu thường là tuyến quay về.

Đọc thông báo trước khi đọc cấu hình

Giai đoạn thứ ba là máy chủ từ chối kết nối theo chính sách của nó, điều thường trông như một cổng mở rồi đóng ngay lập tức. Có gì đó đã trả lời, và đó là thông tin hữu ích thay vì im lặng. Nếu bắt tay hoàn tất mà phiên chết ngay, mạng vẫn ổn và máy chủ đang quyết định. Hãy xem quyền của Máy tính để bàn từ xa trước khi chạm vào mạng lần nữa.

Tính năng có thể được bật cho máy trong khi quyền truy cập bị giới hạn ở các nhóm cụ thể, và trình lắng nghe có thể được liên kết theo cách loại trừ địa chỉ mà bạn đã đến. Xác thực cấp mạng thêm một cổng thất bại trước khi máy tính để bàn tải, và văn bản lỗi của nó khác với mật khẩu sai. So sánh thông báo của ứng dụng khách với nhật ký sự kiện của máy chủ, vì thông báo nêu tên cổng còn nhật ký nêu tên tài khoản.

Đăng nhập phiên là ranh giới riêng của nó

Xác thực thuộc về dịch vụ máy tính để bàn, không phải VPN. Danh tính của đường hầm và tài khoản máy tính để bàn là thông tin đăng nhập riêng với chính sách khóa riêng, vì vậy một đường hầm hoạt động chỉ chứng minh rằng đường hầm đã chấp nhận bạn. Khóa tài khoản máy tính để bàn không làm phiền đường hầm, và ngược lại cũng đúng.

Giữ cả hai nguyên vẹn. Khi thiếu tuyến riêng, hãy sửa tuyến, vì công bố trình lắng nghe ra internet đổi một lỗi tiếp cận lấy một máy tính để bàn bị phơi bày. Cũng đừng làm yếu các kiểm tra danh tính của phiên để vượt qua một cảnh báo chứng chỉ xuất hiện cùng lúc. Chứng chỉ tự ký trên trình lắng nghe RDP tạo cảnh báo theo thiết kế, nên chấp nhận nó là một quyết định chứ không phải một bước.

Đếm số lần thử trước khi thử lại. Ngưỡng khóa của máy tính để bàn đếm các lần đăng nhập thất bại riêng với lỗi VPN, và một ứng dụng khách thử lại theo bộ hẹn giờ có thể vượt ngưỡng trong khi bạn vẫn đang sửa một quy tắc. Đó là cùng cơ chế thử lại song song khiến tài khoản bị khóa sau khi đổi mật khẩu.

Phiên có thể di chuyển gì, và nó ở lại đâu

Học quy trình đăng xuất được phê duyệt trước khi bạn cần. Đóng cửa sổ có thể chỉ ngắt chế độ xem trong khi phiên tiếp tục chạy theo chính sách đã cấu hình, điều này quan trọng trên máy chủ dùng chung hoặc bị kiểm toán. Đăng xuất từ bên trong phiên khi chính sách mong đợi điều đó.

Sau đó quyết định những gì phiên có thể mang, vì clipboard, ổ đĩa được chuyển hướng, chuyển hướng máy in và truyền tệp đều di chuyển dữ liệu giữa hệ thống cục bộ và từ xa ở nơi chính sách cho phép. Một ứng dụng đã công bố chạy ở phía bên kia không tự động là ranh giới không tải xuống, và một phiên trông như chỉ đọc vẫn có thể mang clipboard. Hãy kiểm tra công việc thật chứ không phải kết nối: mở tệp, dùng ứng dụng và xác nhận chuyển hướng bạn cần. Hướng dẫn của Microsoft về việc tiếp cận máy tính để bàn từ xa từ bên ngoài mô tả các tùy chọn phơi bày được hỗ trợ, và đó là tài liệu tham khảo tốt hơn một trình lắng nghe công cộng được thêm vào dưới áp lực.