Anypoint VPN hay NAT trên Transit Gateway: dịch ở đâu
Anypoint VPN không tự dịch địa chỉ. Hãy chọn giữa thiết kế PAT trên tường lửa, bản đồ tiền tố AWS hay một kết nối khác trước khi hứa về NAT.
Một yêu cầu NAT không phải là yêu cầu cho đến khi nó nêu tên các địa chỉ thay đổi và thành phần được phép thay đổi chúng. Trong kết nối MuleSoft, quyết định đó có ba đầu vào: liệu backend cần dịch cổng nhiều-sang-một hay một bí danh tiền tố một-một, liệu kết nối AWS mà bạn thực sự sở hữu có thể thực hiện ánh xạ đó, và liệu toàn bộ đường đi có nằm trong một tổ hợp mà nhà cung cấp hỗ trợ hay không. Nếu sai, bạn sẽ xây một phòng thí nghiệm chạy được nhưng trượt khâu đánh giá.
Điểm cố định duy nhất là bản thân Anypoint VPN không phải thiết bị dịch. Tài liệu CloudHub 2.0 liệt kê NAT là không được hỗ trợ ở đó, nên bất kỳ thiết kế nào giả định đường hầm sẽ che giấu địa chỉ của worker đều đã hỏng.
Xác định việc dịch phải làm gì
Nếu nhiều worker ứng dụng phải xuất hiện trước backend như một địa chỉ duy nhất, yêu cầu là dịch nguồn dùng chung, thường là SNAT hoặc PAT có trạng thái trên tường lửa do bạn kiểm soát. Phần tử đó phải nằm trên đường đi được phê duyệt, giữ trạng thái trong suốt vòng đời của luồng và thấy lưu lượng trả về cho mọi kết nối mà nó đã viết lại. Mất trạng thái giữa phiên không làm suy giảm kết nối; nó kết thúc kết nối. Một cặp tường lửa từ chối chia sẻ trạng thái dịch sẽ bỏ mọi phiên rơi vào thành viên dự phòng sau khi chuyển đổi. Hãy chọn kích thước phần tử đó cho luồng đồng thời, không phải cho thông lượng.
Nếu ngược lại hai mạng chồng lấn và mỗi máy chủ cần một bí danh riêng, yêu cầu là một kế hoạch địa chỉ một-một với tiền tố được ánh xạ rõ ràng, tuyến khớp và phân giải tên nhất quán với ánh xạ. Che giấu mọi worker sau một địa chỉ không phải phiên bản rẻ hơn của điều đó, và việc hoán đổi cái này cho cái kia trong đánh giá thiết kế là cách các dự án mất một quý.
Ghi lại quyết định bằng thuật ngữ cụ thể trước khi chọn sản phẩm: nguồn gốc, đích gốc, giá trị đã dịch, hướng khởi tạo, chủ sở hữu bộ dịch và tuyến trả lời dự kiến. Thêm cả danh tính mà nhật ký backend sẽ giữ lại, vì một thiết kế che giấu mọi nguồn cũng phá hủy việc kiểm toán theo từng khách hàng.
Kiểm tra xem AWS có thể ánh xạ thay bạn không
AWS hiện đã ghi nhận NAT một-một được quản lý trên các kết nối Transit Gateway và Cloud WAN, công bố vào cuối tháng Mười năm 2026, nên khẳng định chung cũ rằng cổng trung chuyển không bao giờ dịch được đã lỗi thời. Tài liệu Transit Gateway NAT mô tả ánh xạ tiền tố IPv4 không trạng thái: tiền tố gốc và tiền tố đã dịch giữ nguyên độ dài, còn bit máy chủ và cổng vận chuyển vẫn tồn tại qua phép dịch. Hãy đọc hướng vào và hướng ra như hai quyết định thiết kế riêng biệt, vì chúng được cấu hình riêng và một hướng có thể sẵn sàng trong khi hướng kia thì chưa. Không có gì trong mô tả đó ngụ ý trạng thái theo từng luồng, nên đừng mong ánh xạ tự theo dõi kết nối thay bạn.
Điều đó có nghĩa là 10.80.0.0/16 được ánh xạ tới 172.28.0.0/16 biến 10.80.10.23 thành 172.28.10.23. Nó không thu gọn /16 thành một địa chỉ và không thay thế yêu cầu PAT. Nó cũng bao gồm một số loại kết nối, trong đó có VPC và Site-to-Site VPN, nhưng không gồm kết nối Client VPN, và cấu hình nằm ở chủ sở hữu cổng trung chuyển chứ không ở phía Anypoint.
Hãy coi tính năng này như một điểm kiểm soát khả dĩ nữa, không phải bằng chứng rằng triển khai của bạn dùng được nó. CloudHub 2.0 ghi nhận các kết nối không gian riêng tới một cổng trung chuyển trong chính tài khoản AWS của khách hàng, kèm điều kiện theo khu vực và điều kiện quyền, nên hãy xác nhận loại kết nối thực, chủ sở hữu và lập trường hỗ trợ của nhà cung cấp trước khi thiết kế quanh tùy chọn mới.
Giữ đường đi trong ranh giới được hỗ trợ
Với bộ dịch trên tường lửa, hãy dùng mô hình VPN, dịch và định tuyến được hỗ trợ của sản phẩm đó thay vì dán một quy tắc NAT chung vào đường hầm đang chạy. Câu trả lời của backend phải quay lại qua đúng phần tử dịch đó, và một đường hầm ra lành mạnh không nói gì về tuyến quay lại ấy.
Với tuyến qua cổng trung chuyển, hãy kiểm kê kết nối không gian riêng, các bảng tuyến liên quan, kết nối tại chỗ và những phần khách hàng thực sự có thể cấu hình. Đây là một kiến trúc kết nối khác, không phải ô chọn NAT bắt vít vào kết nối Anypoint VPN sẵn có, và ranh giới hỗ trợ cũng dịch chuyển theo.
So sánh ba lựa chọn trong một bảng
Hầu hết các nhóm chỉ cần trả lời hai câu hỏi: nhiều-sang-một hay một-một, và ai sở hữu kết nối. Bảng dưới đây biến các câu trả lời đó thành lựa chọn khởi đầu.
| Requirement | Starting option | What breaks it |
|---|---|---|
| Many workers, one backend address | Stateful PAT on your firewall | Asymmetric return path, expired state |
| Overlapping /16s, one-to-one | AWS prefix mapping on a supported attachment | Client VPN attachment, no explicit config |
| Per-client audit must survive | Keep original sources, translate downstream | Any many-to-one hiding of sources |
Hãy đọc cột thứ ba như câu hỏi đánh giá, không phải ý nghĩ về sau. Một bản đồ tiền tố được cho phép trên giấy nhưng lại cấu hình trên kết nối bạn không sở hữu vẫn là dự án bị chặn, và một quy tắc PAT cho lưu lượng đi qua nhưng phá vỡ ghi nhật ký theo khách hàng sẽ trượt lần kiểm toán tiếp theo.
Kiểm chứng ánh xạ trước khi hứa
Cho một thao tác ứng dụng mới đi qua đường dẫn và xác nhận cả câu trả lời, không chỉ yêu cầu. Hỏi chủ sở hữu backend xem nhật ký của họ ghi lại địa chỉ nguồn nào, kiểm tra rằng việc xử lý họ địa chỉ khớp với kế hoạch ở cả hai hướng, và xác minh rằng một đường lẽ ra phải bị từ chối vẫn bị từ chối. Một kết nối cũ không chứng minh được gì về ánh xạ bạn vừa thay đổi.
Giữ xác thực của backend độc lập với việc địa chỉ đã dịch nào thỏa mãn danh sách cho phép của nó, vì ánh xạ là hệ thống ống của mạng chứ không phải quyết định kiểm soát truy cập. Ngay khi việc đặt lại mật khẩu phụ thuộc vào một tiền tố NAT, mọi thay đổi dải địa chỉ trong tương lai đều trở thành sự cố.
Trước khi phê duyệt, hãy viết ra ba câu trả lời: loại dịch, chủ sở hữu bộ dịch, và kết nối hoặc đường sản phẩm được hỗ trợ mang nó. Nếu bất kỳ điều nào còn là phỏng đoán, thiết kế chưa sẵn sàng cho cửa sổ thay đổi.