Trong bài đăng này, chúng tôi mô tả cách bạn có thể sử dụng Amazon Web Services (AWS) Cloud WAN với dịch vụ chèn để tập trung NAT Gateway riêng và PrivateLink của bạn để giải quyết hiệu quả và hiệu quả tình trạng cạn kiệt IPv4 riêng. Chúng tôi chứng minh cách bạn có thể tối đa hóa việc sử dụng không gian IP khả dụng trong khi giảm thiểu tác động về chi phí.

Không gian IPv4 riêng tư, được định nghĩa trong RFC 1918 và RFC 6598 , thoạt đầu có vẻ như là một nguồn địa chỉ vô tận và rộng lớn khi được sử dụng đúng cách với kế hoạch cẩn thận. Tuy nhiên, trong hầu hết các mạng doanh nghiệp, khách hàng thường gặp khó khăn trong việc phân bổ phạm vi phù hợp cho các dự án, môi trường mới và đôi khi là toàn bộ các vị trí khi tổ chức của họ phát triển. Điều này có thể là do một số lý do: khó khăn trong việc lập kế hoạch tăng trưởng trong nhiều năm và dự đoán quy mô, thay đổi trong hướng thiết kế dẫn đến việc sử dụng không hiệu quả, sáp nhập và mua lại và áp dụng các công nghệ mới như container tiêu thụ một lượng lớn không gian IP.

Điều này có thể dẫn đến việc khách hàng có không gian khả dụng hạn chế trong phạm vi IPv4 riêng tư của họ để phân bổ cho môi trường AWS khi họ bắt đầu hành trình đám mây hoặc cần mở rộng quy mô để đáp ứng nhu cầu kinh doanh. Để giải quyết tình huống này, AWS cung cấp một số giải pháp và khuyến nghị, chẳng hạn như: Amazon VPC Lattice , hỗ trợ rộng rãi cho IPv6 , PrivateLink và sử dụng Cổng NAT riêng tư phân tán , như được mô tả trong bài đăng, Cách giải quyết tình trạng cạn kiệt IP riêng tư bằng Giải pháp NAT riêng tư .

Một cách tiếp cận chiến lược khác là sử dụng AWS Cloud WAN để cung cấp giải pháp bền vững, có khả năng mở rộng và tiết kiệm chi phí.

Điều kiện tiên quyết và giả định

Bài đăng này giả định rằng bạn đã quen thuộc với các dịch vụ mạng AWS bao gồm NAT Gateways, AWS PrivateLink và AWS Cloud WAN, cùng với hiểu biết cơ bản về các khái niệm mạng doanh nghiệp. Chúng tôi sẽ không tập trung vào việc định nghĩa các dịch vụ và khái niệm này, nhưng chúng tôi sẽ phác thảo các khả năng của chúng và cách bạn có thể sử dụng chúng cho kiến ​​trúc được nêu bật.

Tổng quan về giải pháp

Hiện tại, khách hàng đang phải đối mặt với tình trạng thiếu địa chỉ IPv4 riêng tư và chưa chuyển sang Amazon VPC Lattice hoặc IPv6 thường triển khai Cổng NAT riêng tư trong VPC của họ.

Giải pháp được mô tả trong bài đăng này cho phép bạn loại bỏ nhu cầu NAT lưu lượng còn lại trong AWS và tối đa hóa việc sử dụng không gian IP khả dụng, cho phép bạn mở rộng cả số lượng và quy mô của VPC mà bạn có thể tạo.

Phương pháp này dựa trên việc chỉ định một phạm vi IPv4 riêng tư chỉ có thể định tuyến trong môi trường AWS của bạn và triển khai NAT và PrivateLink tập trung ở cấp độ này thay vì ở cấp độ VPC. Hình 1 cho thấy kiến ​​trúc khái niệm.

Hình 1: Kiến trúc khái niệm—Miền IP có thể định tuyến AWS

