AWS Site-to-Site VPN đến NAT Gateway: VGW so với Transit Gateway

Lần đầu ai cũng vẽ cùng một sơ đồ: VPN vào VPC, NAT gateway ra internet, xong. Nhưng AWS không hỗ trợ đường đó khi VPN kết thúc trên virtual private gateway, và lỗi âm thầm đến mức các nhóm phải dựng lại nó nhiều hơn một lần. Thiết kế chạy được cần một transit gateway, điều này thay đổi gateway và bảng tuyến ở cả hai phía. Hãy so sánh hai hình dạng trước khi vẽ bất cứ thứ gì.

Topology trông hiển nhiên và không được hỗ trợ

Tài liệu NAT gateway của AWS vẽ một đường khiến bất kỳ ai chỉ từng làm thiết kế một VPC phải bất ngờ: lưu lượng từ kết nối Site-to-Site VPN không thể được định tuyến tới NAT gateway qua virtual private gateway. Loại gateway mà VPN kết thúc quyết định liệu có tồn tại đường dịch địa chỉ hay không. Lỗi tồn tại vì trạng thái tunnel là UP và một instance EC2 trong cùng subnet vẫn ra internet bình thường. Cả hai quan sát đều không kiểm tra hướng bị hỏng.

Trên thực tế gói tin đến với địa chỉ nguồn từ mạng nội bộ và không tìm được hop kế tiếp được hỗ trợ nào để dịch nó. Tùy theo bảng, gói bị bỏ tại biên ra, và vì tunnel vẫn UP trong khi instance trong cùng subnet vẫn ra internet, sự cố được báo cáo như một vấn đề firewall tại chỗ.

Virtual private gateway so với transit gateway

Một virtual private gateway thuộc về một VPC duy nhất. Nó kết thúc VPN, cài tuyến vào bảng tuyến của VPC đó và dừng ở đó. Nó không có mô hình attachment nên không thể chuyển lưu lượng sang VPC khác hay sang một phân đoạn ra dùng chung. Phạm vi một VPC đó chính là toàn bộ giới hạn, và không tuyến nào bạn thêm trong VPC thay đổi được điều đó.

Transit gateway là một hub theo vùng, nơi VPN, từng spoke VPC và một VPC dịch vụ dùng chung đều xuất hiện như các attachment. Nó có bảng tuyến riêng, chọn attachment nào nhận một prefix nhất định.

Chính hub đó làm cho lối ra tập trung khả thi: VPN hạ cánh như một attachment, VPC ra như một attachment khác, và bảng tuyến của transit gateway gửi các prefix hướng internet từ cái thứ nhất sang cái thứ hai. Với virtual private gateway không có attachment thứ hai để gửi gì tới, vì thế không thể vá thiết kế về sau.

Đường ra được hỗ trợ, từng hop một

Thiết kế tham chiếu có năm hop và mỗi mũi tên là một quyết định định tuyến bạn phải cấu hình. Lưu lượng rời mạng nội bộ vào attachment Site-to-Site VPN, bảng của transit gateway chuyển tiếp nó tới attachment của VPC ra, nơi bảng subnet gửi nó tới một NAT gateway công khai. NAT gateway dịch nguồn và internet gateway mang gói ra ngoài.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Hai chi tiết quyết định các hop cuối có chạy hay không. NAT gateway phải công khai, có elastic IP và tuyến tới internet gateway, vì NAT gateway riêng tư dịch giữa các mạng và không bao giờ trở thành lối ra internet.

Lập kế hoạch một NAT gateway cho mỗi Availability Zone bạn định phục vụ, với mỗi bảng subnet trỏ tới cái cục bộ. Giữ bảng của transit gateway và các bảng của VPC như những đối tượng riêng trong ghi chú, vì một cái chọn attachment còn cái kia chọn tài nguyên bên trong VPC. Một tuyến mặc định chỉ ở một trong hai để nửa đường không được định nghĩa và tạo ra những sự cố cục bộ khó quy nguyên nhất.

Các thiết kế này thất bại ngay trên đường về

NAT gateway lưu trạng thái cho các luồng nó đã thấy, nên các phản hồi cho một kết nối đi ra quay về mà không cần quy tắc vào mới. Thuộc tính đó không công bố một dịch vụ nội bộ ra internet, và coi như nó làm được điều đó khiến một nhóm mất một ngày gỡ lỗi một kết nối lẽ ra không bao giờ hình thành. Với lưu lượng do client khởi tạo, bốn tuyến phải khớp nhau: chính sách nội bộ, bảng transit gateway, bảng subnet ra và bảng subnet NAT. Thiếu cái cuối thì yêu cầu rời khỏi tòa nhà trong khi phản hồi chết bên trong AWS.

Hãy kiểm chứng bằng một client thật sau VPN và xem nó trình ra địa chỉ nguồn công khai nào. Nếu đó là elastic IP của NAT gateway thì đang có dịch địa chỉ; nếu là thứ khác thì bạn đang đo một lối ra khác.

Phiên bản bất đối xứng của sự cố này đáng được nhận ra sớm. Khi bảng subnet NAT của một Availability Zone có tuyến quay về prefix của client còn zone kia thì không, các kết nối mới thành công hay thất bại tùy theo zone nơi luồng rơi vào, và mẫu đó bị đọc sai thành internet chập chờn. Hãy so sánh bảng subnet của mọi zone bạn phục vụ thay vì sửa zone nơi ticket được mở, vì tuyến thiếu chính là toàn bộ lỗi và phía bên kia không cần thay đổi gì.

Khi nào một proxy tường minh là thiết kế tốt hơn

HTTP proxy trên một instance trong VPC ra là phương án chính đáng và thường rẻ hơn. Client được cấu hình để dùng nó, proxy tự mở kết nối ra ngoài, và đường về trở thành vấn đề của nó thay vì một câu đố định tuyến đối xứng. Với vài ứng dụng, điều này loại bỏ phần lớn công việc của transit gateway. Nó cũng cho nhật ký theo từng người dùng mà NAT gateway không thể tạo ra.

Tuy nhiên nó không trong suốt. Bất cứ thứ gì bỏ qua cài đặt proxy, và mọi giao thức không phải HTTP, sẽ không đi theo đường đó.

Lựa chọn phụ thuộc vào việc ứng dụng của bạn thực sự nói gì và bạn cần bao nhiêu danh tính trong nhật ký. Ở đâu chúng nói HTTP, proxy có chỗ đứng; ở đâu cần lối ra tổng quát cho các giao thức tùy ý, thiết kế transit gateway là thứ AWS hỗ trợ. Quyết định điều đó trước rẻ hơn là phát hiện sau khi bảng tuyến đã dựng xong.