Vì sao RDP bị treo khi máy tính từ xa kết nối với VPN

Bạn đang ở trong cửa sổ RDP, màn hình máy tính hiện trên màn hình, và bạn nhấn Connect trong ứng dụng VPN chạy trên máy từ xa đó. Vài giây sau cửa sổ treo rồi đóng lại. Đường hầm đã lên, đó chính là điều nhật ký VPN sẽ ghi, và đó là sự thật ít hữu ích nhất trong toàn bộ sự cố. Phiên đã chết vì máy bạn đang nói chuyện đã đổi cách trả lời bạn, nên hãy rà lại đường quay về trước khi chạm vào đường hầm.

Ghi lại điểm cuối mà phiên của bạn thực sự dùng

Địa chỉ bạn gõ vào ứng dụng RDP không nhất thiết là địa chỉ mà máy tính từ xa trả lời. NAT, một RD Gateway hay bộ cân bằng tải trước máy chủ có thể viết lại địa chỉ đó, và đường quay về được xác định bởi địa chỉ nguồn mà máy từ xa thấy trên kết nối đã thiết lập. Sai ở đây sẽ khiến bạn đi tìm một tuyến đường chưa bao giờ tham gia.

Trên máy tính từ xa, trước khi VPN được kết nối, hãy liệt kê các phiên đã thiết lập và đọc địa chỉ peer từ bảng. Sau đó ghi nó ra một chỗ bên ngoài máy đó, vì bạn sẽ không đọc được nữa sau khi phiên rơi.

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

Hãy coi địa chỉ đó là thứ phải tiếp tục truy cập được. Nếu đó là địa chỉ riêng trên một VLAN quản trị, đường hầm phải để yên con đường đó. Nếu là địa chỉ công cộng, câu trả lời phải đi ra qua đúng giao diện đã mang yêu cầu vào.

Đọc tuyến đường trả lời điểm cuối đó

Windows chọn một giao diện cho mỗi đích, và Find-NetRoute hiển thị quyết định mà nó sẽ đưa ra ngay lúc này. Chạy nó trên địa chỉ peer trước khi kết nối, rồi chạy lại khi đường hầm đã lên, và so sánh chỉ số giao diện cùng bước nhảy tiếp theo trong hai câu trả lời. Giao diện thay đổi chính là toàn bộ lỗi trong một dòng kết xuất.

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

Hồ sơ đường hầm đầy đủ cài một tuyến mặc định qua đường hầm, như hướng dẫn định tuyến VPN của Windows mô tả, nên giờ mọi câu trả lời đi ra qua VPN và phụ thuộc vào việc phía bên kia có định tuyến ngược về máy khách của bạn hay không. Hồ sơ đường hầm chia tách mặc định an toàn hơn nhưng không miễn nhiễm, vì một tuyến cụ thể bao phủ địa chỉ peer vẫn có thể thắng tuyến mặc định vật lý. Dù thế nào câu hỏi vẫn như nhau: sau khi đường hầm lên, địa chỉ peer còn phân giải về giao diện đã mang phiên vào hay không?

Nếu không, cách sửa thuộc về hồ sơ hoặc một tuyến ngoại lệ rõ ràng được chủ sở hữu chính sách VPN phê duyệt. Sửa bảng định tuyến bằng tay trên máy chủ sản xuất giữa một sự cố là cách một giải pháp tạm thời trở thành cấu hình không được ghi lại.

Theo dõi thay đổi hồ sơ tường lửa

Một giao diện mới được phân loại khi xuất hiện, và việc phân loại quyết định lưu lượng của nó được đánh giá theo hồ sơ tường lửa nào. Một bộ tiếp hợp đường hầm rơi vào hạng mục Public có thể lặng lẽ chặn RDP đi vào dù bảng định tuyến trông hoàn hảo. Đây là chế độ hỏng thứ hai, và nó tạo ra triệu chứng khác: tuyến đúng, gói tin đến nơi, và máy chủ từ chối kết nối.

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

So sánh hồ sơ gắn với giao diện đường hầm với các hồ sơ mà quy tắc Remote Desktop nhắm tới. Một quy tắc chỉ bật cho Domain và Private không làm gì cho giao diện được phân loại là Public, và không có sửa tuyến nào thay đổi điều đó. Một số ứng dụng VPN cũng giới hạn truy cập mạng con cục bộ theo thiết kế, điều này tạo ra cùng dạng hỏng từ một cơ chế khác.

Thử chuyển đổi từ một nơi mà bạn có thể quay lại

Làm toàn bộ trình tự từ một bảng điều khiển ngoài băng hoặc một đường quản trị thứ hai, theo thứ tự này: xác nhận phiên hiện có, kết nối VPN, mở phiên mới, sau đó ngắt VPN và mở thêm một phiên nữa. Mỗi bước thử một lần chuyển khác nhau, và bước hỏng trước tiên cho bạn biết cơ chế nào chịu trách nhiệm.

Lập kế hoạch quay lui trước khi bắt đầu, ví dụ một tác vụ theo lịch chạy rasdial "Work VPN" /disconnect sau một khoảng đã đặt. Điều đó biến một phiên bị mất thành gián đoạn năm phút thay vì một chuyến đến tận nơi, và đó là khoản bảo hiểm rẻ nhất trong toàn bộ quy trình.

Vào lại khi phiên đã mất rồi

Nếu máy chủ đã không thể tới được, hãy ngừng thử các kết nối RDP mới từ cùng máy khách và dùng kênh phục hồi mà môi trường đã có: một RD Gateway, một bảng điều khiển hypervisor hoặc một giao diện quản trị ngoài băng. Nhờ người có quyền truy cập bảng điều khiển chạy đúng các lệnh Find-NetRoute và Get-NetConnectionProfile, để bằng chứng sống sót qua lần phục hồi.

Sau đó hãy quyết định cách bố trí lâu dài chứ không phải cách nhanh nhất. Hoặc hồ sơ VPN giữ lại rõ ràng đường quản trị, hoặc quản trị chuyển sang một kênh không phụ thuộc tuyến mặc định của máy chủ. Cả hai đều bảo vệ được; một tuyến máy chủ với cổng mặc định đoán được thì không. Hãy ghi lại bạn chọn cách nào, và ghi lại địa chỉ peer lẽ ra phải sống sót.