RDP ngừng sau khi cài đặt ứng dụng VPN? Thủ phạm là tường lửa

Vài phút sau khi ứng dụng VPN tiêu dùng cài xong, cổng thông tin vẫn báo VM đang chạy, IP công cộng không đổi, và RDP không phản hồi. Mọi người thường cho rằng VM bị sập hoặc nhóm bảo mật mạng đã thay đổi, và cả hai thường sai. Thứ đã thay đổi là hồ sơ tường lửa Windows mà máy đang ở trong đó, và quy tắc RDP từng khớp nay không còn khớp. Việc sửa bắt đầu bằng việc lấy một shell qua đường không phụ thuộc RDP.

VM đang chạy; quy tắc không còn khớp

Các quy tắc tường lửa trong Windows mang một bộ hồ sơ, và quy tắc giới hạn ở Riêng tư hoặc Miền không có tác dụng khi máy đang ở hồ sơ Công cộng. Trình cài VPN thêm bộ điều hợp và tuyến đường, và nhiều trình trong số đó siết chặt hồ sơ Công cộng như một tác dụng phụ. Bộ lắng nghe vẫn gắn với 3389 và các gói vẫn đến, nhưng sự không khớp hồ sơ loại bỏ chúng.

Trạng thái nguồn và khả năng tiếp cận là hai sự thật riêng biệt, và một VM đang chạy với cổng đóng trông từ bên ngoài giống hệt như một VM đã sập.

Hãy kiểm tra cổng trước khi thay đổi bất cứ điều gì. Một lần thử kết nối tới 3389 bị hết thời gian trong khi lệnh của tác nhân khách vẫn trả về đầu ra cho thấy tường lửa của máy chủ. Một cổng trả lời trong khi RDP vẫn thất bại nghĩa là lỗi nằm trên lớp mạng, và lần sửa này sẽ không chạm tới nó. Hãy ghi lại trường hợp nào trong hai trường hợp bạn đã thấy, vì phần còn lại của kế hoạch phụ thuộc vào đó.

Hai cổng đóng độc lập

Chính sách nền tảng chạy trước: nhóm bảo mật mạng thấy gói tin trước khi khách thấy. Thứ tự đó khiến một mục NSG hoàn hảo trở nên vô dụng khi máy chủ bỏ gói, và một quy tắc máy chủ đang mở trở nên vô dụng khi nền tảng từ chối nó. Hãy coi chúng là hai cổng riêng biệt và thử từng cổng một.

Hãy đọc các quy tắc hiệu lực của NSG trong cổng thông tin hoặc CLI, rồi so sánh với các quy tắc của chính khách. Đừng cho rằng thay đổi cuối cùng bạn nhớ là thay đổi đã có hiệu lực.

Một ứng dụng tiêu dùng cũng có thể cài trình điều khiển lọc hoặc công tắc ngắt chặn lưu lượng bên dưới tường lửa Windows. Nếu các quy tắc tường lửa trông đúng mà cổng vẫn thất bại, lớp đó là nghi phạm tiếp theo.

Hãy dùng tác nhân khách làm đường quay lại

Hai tính năng thực thi từ xa, Run Command và Custom Script Extension, chạy bên trong khách thông qua tác nhân nền tảng. Không tính năng nào cần RDP, nên lỗi tường lửa không ảnh hưởng tới chúng. Cả hai trả về đầu ra của script, điều này khiến chúng thành kênh chẩn đoán và đồng thời là kênh sửa chữa.

Đọc hồ sơ đang hoạt động và quy tắc RDP trước khi thay đổi bất kỳ cái nào:

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

Bật lại các quy tắc đầu vào trên hồ sơ đó là biện pháp tạm thời, không phải đích đến. Hãy dùng nó để lấy một phiên, rồi đóng lỗ hổng đúng cách:

Set-NetFirewallProfile -Name Public -AllowInboundRules True

Công tắc đó mở mọi quy tắc đầu vào trên hồ sơ, không chỉ RDP. Khi đã có phiên, hãy thay nó bằng một quy tắc giới hạn và khôi phục các cài đặt mà bạn thực sự muốn. Nếu tác nhân cũng không sẵn có, phương án dự phòng là bảng điều khiển nối tiếp hoặc một đĩa được dựng lại, và đó là lý do thực tế để giữ tác nhân khỏe mạnh.

Thu hẹp lỗ hổng trước khi đóng phiên

Thay đổi hồ sơ tạm thời là một cánh cửa để mở cho mọi quy tắc đầu vào của hồ sơ đó. Hãy thay nó bằng một quy tắc giới hạn ở địa chỉ nguồn của bạn và cổng RDP, rồi xác nhận hồ sơ đã trở về trạng thái dự kiến. Làm việc này khi bạn còn phiên, vì sai lầm tiếp theo có thể không thể đảo ngược từ xa. Hãy giữ sẵn một đường quản trị thứ hai như Bastion hoặc bảng điều khiển nối tiếp trong lúc thay đổi.

Xác nhận kết quả từ máy trạm của bạn bằng bài kiểm tra cổng, và từ bên trong khách bằng danh sách quy tắc:

Test-NetConnection -ComputerName 203.0.113.25 -Port 3389
Get-NetFirewallRule -DisplayName "RDP from admin" | Get-NetFirewallPortFilter

Bật ghi nhật ký tường lửa trong suốt thời gian kiểm tra. Một dòng về gói bị bỏ có nêu 3389 và hồ sơ đang hoạt động trả lời câu hỏi nhanh hơn một lần khởi động lại nữa.

Ngăn trình cài đặt tiếp theo làm lại điều đó

Nếu máy chủ đó không có lý do chạy ứng dụng, hãy gỡ cài đặt. Một ứng dụng đã cài là lời mời thường trực để bản cập nhật tiếp theo ghi lại hồ sơ lần nữa, và người tiếp theo sẽ gỡ lỗi cùng sự cố đó từ cổng thông tin.

Hãy chụp ảnh đĩa trước khi để bất cứ thứ gì ghi lại cài đặt mạng, và giữ sẵn một đường quản trị thứ hai trước khi bạn cần.

Ghi lại những gì trình cài đặt đã thay đổi: bộ điều hợp, tuyến đường, hồ sơ tường lửa, trình điều khiển lọc và dịch vụ. Bản ghi đó biến sự cố tiếp theo thành một mẫu đã biết thay vì một cuộc điều tra mới. Khi VM cần một đường hầm tới đúng một dịch vụ, hãy đặt ứng dụng trên máy trạm của bạn hoặc dựng liên kết site-to-site thay vì cài một sản phẩm dành cho máy tính xách tay trên máy chủ. Ứng dụng tiêu dùng nhắm tới máy tính xách tay, và máy chủ bạn quản trị từ xa không phải như vậy.