VPN site-to-site Azure với một peer sau NAT: danh sách kiểm tra

Thực hiện các bước kiểm tra này theo thứ tự và dừng ở bước đầu tiên thất bại. Hầu hết báo cáo rằng Azure không hỗ trợ thiết bị sau NAT thực ra là địa chỉ peer mà Azure không thể tiếp cận, hoặc một đường hầm không bao giờ khởi tạo từ phía đúng. Truyền tải bên ngoài và định tuyến bên trong là hai vấn đề khác nhau, và trộn chúng sẽ mất một buổi chiều. Mỗi bước dưới đây tạo ra một quan sát mà bạn có thể chuyển cho người khác.

Bước 1: xác nhận peer thực sự nằm sau NAT

So sánh địa chỉ trên giao diện WAN của thiết bị với địa chỉ mà Azure nhìn thấy cho nó. Nếu chúng khác nhau, có gì đó đang dịch, và bộ dịch đó giờ là một phần trong thiết kế VPN của bạn. Hỏi nhà cung cấp xem ánh xạ là tĩnh hay chia sẻ, vì ánh xạ chia sẻ thay đổi những gì bạn có thể dựa vào. Một thiết bị có địa chỉ WAN riêng và không chuyển tiếp là trường hợp khác với thiết bị nằm sau NAT cấp nhà mạng có ánh xạ công khai ổn định.

Nếu hai địa chỉ khớp nhau, hãy dừng ở đây: NAT không phải vấn đề của bạn và phần còn lại của danh sách này sẽ không giúp gì.

Ghi cả hai địa chỉ và kiểu bộ dịch vào ticket. Một dòng đó ngăn vòng câu hỏi tiếp theo về việc tại sao peer đã cấu hình không trả lời.

Bước 2: thống nhất ai sẽ khởi tạo

Câu hỏi thường gặp về Azure VPN Gateway nêu hỗ trợ NAT-T và thêm rằng thiết bị tại chỗ nên khởi tạo đường hầm IPsec khi nó nằm sau NAT. Điều đó khớp với cách dịch có trạng thái hoạt động, vì bộ dịch giữ một ánh xạ bởi thiết bị bên trong đã gửi gói đầu tiên. Nếu Azure được kỳ vọng khởi tạo và không có gì đến để tạo ánh xạ đó, đường hầm không bao giờ bắt đầu.

Cấu hình peer sao cho lỗi chỉ-phản-hồi trở nên rõ ràng, và kiểm tra xem thiết bị tự thử lại hay cần một tác nhân kích hoạt. Một số thiết bị chỉ dựng đường hầm khi xuất hiện lưu lượng thú vị, điều đó ổn cho đến khi lưu lượng thú vị là một phép dò sức khỏe không bao giờ đến.

Quan sát trao đổi IKE trên thiết bị trong lúc khởi tạo thủ công; sự im lặng ở đó là câu trả lời của định tuyến hoặc tường lửa, không phải của Azure.

Bước 3: đặt địa chỉ peer cho đúng

Azure cần một địa chỉ công khai có thể tiếp cận cho peer trong đối tượng cổng mạng cục bộ, thường là địa chỉ công khai của bộ dịch chứ không phải địa chỉ bên trong của thiết bị. Danh tính mà thiết bị dùng để xác thực là một trường riêng và có thể khác một cách hợp lệ với địa chỉ mà Azure quay số. Giữ hai thứ tách biệt, vì hoán đổi chúng tạo ra lỗi xác thực trông giống hệt vấn đề NAT.

Nếu địa chỉ công khai thay đổi, đối tượng đó phải thay đổi theo. Một tên phân giải đến địa chỉ cũ còn tệ hơn một địa chỉ tĩnh mà bạn phải cập nhật bằng tay.

Ghi cả ba giá trị: địa chỉ cục bộ của thiết bị, địa chỉ công khai đã dịch, và danh tính peer đã cấu hình.

Bước 4: chỉ mở những cổng mà NAT-T cần

NAT-T mang ESP bên trong UDP, và RFC 3948 mô tả cách đóng gói đó với cổng 4500 được dùng sau khi thương lượng ban đầu trên cổng 500. Tường lửa của bạn và bộ dịch đều phải cho phép trao đổi và lưu lượng trả về của nó. Cho phép một cổng TCP không liên quan không chứng minh được gì về đường đi này, và một quy tắc cho phép chiều ra nhưng không cho phép phản hồi vẫn sẽ thất bại.

Chuyển tiếp cổng vào tĩnh không tự động cần thiết khi peer khởi tạo và bộ dịch giữ trạng thái. Nó trở nên cần thiết khi ánh xạ không ổn định hoặc khi có gì đó trên đường đi hết hạn trạng thái một cách hung hăng.

Bắt gói một lần ở cả hai phía của bộ dịch; sự khác biệt về đóng gói hiện ra ngay.

Bước 5: tách truyền tải bên ngoài khỏi định tuyến bên trong

Một đường hầm được thiết lập mà không mang gì là vấn đề định tuyến, không phải vấn đề NAT-T. Các site vẫn cần bộ chọn lưu lượng tương thích, không gian địa chỉ khớp nhau, quy tắc truy cập và đường trở về cho các mạng ứng dụng. Không điều nào trong số đó được cung cấp bởi một trao đổi IKE thành công.

Nếu hai site dùng dải riêng chồng lấn, việc dịch bên trong đường hầm là một thiết kế riêng với quy tắc riêng. Đừng đánh số lại một subnet chỉ vì cổng bên ngoài tình cờ nằm sau một router gia đình.

Phân loại lỗi theo giai đoạn trước khi bạn thay đổi bất cứ điều gì, và giữ cách phân loại đó trong ticket để người tiếp theo bắt đầu từ nơi bạn dừng lại.