Trong ví dụ này, chúng tôi gán phạm vi Carrier-Grade NAT (CGN) 100.64.0.0/10 (RFC 6598) cho môi trường AWS và chia nó thành /12 CIDR để gán cho từng Vùng AWS. Phạm vi này được định tuyến qua các Vùng AWS nhưng được dịch bằng cách sử dụng các cổng NAT riêng của Vùng thành miền IP có thể định tuyến trên toàn công ty (10.0.0.0/8 trong ví dụ) khi nó rời khỏi AWS. Điều này cho phép bạn có phạm vi mở rộng mà bạn có thể sử dụng để triển khai VPC và khối lượng công việc và định tuyến tự do trong AWS mà không cần phải NAT lưu lượng để lại một VPC đến một VPC khác.

Phạm vi được chọn ở đây được sử dụng làm ví dụ, vì khách hàng thường chọn sử dụng nó đằng sau các thiết bị NAT và không định tuyến nó qua WAN của công ty. Nếu bạn đang định tuyến phạm vi này, thì bạn có thể chọn bất kỳ phạm vi riêng tư nào khác chỉ được triển khai đằng sau các thiết bị NAT và có thể được sử dụng lại ở nhiều vị trí, chẳng hạn như AWS, công ty và trung tâm dữ liệu của bên thứ ba.

Nếu bạn không có đủ không gian IP không định tuyến đủ lớn, thì bạn cũng có thể chọn một phạm vi nhỏ hơn mà bạn có thể sử dụng lại trên tất cả các Vùng AWS, vị trí tại chỗ và trung tâm dữ liệu của bên thứ ba. Trong trường hợp này, lưu lượng còn lại trong Vùng không được dịch. Tuy nhiên, tất cả lưu lượng rời khỏi Vùng, đến một Vùng AWS khác hoặc đến các vị trí tại chỗ, phải được dịch bởi các cổng NAT riêng của Vùng.

Trong bài đăng này, chúng tôi sẽ khám phá cách thực hiện điều này bằng cách áp dụng logic được nêu trong các điểm sau và thể hiện trong Hình 2 như các nguyên tắc thiết kế chính:

1. Miền IP có thể định tuyến AWS đến miền IP có thể định tuyến AWS: Đã định tuyến
2. Miền IP có thể định tuyến của AWS tới miền IP có thể định tuyến của toàn công ty: NAT
3. Miền IP có thể định tuyến trên toàn công ty đến miền IP có thể định tuyến của AWS: PrivateLink
4. Miền IP có thể định tuyến trên toàn công ty đến miền IP có thể định tuyến trên toàn công ty: Đã định tuyến

Hình 2: Nguyên tắc thiết kế

Kiến trúc giải pháp

Kiến trúc cấp cao trong Hình 3 cho thấy cấu hình logic của một Vùng, bao gồm các thành phần sau:

• Khối lượng công việc VPC sử dụng không gian IP có thể định tuyến AWS (100.64.0.0/10), trong đó khả năng sử dụng CIDR lớn cho phép khả năng mở rộng lớn hơn. Phạm vi này có thể định tuyến với AWS giúp loại bỏ nhu cầu về cổng NAT hoặc điểm cuối VPC trong khối lượng công việc VPC.
• Một VPC NAT outbound tập trung duy nhất để chuyển lưu lượng khi nó rời AWS đến tại chỗ. Việc sử dụng NAT tập trung làm giảm số lượng cổng NAT riêng cần thiết. VPC này cần một mạng con có thể định tuyến nhỏ (10.2.100.0/26 trong ví dụ), trong đó /28 có thể được chỉ định cho mỗi Vùng khả dụng (AZ) để chứa các cổng NAT.
• Một VPC tập trung duy nhất để triển khai các điểm cuối VPC cho lưu lượng truy cập đến các ứng dụng. Việc sử dụng VPC tập trung cho phép bạn tối đa hóa việc sử dụng không gian IP có thể định tuyến (10.1.0.0/20 trong ví dụ này) thay vì phải chia nó thành các mạng con nhỏ hơn được chỉ định cho các VPC khối lượng công việc cho mỗi AZ. Sử dụng không gian hiệu quả hơn cho phép bạn tối đa hóa số lượng điểm cuối VPC mà bạn có thể có.

Hình 3: Kiến trúc cấp cao

