Vấn đề
Bạn vừa thiết lập một kết nối VPC Peering. AWS Console hiển thị trạng thái Active màu xanh lá cây, và mọi thứ có vẻ đã sẵn sàng. Tuy nhiên, ngay khi bạn cố gắng ping một cơ sở dữ liệu hoặc SSH vào một instance trong VPC đã được kết nối (peered VPC), bạn gặp phải trở ngại:
Request timeout for icmp_seq — no route to host
Thông thường, điều này có nghĩa là "cây cầu" đã tồn tại, nhưng các instance của bạn không có bản đồ để tìm thấy nó. Các gói tin mạng đi đến gateway cục bộ và dừng lại vì chúng không có hướng dẫn rõ ràng về cách tiếp cận dải CIDR từ xa.
Cách khắc phục trong 60 giây
VPC Peering yêu cầu định tuyến thủ công. Bạn phải cập nhật Route Tables cho các subnet trong cả hai VPC để đảm bảo lưu lượng truy cập có thể lưu thông theo cả hai chiều:
- Mở VPC Dashboard và chọn Route Tables.
- Tìm Route Table cho instance nguồn của bạn (ví dụ:
10.0.0.0/16). - Thêm một route: Đặt Destination là CIDR của VPC từ xa (ví dụ:
172.31.0.0/16) và Target là IDpcx-xxxxxxcủa bạn. - Quan trọng: Chuyển sang Route Table của VPC đích và thêm một route phản hồi trỏ ngược lại CIDR nguồn của bạn.
Tại sao điều này xảy ra
AWS xây dựng cơ sở hạ tầng mạng khi bạn kết nối các VPC, nhưng nó sẽ không can thiệp vào logic định tuyến của bạn vì lý do bảo mật. Hãy coi VPC Peering như một đường hầm riêng tư mới giữa hai tòa nhà văn phòng. Mặc dù đường hầm đã mở, nhân viên sẽ không sử dụng nó trừ khi bạn đặt các biển báo chỉ dẫn họ hướng tới lối thoát mới.
Lỗi định tuyến thường xuất phát từ ba lỗ hổng:
- Lỗ hổng phía Người yêu cầu (Requester): VPC nguồn không nhận diện kết nối peering là một gateway hợp lệ cho IP đích.
- Lỗ hổng phía Người chấp nhận (Accepter): VPC đích nhận được gói tin nhưng không biết cách gửi phản hồi (ACK) trở lại.
- Định tuyến bất đối xứng (Asymmetric Routing): Lưu lượng chỉ di chuyển theo một hướng, khiến kết nối thất bại ở bước bắt tay giao thức (protocol handshake).
Hướng dẫn từng bước
1. Xác nhận chi tiết mạng của bạn
Trước khi thao tác trên console, hãy chuẩn bị sẵn ba giá trị sau:
- VPC A (Requester):
10.0.0.0/16 - VPC B (Accepter):
172.31.0.0/16 - Peering ID:
pcx-0a1b2c3d4e5f6g7h8
2. Cấu hình Route nguồn (VPC A)
- Trong VPC Console, nhấp vào Route Tables.
- Chọn bảng liên kết với subnet của instance. Nếu bạn có nhiều subnet (Public/Private), hãy đảm bảo bạn cập nhật subnet mà instance của bạn thực sự sử dụng.
- Chọn Actions > Edit routes.
- Nhấp vào Add route. Nhập
172.31.0.0/16làm Destination. - Tại mục Target, chọn Peering Connection và chọn ID
pcx-...của bạn. - Lưu các thay đổi.
3. Cấu hình Route phản hồi (VPC B)
Bỏ qua bước này là nguyên nhân phổ biến nhất dẫn đến lỗi "no route to host". Giao tiếp phải mang tính hai chiều.
- Tìm Route Table cho subnet đích trong VPC B.
- Nhấp vào Edit routes và thêm một mục mới.
- Nhập
10.0.0.0/16(dải của VPC A) làm Destination. - Chọn cùng một Peering Connection ID làm Target.
- Lưu các thay đổi.
4. Khắc phục nhanh qua AWS CLI
Nếu bạn thích sử dụng terminal, hãy chạy các lệnh sau để kết nối ngay lập tức:
# Tuyến đường từ VPC A đến VPC B
aws ec2 create-route \
--route-table-id rtb-11111111 \
--destination-cidr-block 172.31.0.0/16 \
--vpc-peering-connection-id pcx-0a1b2c3d4e5f6g7h8
# Tuyến đường từ VPC B đến VPC A
aws ec2 create-route \
--route-table-id rtb-22222222 \
--destination-cidr-block 10.0.0.0/16 \
--vpc-peering-connection-id pcx-0a1b2c3d4e5f6g7h8
Kiểm tra kết nối
Sau khi cập nhật các bảng, hãy xác minh đường truyền. Bắt đầu với một bước kiểm tra ICMP đơn giản từ một instance trong VPC A:
# Ping IP riêng của instance từ xa
ping 172.31.20.5
# Kiểm tra xem cổng dịch vụ cụ thể có thể truy cập được không
nc -zv 172.31.20.5 80
Nếu ping vẫn thất bại, hãy sử dụng VPC Reachability Analyzer. Tạo một đường truyền giữa hai instance của bạn. Nó sẽ tạo ra một sơ đồ trực quan và cho bạn biết chính xác quy tắc Security Group hoặc NACL nào đang chặn lưu lượng của bạn.
Mẹo chuyên nghiệp để ổn định mạng
- Phạm vi Security Group: Đảm bảo instance đích cho phép lưu lượng truy cập đến từ CIDR nguồn. Lưu ý: Bạn không thể tham chiếu ID Security Group giữa các region trong một kết nối peering.
- NACLs: Không giống như Security Group, Network ACL là stateless. Bạn phải cho phép cả lưu lượng truy cập vào (inbound) và ra (outbound) ở cả hai đầu.
- CIDR bị trùng lặp: Nếu cả hai VPC đều sử dụng
10.0.0.0/16, peering sẽ không hoạt động. AWS không thể định tuyến lưu lượng khi cả hai bên đều sử dụng cùng một không gian địa chỉ.
Để tránh xung đột địa chỉ trước khi xây dựng VPC, tôi khuyên bạn nên sử dụng ToolCraft Subnet Calculator. Đây là một cách tuyệt vời để lập bản đồ các khối CIDR cho môi trường Dev, Staging và Production nhằm đảm bảo chúng không bao giờ bị trùng lặp khi thực hiện peering trong tương lai.