Giá trị registry NAT-T của Windows: kiểm tra topo trước

Một kết nối VPN của Windows thất bại, tìm kiếm trả về một giá trị registry và giá trị đó được nhập vào cùng với khởi động lại. Trình tự đó đôi khi hiệu quả và không bao giờ giải thích được gì. Cài đặt đang bàn trả lời một câu hỏi về vị trí máy chủ so với thiết bị NAT, và nó vô nghĩa cho đến khi bạn biết giao thức nào đã thất bại và ở giai đoạn nào.

Giá trị thực sự chọn gì

AssumeUDPEncapsulationContextOnSendRule quyết định liệu bản triển khai IPsec của Windows có thử tạo liên kết với một đối tác phía sau thiết bị NAT hay không. Giá trị mặc định được tài liệu hóa là 0 không cho phép trường hợp đó, 1 cho phép khi máy chủ là phía sau NAT, và 2 bao trùm việc dịch địa chỉ ở cả hai đầu. Đây là những phát biểu về topo — ai ở đâu.

Đọc như một chuỗi, các con số mô tả ngày càng nhiều chuyển dịch chứ không phải ngày càng đáng tin cậy. Đặt 2 trên một mạng không dịch gì không làm kết nối nhanh hơn hay ổn định hơn, và không sửa được lỗi xác thực. Hướng dẫn NAT của Microsoft cho L2TP/IPsec ghi lại chính sách và bối cảnh nền tảng lịch sử của nó. Đối chiếu bối cảnh đó với phiên bản và vai trò Windows bạn thực sự chạy, vì một tài liệu đã sống qua nhiều bản phát hành không phải là phát biểu về mọi bản dựng hiện tại.

Khớp topo trước con số

Vẽ đường đi và đánh dấu các điểm chuyển dịch: máy khách có ở sau router gia đình không, máy chủ có ở sau bộ cân bằng tải hay tường lửa viết lại địa chỉ không, và một trong hai đầu có nằm sau chuyển dịch của nhà mạng mà bạn không kiểm soát không. Chỉ sau bản vẽ đó bạn mới quyết định được giá trị có áp dụng hay không, và cho đầu nào.

Khẳng định rằng các phiên bản Windows Server hiện tại chỉ đơn giản được phát hành với NAT traversal bị tắt là quá rộng để hành động theo. Điều quan trọng là chính sách trên hệ thống của bạn, topo phía trước nó và trao đổi đã thất bại, theo đúng thứ tự đó. Nếu cả hai đầu đều có địa chỉ công khai thì cài đặt này không phải vấn đề của bạn. Hãy xem đề xuất, chứng chỉ hoặc tài khoản thay vào đó, và để yên registry.

Kiểm tra giai đoạn hỏng trước

L2TP/IPsec tạo ra ít nhất ba kiểu hỏng khác nhau: không tới được đối tác, không thiết lập được bảo vệ IPsec, và xác thực người dùng PPP bị từ chối sau khi đường hầm tồn tại. Không thể sửa tài khoản bị từ chối bằng cách đổi chính sách NAT, và không thể sửa sự không khớp đề xuất bằng khởi động lại.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

Hết thời gian mà không có ai trả lời gợi ý khả năng tiếp cận hoặc lọc hơn là chính sách. Từ chối nhanh kèm thông báo đề xuất chỉ vào thuật toán. Hỏng sau khi đường hầm lên thuộc giai đoạn xác thực, là chủ khác và cách sửa khác.

SSTP trên HTTPS và IKEv2 gốc có nhật ký riêng và điều khiển riêng. Không thứ nào trở thành ca NAT-traversal chỉ vì chúng cũng chạy trên Windows.

Thực hiện thay đổi với đường lùi

Nếu chính sách được tài liệu hóa và topo quan sát được cùng đòi hỏi điều đó, hãy ghi lại giá trị trước, áp dụng thay đổi qua cấu hình được quản lý chứ không phải script từng hồ sơ, và lên kế hoạch khởi động lại. Trên một máy chủ còn gánh khối lượng công việc khác, đây không phải chỉnh sửa vô hại.

Thiết bị NAT vẫn phải mang lưu lượng đóng gói và lưu lượng trở về. Một giá trị registry không tạo quy tắc chuyển tiếp, không căn chỉnh đề xuất và không xác thực danh tính, nên một kết nối bắt đầu hoạt động sau thay đổi có thể đang hoạt động vì lý do hoàn toàn khác. Kiểm tra lại giao thức gốc với topo gốc, rồi ghi lại giai đoạn nào đã hỏng và vì sao người ta kỳ vọng giá trị đó khắc phục. Chính câu đó biến một tin đồn internet thành cấu hình bạn có thể bảo vệ.