VM GCP với nhiều NIC: vì sao phản hồi đi ra qua giao diện sai

Gắn thêm giao diện thứ hai vào một VM Compute Engine cho nó một kết nối mạng khác, không phải đường trở về đối xứng. Khách vẫn chọn giao diện và địa chỉ nguồn từ các tuyến và quy tắc của chính nó. Sau đó Google Cloud áp dụng định tuyến VPC và chính sách tường lửa quanh giao diện mà gói tin đã rời đi. Khi hai quyết định này không khớp nhau, yêu cầu đến trên một NIC và phản hồi đi ra qua NIC kia, và chi nhánh thấy một cuộc trò chuyện nửa mở.

Đi hết tuyến qua năm bước và sự không khớp sẽ lộ ra trước khi bạn viết một quy tắc chính sách.

Bước 1: ánh xạ NIC của đám mây với thiết bị của khách

Đám mây đặt tên các giao diện là nic0, nic1 và tương tự, còn khách thấy các tên thiết bị không nhất thiết phải khớp. Giải quyết ánh xạ từ siêu dữ liệu của phiên bản hoặc từ địa chỉ của chính giao diện trước bất cứ điều gì khác. Tuyến mặc định thông thường do DHCP cung cấp gắn với nic0, đó là lý do tuyến hướng ra internet thường thắng một cách tình cờ. Viết chính sách theo một tên thiết bị phỏng đoán là cách một quy tắc đúng rơi vào giao diện sai.

Ghi lại địa chỉ, tên thiết bị và VPC mà mỗi cái thuộc về. Bản đồ ba cột đó là đầu vào cho mọi bước tiếp theo.

Bước 2: gọi tên hai quyết định định tuyến

Quyết định thứ nhất thuộc về khách: giao diện nào và địa chỉ nguồn nào cho gói tin này. Quyết định thứ hai thuộc về đám mây: các tuyến của VPC và chính sách tường lửa cho phép gì quanh giao diện đó.

Một tuyến nhìn thấy trong VPC hướng về VPN không trở thành tuyến của khách chọn NIC đó. Tuyến của đám mây mô tả những gì mạng có thể chuyển giao, trong khi tuyến của khách quyết định gói tin làm gì.

Bước 3: chọn chính sách đường trở về

Với một tập tiền tố chi nhánh nhỏ và ổn định, các tuyến đích rõ ràng trong khách là cách diễn đạt đơn giản nhất: phản hồi cho các tiền tố đó đi ra qua giao diện hướng về VPN. Khi nhiều dịch vụ cố ý dùng các địa chỉ nguồn cục bộ khác nhau, các quy tắc dựa trên nguồn chọn bảng cho từng giao diện giữ mỗi phản hồi trong đúng ngữ cảnh. Tài liệu về nhiều giao diện mô tả cách đặt tên NIC và hành vi tuyến mặc định mà các thiết kế này dựa vào.

Mỗi bảng cần các tuyến kết nối hợp lệ và bước nhảy tiếp theo, cùng các đích sẽ được hỏi tới. Một quy tắc trỏ vào bảng chưa hoàn chỉnh không phải là thiết kế đường trở về. Dùng cổng được tài liệu hóa cho NIC đó thay vì bịa ra một cổng Ethernet từ vẻ ngoài của mạng con.

Bước 4: kiểm tra các bộ lọc của chính khách

Kiểm tra máy chủ lắng nghe ở đâu và phản hồi mang theo nguồn cục bộ nào. Một trình lắng nghe trên mọi địa chỉ không ghi đè chính sách định tuyến, nên gắn với mọi địa chỉ không thay đổi gì về giao diện mà câu trả lời đi ra.

Trên Linux, xem lại việc kiểm tra tuyến ngược so với thiết kế dự định. Tắt nó trên toàn hệ thống như bước đầu tiên đánh đổi một lỗi định tuyến lấy nguy cơ giả mạo, và che giấu sự bất đối xứng mà bạn đang cố tìm.

Bước 5: kiểm tra một luồng cho mỗi tuyến

Kiểm tra riêng một yêu cầu chi nhánh được phép và một yêu cầu internet không liên quan, mỗi cái với nguồn và đích thật của nó. Bắt gói trên cả hai giao diện khi có thể, vì bằng chứng hữu ích là giao diện nào đã mang phản hồi. Sau đó xác nhận rằng chính sách phía đám mây đã tôn trọng tuyến bạn thiết kế. Một yêu cầu thành công chứng minh một luồng, không phải một thiết kế đối xứng.

Giữ hai bài kiểm tra riêng trong ghi chú của bạn, vì chúng dùng các tuyến khác nhau và các quy tắc tường lửa khác nhau.

Điều mà NIC thứ hai không cho bạn

Giao diện thứ hai thêm một kết nối mạng và một địa chỉ nữa. Nó không thêm định tuyến đối xứng tự động và không vượt qua chính sách tường lửa. Coi nó là bản sửa lỗi định tuyến là lý do các thiết kế nhiều NIC tích tụ những quy tắc mà sau này không ai giải thích được.

Nếu VM phải chuyển tiếp lưu lượng của các máy khác, hãy lập kế hoạch cho vai trò bộ định tuyến đó một cách rõ ràng, gồm cả cài đặt đám mây cho phép chuyển tiếp và các bộ lọc của khách đi kèm.