RRAS trên Azure VM không được hỗ trợ: kiểm tra trước khi thiết kế

Bạn mở cổng thông tin, triển khai Windows Server 2022 vào một mạng con, và vai trò Remote Access cài đặt trơn tru. Trình tự đó chứng minh bộ cài hoạt động, không phải rằng Microsoft hỗ trợ cấu hình này. Hướng dẫn hỗ trợ phần mềm máy chủ được công bố cho máy ảo Azure liệt kê RRAS trong số các tính năng Windows Server không được hỗ trợ trên Azure VM, và đó là quyết định kiến trúc, không phải chi tiết khắc phục sự cố. Một đường hầm dựng lên không đưa việc triển khai vào bên trong ranh giới hỗ trợ.

Hướng dẫn dưới đây bắt đầu từ trang hỗ trợ, sau đó mở rộng sang các yêu cầu và lựa chọn thay thế.

Bắt đầu từ trang hỗ trợ, không phải trong phòng thí nghiệm

Hãy đọc hướng dẫn hỗ trợ Azure VM trước khi định cỡ bất cứ thứ gì. Nó tách các sản phẩm, vai trò và tính năng được hỗ trợ thay vì coi Windows Server là một khối không phân biệt. Lưu ý khối lượng công việc dự kiến thực sự nằm ở hàng nào, vì hai thành phần trông có liên quan trong bảng điều khiển có thể nằm ở các hàng khác nhau.

Viết trích dẫn vào tài liệu thiết kế khi trang còn mở. Trạng thái hỗ trợ là sự thật có nguồn, và một buổi đánh giá thiết kế không thể trích dẫn nó sẽ bị người có bản demo phản bác.

Tách hỗ trợ hệ điều hành khỏi hỗ trợ vai trò và tính năng

Cùng hướng dẫn đó liệt kê Network Policy and Access Services trong các vai trò được hỗ trợ, đồng thời liệt kê RRAS riêng là không được hỗ trợ. Hai mục đó mô tả những thứ khác nhau, và việc gộp chúng thành “truy cập từ xa được hỗ trợ” chính là cách một dự án được phê duyệt dựa trên đọc sai. Hệ điều hành được hỗ trợ không nói gì về một tính năng có hàng riêng.

Giới hạn này cũng hẹp hơn mức đôi khi được trích dẫn. Nó liên quan đến tính năng đó chạy bên trong một Azure VM; nó không có nghĩa là mạng riêng không thể kết nối với Azure, và cũng không nói RRAS không được hỗ trợ ở mọi nơi. Một phòng thí nghiệm cũ chuyển tiếp gói tin đúng là bằng chứng về gói tin, không phải về tuyên bố hỗ trợ.

Giữ hai câu hỏi đó tách biệt trong phần còn lại của dự án: nó có hoạt động không, và nó có được hỗ trợ không. Bạn sẽ cần câu trả lời khác nhau và đôi khi là người phụ trách khác nhau cho mỗi câu.

Viết ra thiết kế thực sự phải làm gì

Trước khi chọn phương án thay thế, hãy biến danh sách địa điểm thành các yêu cầu có thể đo lường sản phẩm:

• Các giao thức đường hầm mà thiết bị chi nhánh đã dùng, và liệu có địa điểm nào cần định tuyến động không.
• Các tiền tố từ xa, bao gồm mọi không gian địa chỉ chồng lấn cần dịch chứ không phải định tuyến.
• Trao đổi tuyến với Azure, và ai sở hữu từng mục trong bảng định tuyến.
• Thông lượng và số kết nối mà giờ cao điểm nhất phải chịu được.
• Hành vi chuyển đổi dự phòng mà chủ các địa điểm đã đồng ý, không chỉ cái bạn có thể xây.

NAT là hạng mục bị bỏ qua rồi sau đó quyết định toàn bộ thiết kế. Một thiết bị có thể thiết lập IPsec vẫn có thể dịch địa chỉ khác với triển khai RRAS mà nó thay thế, và điều đó thay đổi những gì chi nhánh thấy là địa chỉ nguồn và những gì nhật ký của bạn ghi lại.

Mang danh sách đến chủ mạng và xác nhận trước mọi cuộc thảo luận về sản phẩm. Yêu cầu mơ hồ biến mọi so sánh nhà cung cấp thành tranh luận sở thích.

Đánh giá phương án thay thế theo những yêu cầu đó

Các dịch vụ kết nối được quản lý của Azure và các thiết bị mạng ảo được nhà cung cấp hỗ trợ đều phải được cho điểm theo cùng một danh sách. Đừng cho rằng cái nào trong số chúng là tương đương trực tiếp của một RRAS VM chỉ vì nó có thể kết thúc IPsec: mô hình NAT và quyền sở hữu tuyến cùng thiết kế sẵn sàng cao quyết định cách các địa điểm hiện có kết nối và nơi phản hồi của chúng quay về. Cho điểm từng ứng viên trên giấy theo danh sách và ghi lại yêu cầu nào nó không đáp ứng, vì ghi chú đó khiến lựa chọn có thể được xem xét lại sau này.

Bộ cân bằng tải trước hai VM thiết bị không phải là sẵn sàng cao tự thân. Nó cung cấp một giao diện phía trước, không phải trạng thái đường hầm được đồng bộ, và một lần chuyển đổi dự phòng làm rơi mọi phiên là quyết định thiết kế mà ai đó phải thực hiện có chủ đích. Hỏi nhà cung cấp thiết bị mẫu HA được hỗ trợ là gì và liệu nó có khớp với mức sẵn sàng đã hứa với các địa điểm không. Kiểm tra chuyển đổi dự phòng trước khi các địa điểm đó phụ thuộc vào nó, và coi mỗi phiên bị mất là một phát hiện chứ không phải bất ngờ.

Khi yêu cầu thực sự đơn giản — một địa điểm, một tiền tố, không chồng lấn — dịch vụ được quản lý thường thắng về chi phí vận hành. Khi cả dịch địa chỉ và định tuyến động cùng tham gia, con đường thiết bị có thể là lựa chọn duy nhất phù hợp, và đó là lý do để lập kế hoạch di chuyển dài hơn thay vì giữ lại VM không được hỗ trợ.

Nếu một RRAS VM đã chạy

Phát hiện không phải lý do để xóa nó. Lập kế hoạch thay đổi quanh các phụ thuộc mà VM đó đã tích lũy: các tuyến mà mạng con khác dựa vào, quy tắc NAT che giấu địa chỉ nguồn, và mọi thứ mà giám sát đã học được để mong đợi từ địa chỉ của nó. Giữ lại các tuyến cần thiết và đường khôi phục đã kiểm thử trong khi mục tiêu được hỗ trợ được thiết kế và xác thực song song.

Giữ khả năng hỗ trợ và chẩn đoán kỹ thuật là những phát hiện riêng biệt suốt thời gian. Một bố trí không được hỗ trợ cũng có thể có lỗi định tuyến thông thường, và sửa lỗi đó không thay đổi trạng thái hỗ trợ của nó. Cả hai nhận định đều thuộc báo cáo, và không cái nào phủ định cái kia.

Kết thúc hướng dẫn bằng cách ghi lại trích dẫn hỗ trợ, danh sách yêu cầu, phương án thay thế đã chọn và thứ tự chuyển đổi. Bốn mục đó là điều đầu tiên một kiểm toán viên hoặc thành viên nhóm mới sẽ hỏi.