Xây dựng kết nối với AWS Cloud WAN

Để chứng minh cách thức định tuyến hoạt động, Hình 4 giới thiệu AWS Cloud WAN và AWS Direct Connect và trình bày chi tiết hơn về thiết kế VPC.

Chủ sở hữu Tài khoản mạng chịu trách nhiệm triển khai cả VPC NAT outbound tập trung và VPC inbound tập trung. Họ cũng sở hữu kết nối, chẳng hạn như AWS Cloud WAN và Direct Connect. Các mạng con có thể định tuyến, được hiển thị bằng màu xanh lam trong Hình 4, được chỉ định 10.2.100.0/26 cho NAT và 10.1.0.0/20 cho các điểm cuối VPC. Hai CIDR này cần được quảng cáo tới các mạng tại chỗ qua Direct Connect.

Hình 4: Lưu lượng giao thông trong một khu vực

Lưu lượng truy cập được khởi tạo từ khối lượng công việc trong VPC đến cơ sở tại chỗ

1. Lưu lượng truy cập bắt đầu từ khối lượng công việc trong VPC 1 được định tuyến đến mạng lõi AWS Cloud WAN thông qua tệp đính kèm.
2. AWS Cloud WAN sẽ được cấu hình để định tuyến toàn bộ lưu lượng truy cập đến mạng tại chỗ đến NAT VPC tập trung.
3. Cổng NAT dịch địa chỉ IP nguồn thành địa chỉ riêng của nó (10.2.100.1 trong ví dụ này) và định tuyến trở lại AWS Cloud WAN.
4. Sau đó, Cloud WAN sẽ chuyển tiếp lưu lượng đến các mạng hứa hẹn thông qua AWS Direct Connect.

Lưu lượng truy cập trả về theo cùng một đường dẫn ngược lại, các bước (5) đến (8). Các gói trả về được định tuyến đến địa chỉ IP NAT (10.2.100.1). Cổng NAT dịch địa chỉ IP đích từ địa chỉ của nó sang địa chỉ của khối lượng công việc đã khởi tạo yêu cầu. Sau đó, nó gửi gói đến AWS Cloud WAN, chuyển tiếp gói trở lại VPC và khối lượng công việc.

Lưu lượng truy cập được khởi tạo từ cơ sở tại chỗ đến khối lượng công việc trong VPC

1. Lưu lượng truy cập bắt đầu từ mạng tại chỗ được định tuyến qua AWS Cloud WAN thông qua Direct Connect.
2. AWS Cloud WAN chuyển tiếp lưu lượng trực tiếp đến điểm cuối VPC (10.1.0.1 trong ví dụ này) được triển khai trong VPC tập trung, vì không cần bất kỳ quá trình chuyển đổi nào.
3. Sử dụng PrivateLink, điểm cuối VPC gửi gói tin đến
4. Sau đó, NLB có thể gửi nó đến một trong các trường hợp trong nhóm mục tiêu của nó.

Lưu lượng truy cập trả về theo cùng một đường dẫn ngược lại, các bước (5) đến (8). Phiên bản gửi gói trả về đến NLB, chuyển tiếp gói này qua cùng điểm cuối VPC. Từ đó, gói được gửi đến AWS Cloud WAN, sau đó định tuyến gói này trở lại mạng tại chỗ thông qua Direct Connect.

Định tuyến với dịch vụ chèn AWS Cloud WAN

Bây giờ chúng ta đã mô tả kiến ​​trúc và các mẫu luồng, hãy cùng xem xét việc triển khai giải pháp. Chúng tôi sẽ trình bày cách bạn có thể sử dụng AWS Cloud WAN service inserted để chèn các cổng NAT tập trung vào đường dẫn lưu lượng đi và sử dụng chia sẻ tuyến đường giữa các phân đoạn cho lưu lượng đến.

Hình 5 hiển thị các phân đoạn AWS Cloud WAN và cung cấp chế độ xem các bảng định tuyến cho cả phân đoạn và mạng con VPC. Hình này cũng hiển thị cách nhiều tài khoản có thể sử dụng VPC tập trung để triển khai các điểm cuối VPC cho các ứng dụng tương ứng của họ.

