Cổng NAT của AWS dùng IP nguồn nào để đi tới VPN?

Bạn mở bảng điều khiển VPC vì một đối tác hỏi dải nguồn nào sẽ đến qua VPN site-to-site. Trang cổng NAT hiển thị một cổng công khai có gắn Elastic IP, và điều cám dỗ là gửi địa chỉ đó rồi đi tiếp. Đó là câu trả lời đúng cho tuyến internet và câu trả lời sai cho tuyến VPN, và khác biệt nằm ở việc bảng tuyến trỏ tới cổng nào. Hãy đi hết tuyến trước khi viết danh sách cho phép.

Bắt đầu ở trang cổng NAT, không phải ở danh sách cho phép

Trang cổng NAT cho bạn biết subnet, loại và Elastic IP, và ba trường đó đủ để bắt đầu. Điều nó không nói là tuyến mà lưu lượng đi sau đó. Điều đó đến từ các bảng tuyến gắn với subnet của cổng NAT.

Đọc loại trước, vì công khai hay riêng tư quyết định liệu một cổng internet có xuất hiện về sau trong chuỗi hay không. Sau đó đọc subnet, vì tuyến thứ hai nằm ở đó.

Theo dõi hai lần chuyển đổi

Cả cổng NAT công khai và riêng tư đều chuyển nguồn IPv4 riêng của khối lượng công việc thành địa chỉ IPv4 riêng của chính cổng NAT. Lần chuyển đổi đầu tiên xảy ra bất kể loại. Lần chuyển đổi thứ hai là thứ người ta quên: cổng NAT công khai giao lưu lượng cho cổng internet, cổng này ánh xạ địa chỉ tới Elastic IP đã gắn.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

Trên tuyến riêng không có cổng internet trong chuỗi. Khi lưu lượng đi ra qua cổng trung chuyển hoặc cổng riêng ảo, hướng dẫn về cổng NAT ghi nhận địa chỉ riêng của cổng NAT là nguồn mà phía xa nhận được. Đó là địa chỉ mà đối tác nên cho phép, không phải Elastic IP.

Tuyến VPN thường hiển thị địa chỉ riêng

Với khối lượng công việc trong 10.20.1.0/24 đi tới tiền tố của đối tác, bảng tuyến của subnet khối lượng công việc trỏ tới cổng NAT, và bảng tuyến của subnet cổng NAT trỏ tới tuyến của cổng riêng. Cả hai bước nhảy đều quan trọng, và chỉ bước thứ hai quyết định đối tác thấy gì. Nếu subnet NAT không có tuyến nào tới tuyến VPN, gói tin không bao giờ tới, và đó là lỗi khác với địa chỉ nguồn sai.

Hãy xác minh tuyến thứ hai đó trước khi nói về địa chỉ. Một tuyến thiếu và một nguồn bị báo sai trông giống hệt nhau với đối tác chỉ đơn giản là không thấy lưu lượng.

Khi lần chuyển đổi thứ hai thay đổi câu trả lời

AWS cũng cung cấp ánh xạ NAT một-một rõ ràng và khớp trên một tệp đính kèm cổng trung chuyển. Ánh xạ đó có thể chuyển đổi nguồn một lần nữa trước khi dịch vụ xa nhìn thấy, và đây không phải hành vi mặc định chỉ định tuyến. Vì nó phải được cấu hình có chủ đích, hãy coi nó là ngoại lệ thiết kế chứ không phải thứ bạn thừa hưởng do tình cờ. Nếu không ai trong nhóm nhớ đã bật nó, hãy cho rằng nó không tồn tại cho tới khi bạn đọc tệp đính kèm.

Nếu thiết kế của bạn dùng nó, danh sách cho phép phải mô tả ánh xạ cuối cùng chứ không phải địa chỉ của cổng NAT. Cùng sự thận trọng đó áp dụng cho các tuyến khả dụng: khi nhiều địa chỉ cổng tham gia, tập nguồn dự kiến là hợp chứ không phải một địa chỉ đại diện. Hãy ghi lại mỗi địa chỉ thuộc lần chuyển đổi nào, vì một danh sách không có nguồn gốc thì không thể kiểm toán về sau.

Không thể cấp dịch vụ internet cho một cổng NAT riêng bằng cách trỏ nó tới cổng internet; AWS ghi nhận rằng lưu lượng như vậy bị bỏ. Hãy chọn loại dựa trên toàn bộ tuyến, không dựa trên từ VPN trong yêu cầu.

Hãy viết hợp đồng mà đối tác của bạn có thể hành động theo

Hợp đồng dùng được có bốn phần: hướng mà các luồng được khởi tạo, danh tính đã chuyển đổi mà đối tác sẽ thấy, tuyến quay lại cho danh tính đó và phạm vi bảo vệ áp dụng. Các luồng của cổng NAT được khởi tạo từ phía nguồn được hỗ trợ, nên đây không phải dịch vụ chuyển tiếp cổng vào để lộ một khối lượng công việc riêng. Nói to điều đó sớm sẽ ngăn một buổi rà soát thiết kế mà mỗi bên đều cho rằng bên kia khởi tạo.

Việc chuyển đổi mua sự dễ chịu từ chồng lấn địa chỉ và một chính sách nguồn có thể dự đoán được, và nó khiến bạn mất danh tính riêng của khối lượng công việc trong nhật ký của đối tác. Nếu kiểm toán cần quy trách nhiệm theo từng khối lượng công việc, hãy giữ danh tính đó ở lớp ứng dụng thay vì cố khôi phục nó từ một địa chỉ nguồn đã chuyển đổi.

Sau đó kiểm tra lại cả hai bảng tuyến sau mọi thay đổi, vì một tệp đính kèm mới hoặc một subnet được liên kết lại sẽ lặng lẽ viết lại câu trả lời.