SSH đến IP công khai của máy chủ WireGuard thất bại trên Windows

Những đường hầm dựng lên trong khi SSH đến địa chỉ công khai của máy chủ ngừng hoạt động trông giống như máy chủ từ chối kết nối. Trên Windows nguyên nhân khả dĩ hơn là cục bộ: AllowedIPs của đường hầm đầy đủ là /0 bật các quy tắc tường lửa hạn chế, chỉ cho phép lưu lượng của chính đường hầm và rất ít thứ khác. Các gói đã mã hóa đến địa chỉ đó không nói gì về việc một kết nối TCP riêng đến cùng địa chỉ có được phép đi ra hay không.

Tách địa chỉ công khai của điểm cuối khỏi địa chỉ đường hầm bên trong của nó trước khi chạm vào danh sách peer. Gần như mọi nỗ lực sửa việc này bằng cách chỉnh sửa AllowedIPs đều làm chính sách yếu đi thay vì làm tuyến đường đúng.

Quyền định tuyến và quyền tường lửa là khác nhau

Tuyến đường quyết định gói tin sẽ được gửi đi đâu, còn quy tắc tường lửa quyết định gói tin có được gửi hay không. Vì vậy việc thêm tuyến đường cho IP công khai của điểm cuối tạo ra một đường đi mà bộ lọc vẫn có thể chặn, và chính sự nhầm lẫn đó là thứ triệu chứng này tạo ra. Trên Windows bộ lọc là một phần của cách triển khai chứ không phải phần thêm vào, nên không mục tuyến đường nào thay đổi nó. Hai quyết định này cũng tách biệt ở nơi khác, dù giá trị mặc định khác nhau.

Đó là lý do một traceroute đến điểm cuối có thể thành công trong khi một lần thử SSH thất bại. Cái đầu do dịch vụ sở hữu ngoại lệ mang, cái sau thì không.

Điều /0 làm trên Windows

Khi một peer duy nhất có các địa chỉ được phép bao phủ toàn bộ không gian IPv4, WireGuard for Windows áp dụng thế phòng thủ hạn chế của tường lửa, chặn lưu lượng mà nếu không sẽ đi ra ngoài đường hầm. Lưu lượng của chính dịch vụ đường hầm được cho phép, vì VPN không thể hoạt động nếu không có nó. Một ứng dụng khác đến cùng địa chỉ công khai không nhận được quyền đó, vì ngoại lệ thuộc về lưu lượng chứ không thuộc về địa chỉ. Ghi chú mạng của Windows mô tả hành vi này và điều khiển liên quan trong trình biên tập.

Những quy tắc đó là cơ chế đằng sau cụm từ kill switch. Chúng được kích hoạt bởi hình dạng của cấu hình chứ không bởi một hộp kiểm mang tên đó.

Các ngoại lệ thay đổi mô hình bảo vệ

Thay /0 bằng hai tiền tố nửa mặc định là cách được ghi nhận để giữ định tuyến rộng mà không có ngữ nghĩa hạn chế, và đó là một mô hình bảo vệ khác, không phải cách viết ngắn hơn. Trừ địa chỉ điểm cuối khỏi các tiền tố được phép là cách xử lý phổ biến còn lại, kéo dài danh sách và cũng thay đổi những quy tắc nào được kích hoạt. Không cái nào là chỉnh sửa cục bộ với hiệu ứng cục bộ. Mỗi cách đều dịch chuyển ranh giới cho mọi luồng trên máy, không chỉ cho kết nối bạn đang sửa.

Ở nơi thực sự cần SSH công khai trực tiếp, chủ sở hữu hồ sơ phải thiết kế cả tuyến đường bên ngoài lẫn quyền tường lửa của nó, và quyết định điều gì xảy ra với lưu lượng không liên quan khi đường hầm sập. Việc xem xét IPv4 và IPv6 riêng rẽ cũng thuộc phần đó, vì các quy tắc được diễn đạt theo họ địa chỉ. Một đường vòng rộng được thêm vào để cứu một phiên quản trị thường phơi bày nhiều hơn chính phiên đó.

Kiểm tra đường quản trị bạn đã chọn

Trước tiên hãy quyết định quản trị nên đi bên trong hay bên ngoài đường hầm, sau đó kiểm tra chính lựa chọn đó thay vì cả hai cùng lúc. Các lệnh dưới đây kiểm tra địa chỉ của máy khách, trạng thái peer và kết nối đến từng mục tiêu. Chạy chúng từ máy khách Windows khi đường hầm đang dựng.

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

Một SSH thành công đến địa chỉ bên trong chứng minh đường hầm mang lưu lượng quản trị và tường lửa của chính máy chủ chấp nhận nó từ dải peer. Thất bại ở cả hai mục tiêu là vấn đề phía máy chủ hoặc khóa, không phải định tuyến của Windows. Nếu địa chỉ bên trong hoạt động còn địa chỉ bên ngoài thì không, thế phòng thủ tường lửa cục bộ đang làm đúng điều nó được thiết kế để làm. Đọc ba kết quả theo thứ tự đó trước khi chỉnh sửa hồ sơ.

Ghi lại đường quản trị, địa chỉ đã dùng và hành vi khi đường hầm xuống. Chính ghi chú đó ngăn người tiếp theo mở rộng đường vòng để tiết kiệm năm phút.