Hình 5: Định tuyến với dịch vụ chèn AWS Cloud WAN

Cấu hình các phân đoạn AWS Cloud WAN và tệp đính kèm VPC

Để triển khai kiến ​​trúc này, bạn cần cấu hình bốn phân đoạn trên mạng lõi AWS Cloud WAN và các tệp đính kèm liên quan:

• Phân đoạn sản xuất : Được sử dụng để liên kết các tệp đính kèm VPC khối lượng công việc.
• Phân đoạn lai : Được sử dụng để liên kết kết nối với mạng tại chỗ thông qua Direct Connect.
• Phân đoạn đến : Được sử dụng để liên kết VPC đến tập trung. Đây là VPC lưu trữ Điểm cuối PrivateLink.
• Nhóm chức năng mạng đi (NFG): Đây là phân đoạn được quản lý do dịch vụ chèn AWS Cloud WAN tạo ra và được sử dụng để đính kèm VPC NAT đi tập trung và chèn cổng NAT vào đường dẫn lưu lượng đi.

Việc triển khai mạng lõi AWS Cloud WAN và cấu hình các phân đoạn và tệp đính kèm nằm ngoài phạm vi của bài đăng này nhưng được trình bày chi tiết trong Hướng dẫn sử dụng AWS Cloud WAN .

Cấu hình định tuyến cho lưu lượng truy cập đi

Lưu lượng truy cập ra được khởi tạo từ khối lượng công việc trong VPC hướng đến các tài nguyên tại chỗ cần được dịch (NAT) trước khi rời khỏi AWS. Sử dụng chèn dịch vụ, bạn xác định ý định của mình trong chính sách và AWS Cloud WAN đảm bảo rằng lưu lượng truy cập ra được định tuyến qua VPC NAT ra tập trung và các cổng NAT bên trong nó.

Tùy thuộc vào ứng dụng của bạn, bạn cũng có thể cần cho phép lưu lượng truy cập được khởi tạo từ khối lượng công việc bên trong VPC đến điểm cuối PrivateLink được triển khai trong VPC tập trung vào. Điểm cuối nằm trong miền IP có thể định tuyến trên toàn công ty (10.1.0.0/20 trong ví dụ này), trong khi khối lượng công việc nằm trong miền IP có thể định tuyến của AWS (phạm vi 100.64.0.0/10). Do đó, lưu lượng truy cập này cũng phải được dịch (NAT) theo các nguyên tắc thiết kế đã mô tả trước đó.

Lưu lượng truy cập còn lại trong phân khúc Sản xuất không cần phải được NAT.

Mục đích chính sách chèn dịch vụ cần thiết như sau:

Mục đích chính sách chèn dịch vụ
Phân khúc nguồn	Phân khúc đích	Hoạt động
Sản xuất	lai	Gửi qua NFG ra
Sản xuất	Đến	Gửi qua NFG ra

Bảng 1: Ý định chính sách chèn dịch vụ

Để thiết lập chèn dịch vụ cho phân đoạn Sản xuất, hãy làm theo các bước được mô tả trong phần Hành động thêm phân đoạn của Hướng dẫn sử dụng AWS Cloud WAN .

Khi lưu lượng truy cập đến cổng NAT, nó sẽ dịch địa chỉ IP nguồn của gói tin thành địa chỉ của riêng nó (10.2.100.1 trong ví dụ này). Để đảm bảo lưu lượng truy cập trả về có thể đến cổng NAT, cần có một tuyến tĩnh trong cả phân đoạn Hybrid và Inbound. Điều này là do, mặc dù tính năng chèn dịch vụ đảm bảo truyền tuyến động giữa các phân đoạn nguồn và đích, nhưng nó không truyền các tuyến của VPC được đính kèm trực tiếp vào NFG. Trong Hình 5, tuyến tĩnh được hiển thị màu đỏ trong cả bảng tuyến phân đoạn Hybrid và Inbound. Đây là tuyến tĩnh duy nhất cần thiết trong giải pháp được triển khai khi triển khai ban đầu và trỏ đến toàn bộ CIDR của VPC NAT outbound tập trung.

