Thêm một mạng con nội bộ vào AWS VPN: VGW so với Transit Gateway

Một VPN Site-to-Site hiện có đang mang 10.60.0.0/16, một mạng dịch vụ mới xuất hiện sau cùng cổng nội bộ đó với địa chỉ 10.70.0.0/16, và ai đó hỏi liệu có cần proxy không. Thường là không: một đường đã định tuyến có thể mang tiền tố, nhưng chỉ khi ba điều khớp nhau, và ba điều nào thì phụ thuộc vào kiến trúc AWS bạn đang vận hành. Cổng riêng ảo có một ranh giới bảng định tuyến; transit gateway thêm ranh giới thứ hai. Quảng bá đúng mà bảng sai sẽ tạo ra một phiên trông khỏe mạnh nhưng không giao gì cả.

Quảng bá một tiền tố mà cổng thực sự có thể giao được

Cổng nội bộ cần một đường đi tiếp vào mạng mới trước khi bất kỳ quảng bá nào có ý nghĩa. Quảng bá 10.70.0.0/16 qua BGP cho AWS biết nơi gửi gói tin của dải đó; nó không tạo ra đường chuyển tiếp cục bộ giúp dải đó đến được ở đầu bên kia. Hãy xác nhận cổng có tuyến cho tiền tố trỏ tới thiết bị đang giữ tiền tố đó, và thiết bị được cấu hình để trả lời cho các địa chỉ ấy. Chính sách xuất và giới hạn tiền tố được chấp nhận là ràng buộc tiếp theo, vì một tiền tố bị phiên lọc bỏ sẽ không bao giờ đến AWS.

Giữ các tổng hợp và các tuyến cụ thể hơn một cách có chủ đích. Những đường trùng lặp đến từ hai hướng là một quyết định thiết kế, không phải chi tiết phát hiện sau này.

Đường thứ nhất: ranh giới của cổng riêng ảo

Với cổng riêng ảo, tài liệu định tuyến AWS VPN mô tả hai chế độ phân phối, tuyến tĩnh và quảng bá BGP, và cả hai đều phụ thuộc vào bảng định tuyến mạng con mà ứng dụng thực sự dùng. Lan truyền thuận tiện khi bạn kiểm soát toàn bộ dải, và một tuyến rõ ràng dễ lập luận hơn khi bạn muốn đích được liệt kê cạnh mục tiêu. Dù thế nào, kiểm tra vẫn như nhau: bảng của mạng con ứng dụng cụ thể có đường hoạt động tới mục tiêu VPN cho tiền tố mới không, và nó có thắng thứ gì cụ thể hơn không?

Một phiên BGP khỏe mạnh chứng minh kênh tồn tại. Nó không nói gì về việc một bảng mạng con nhất định đã nhận tuyến hay chưa.

Đường thứ hai: transit gateway thêm một bảng

Transit gateway chia câu hỏi duy nhất đó thành hai. Mạng con của VPC phải gửi đích đến tới gắn kết transit gateway, rồi bảng định tuyến của transit gateway phải chọn gắn kết VPN cho cùng tiền tố đó. Các lựa chọn liên kết và lan truyền quyết định mạng nào được gắn nhận tuyến, nên một tiền tố có thể được VPN quảng bá đúng mà vẫn không bao giờ đến được VPC có bảng chưa từng được liên kết với bảng định tuyến đúng.

Lỗi thường gặp là một tuyến có trong bảng này mà không có trong bảng kia, khi mỗi nhóm đều tin phía mình đúng. Khi bạn so sánh hai kiến trúc, ranh giới thêm này chính là toàn bộ khác biệt: nhiều chỗ để xem hơn, và kiểm soát chính xác hơn ai nhận tuyến.

Lan truyền tuyến cũng không cấp tiền tố cho mọi gắn kết. Nó phân phối tới các bảng được cấu hình để nhận.

Đường quay về là một quyết định chính sách riêng

Lưu lượng đến chỉ là một nửa của trao đổi. Mạng nội bộ mới cần một đường quay về các tiền tố nguồn của AWS qua cổng đúng, và chính sách bảo mật ở cả hai đầu phải cho phép cặp nguồn và đích đó. Nếu đường hầm thương lượng phạm vi bảo vệ với bộ chọn lưu lượng, tiền tố mới phải nằm trong đó, nếu không gói tin bị bỏ trước khi bất kỳ bảng định tuyến nào được xem.

Chồng lấn địa chỉ là cái bẫy khác. Các dải tách rời, có chủ sở hữu rõ ràng giữ việc này đơn giản; các dải chồng lấn nghĩa là phải dịch hoặc thiết kế lại, và không cái nào là biến thể hoán đổi được của cùng một công thức.

Hãy thử với nguồn trong mạng mới và đích trong mạng con ứng dụng, rồi lặp lại theo chiều ngược lại. Một thử nghiệm một chiều chỉ chứng minh một chiều.

Khi proxy thực sự là ranh giới tốt hơn

Proxy có chỗ đứng khi yêu cầu là một giao diện dịch vụ hẹp, khi ứng dụng đã mong đợi kiến trúc đó, hoặc khi không thể buộc đường mạng mang tiền tố mà không cần một phép dịch bạn không muốn. Nó không phải giải pháp dự phòng cho một mục trong bảng định tuyến mà không ai kiểm tra.

Hãy quyết định theo thứ tự này: chuyển tiếp cục bộ, quảng bá, ranh giới bảng, chính sách quay về. Sửa cái đầu tiên thất bại, và chỉ sau đó mới hỏi liệu đường đã định tuyến có phải là câu trả lời đúng.