NAT của Azure VPN không khắc phục được địa chỉ VNet trùng lặp
Hai VNet có cùng dải riêng sẽ không kết nối chỉ vì có NAT. Hãy kiểm tra loại kết nối trước, sau đó đánh số lại hoặc sở hữu một bí danh dịch.
Cả hai VNet đều dùng 10.40.1.0/24, các đường hầm đã lên nhưng không có gì hoạt động. Thêm một cổng VPN thứ hai không thay đổi điều đó, và một chỉ số tuyến thấp hơn cũng vậy, vì vấn đề không phải là chọn đường. Hai khối lượng công việc cùng trả lời một địa chỉ riêng để lại mỗi gói tin với đích đến mơ hồ và đường về không thể kiểm chứng. Trước khi lập kế hoạch cho bất kỳ bản dịch nào, hãy tìm hiểu loại kết nối bạn thực sự đã tạo, vì lựa chọn duy nhất đó quyết định liệu tính năng NAT của Azure có khả dụng hay không.
Triệu chứng này thực sự đang nói với bạn điều gì
Khi một máy chủ trong VNet A gửi tới 10.40.1.10, bảng định tuyến chỉ có thể trỏ nó đến một nơi nào đó. Nếu VNet B cũng chứa 10.40.1.10, địa chỉ đó không phải là đích mà đường đi có thể phân biệt; đó là một địa chỉ có hai chủ sở hữu.
Cổng thứ hai mà mọi người thường triển khai không giúp ích gì. Nó cho bạn một đường hầm khác, không phải một địa chỉ khác, và dải trùng lặp di chuyển nguyên vẹn bên trong đường hầm. Nó cũng nhân đôi cấu hình mà bạn phải giữ nhất quán. Điều nó không thể làm là khiến một địa chỉ mang nghĩa hai máy chủ.
Thay đổi địa chỉ công cộng của các peer VPN cũng không làm được gì. Những địa chỉ đó xác định các đầu mút của đường hầm, trong khi xung đột nằm ở dải riêng được mang bên trong.
Loại kết nối quyết định NAT có khả dụng hay không
Azure VPN Gateway thực sự có năng lực NAT, và nó được ghi nhận cho các kết nối IPsec giữa các site dựa trên tuyến trên những SKU cổng cụ thể. Cùng tài liệu đó loại trừ kết nối VNet-to-VNet và point-to-site, nên tính năng này không phải là một ô kiểm xuất hiện trên mọi quan hệ cổng.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
VNet-to-VNet gốc cũng yêu cầu dải VNet và dải mạng cục bộ không trùng nhau ngay từ đầu, điều này phù hợp với việc loại trừ. Peer VNet cũng không phải là cách xử lý trùng lặp vì cùng lý do.
Có một lựa chọn thay thế được hỗ trợ mà mọi người nhầm với loại gốc: mô hình hóa VNet kia như mạng cục bộ và kết nối nó như một liên kết site-to-site. Đó là tài nguyên khác và thiết kế khác, nên hãy coi một kết nối đã đổi tên là thay đổi cần xác thực, không phải chỉ là đổi tên.
Đánh số lại, hoặc dịch bằng một thứ sở hữu bí danh
Nếu cả hai VNet là của bạn, hãy so sánh việc đánh số lại theo kế hoạch với chi phí dịch liên tục. Đánh số lại chạm vào cấu hình ứng dụng, bản ghi DNS, quy tắc bảo mật và mọi kết nối hiện có, nhưng để lại một mạng đọc bình thường sau đó. Hãy làm từng subnet một, với thay đổi DNS sau cùng. Một dải đánh số lại một nửa còn tệ hơn cả hai lựa chọn, vì khi đó cả hai tiền tố đều trông có thẩm quyền với người đọc bảng tiếp theo.
Ở nơi việc đánh số lại không thực tế, hãy dùng một thiết kế đã dịch với chủ sở hữu thực sự cho bí danh. Người gọi trong VNet A có thể tới 10.40.1.10 của VNet B với tên 10.140.1.10, nhưng bí danh đó cần một thiết bị dịch, một tuyến đến nó và hành vi khớp cho phản hồi. Một địa chỉ chỉ được thêm vào DNS không phải là bản dịch.
Ghi lại cả hai dải theo cả hai chiều: người gọi quay số gì, đích thấy gì là nguồn, và bên nào được phép khởi tạo. Các quy tắc NAT của chính Azure bao gồm bản dịch ngược cho các ánh xạ SNAT của chúng, nên bạn không viết tay một quy tắc DNAT khớp, nhưng sự tiện lợi đó dừng lại ở các loại kết nối mà tính năng hỗ trợ.
Điều sẽ không hiệu quả
Một tuyến do người dùng xác định hoặc chỉ số tuyến không thể tạo ra sự phân biệt địa chỉ còn thiếu. Cả hai đều tác động lên một đích vẫn còn mơ hồ, và gói tin đến bước nhảy tiếp theo mà bảng ưu tiên.
Thêm dải trùng lặp vào bảng tuyến như một tiền tố cụ thể hơn chỉ dịch chuyển sự mơ hồ một bước. Nó cũng thường phá vỡ chiều ngược lại, nơi phản hồi giờ có hai nguồn khả dĩ.
Chấp nhận thiết kế với lưu lượng theo cả hai chiều
Chứng minh thiết kế bằng một thao tác được phép mới từ mỗi phía, không phải bằng trạng thái đường hầm. Một đường hầm IPsec đã kết nối cho biết các peer đồng ý về mật mã; nó không nói gì về việc các đích đã trở nên phân biệt được hay chưa.
Sau đó chạy các đường bị từ chối: một địa chỉ phải tiếp tục không thể tới và một dịch vụ mà chính sách phải chặn. Nếu cả hai vẫn thành công, bản dịch rộng hơn thiết kế dự định.
Kết thúc bằng những dữ kiện giải thích cấu hình về sau: dải gốc, dải được trình bày, thiết bị dịch và chiều mà mỗi bên được phép khởi tạo. Nếu thiếu bất kỳ điều nào, kỹ sư tiếp theo sẽ thừa hưởng một mạng nơi hai máy chủ dùng chung một tên và không ai nhớ vì sao một trong hai lại trả lời.