Cấu hình định tuyến cho lưu lượng truy cập đến

Lưu lượng truy cập từ các mạng on-promises đi vào AWS cần được chuyển hướng đến các điểm cuối PrivateLink được triển khai trong VPC tập trung vào. Do đó, các mạng con được sử dụng trong VPC này thuộc về miền IP có thể định tuyến trên toàn công ty và có thể được định tuyến trực tiếp mà không cần cổng NAT.

Để định tuyến trực tiếp giữa các phân đoạn, bạn cần sử dụng chia sẻ phân đoạn thay vì chèn dịch vụ. Sau này, như tên gọi của nó, được sử dụng để chèn một dịch vụ vào đường dẫn lưu lượng, điều này không cần thiết ở đây.

Cấu hình chia sẻ phân đoạn giữa các phân đoạn Inbound và Hybrid cho phép chúng chia sẻ các tuyến đường một cách động. Điều này dẫn đến việc phân đoạn Hybrid học các tuyến đường cho VPC inbound tập trung và phân đoạn inbound học các tuyến đường cho các mạng tại chỗ.

Điều này thiết lập một đường dẫn trực tiếp giữa các mạng tại chỗ và VPC tập trung đến, đây là kết quả mong muốn. Nếu bạn cần kiểm tra lưu lượng từ các mạng tại chỗ, thì bạn có thể tạo một VPC kiểm tra riêng và sử dụng chèn dịch vụ để định tuyến lưu lượng đến đó. Điều này được mô tả trong bài đăng, Đơn giản hóa kiểm tra bảo mật toàn cầu với Chèn dịch vụ AWS Cloud WAN .

Kiến trúc đa vùng

Trong khi bài đăng này tập trung vào triển khai một Vùng duy nhất, các khái niệm được trình bày có thể được mở rộng sang triển khai nhiều Vùng. Tuy nhiên, việc khám phá chi tiết về kiến ​​trúc nhiều Vùng nằm ngoài phạm vi thảo luận này.

Những điều cần biết

• Tên miền IP định tuyến AWS có thể được sử dụng lại bên ngoài AWS nhưng không nên quảng cáo trên mạng công ty.
• Nếu miền IP định tuyến AWS được sử dụng bên ngoài AWS, thì nó cần phải nằm sau cả NAT đi và đến.
• Hãy cân nhắc giải quyết DNS của bạn và đảm bảo rằng các tài nguyên bên ngoài AWS không phân giải tên miền thành địa chỉ IP trong miền IP định tuyến của AWS.
• NFG không truyền động các tuyến từ NAT VPC được gắn vào nó. Bạn phải cấu hình một tuyến tĩnh trong các phân đoạn khác để trỏ lại NAT VPC để cho phép lưu lượng truy cập trả về.
• Phân đoạn Hybrid học động các tuyến miền IP có thể định tuyến của AWS từ phân đoạn Production. Đảm bảo rằng các tuyến này không được quảng cáo cho các mạng tại chỗ.
• Bảng định tuyến trong bài đăng này chỉ hiển thị các tuyến có liên quan. Các tuyến khác có thể được học động nhưng không ảnh hưởng đến định tuyến.

Phần kết luận

Trong bài đăng này, chúng tôi đã thảo luận về cách bạn có thể sử dụng AWS Cloud WAN với dịch vụ chèn để giải quyết thách thức về tình trạng cạn kiệt IPv4 riêng tư trên toàn tổ chức của bạn. Kiến trúc được mô tả ở đây cho phép bạn tạo một nền tảng có thể mở rộng bằng cách sử dụng các dải IP chỉ có thể định tuyến trong môi trường AWS. Đồng thời, bạn có thể tối ưu hóa chi phí bằng cách tập trung các tài nguyên NAT của mình cho toàn bộ Vùng thay vì triển khai chúng trong các VPC khối lượng công việc của bạn. Hơn nữa, việc sử dụng VPC tập trung vào cùng với AWS PrivateLink cho phép bạn tối đa hóa việc sử dụng dải IPv4 riêng tư có thể định tuyến được dành cho bạn.