VPN site-to-site từ AWS sang Azure: viết tuyến quay về trước
Một đường hầm đã kết nối giữa hai đám mây không chứng minh được gì cho đến khi mỗi subnet của khối lượng công việc định tuyến tới tiền tố xa. Hãy làm theo kế hoạch đúng thứ tự, rồi kiểm thử dịch vụ.
Đường hầm sẽ lên. Thường là vậy, vì IKE chỉ cần các đề xuất khớp nhau và một địa chỉ peer có thể tới được. Thứ thất bại sau đó là đường quay về: khối lượng công việc trong AWS gửi gói vào đường hầm, nhưng không gì phía Azure biết cách trả lời 10.10.0.0/16, hoặc tuyến Azure nằm trong bảng mà subnet của khối lượng công việc không dùng. Hãy viết kế hoạch tuyến trước khi chạm vào bất kỳ bảng điều khiển nào, và đường hầm sẽ trở thành phần kém thú vị nhất của công việc.
Bước 1: đóng băng kế hoạch địa chỉ
Làm việc với các giá trị cụ thể. Một khối lượng công việc trong AWS nằm ở 10.10.1.20 trong 10.10.0.0/16 và cần TCP 443 tới dịch vụ Azure ở 10.20.1.30 trong 10.20.0.0/16. Hai dải không được chồng lấn, và phép thử chấp nhận là cặp dịch vụ, không phải đường hầm.
Viết bốn sự kiện đó trước mọi thứ khác, vì mọi bước sau đều được kiểm tra dựa trên chúng.
Bước 2: gọi tên cổng kết nối sở hữu mỗi đầu
AWS Site-to-Site VPN có thể kết thúc trên virtual private gateway hoặc transit gateway, và đó là những chủ sở hữu định tuyến khác nhau. Azure cung cấp VPN Gateway được quản lý và, riêng biệt, các thiết bị dựa trên VM do khách hàng tự vận hành. Ghi lại bạn có cặp nào, vì bước nhảy tiếp theo khác nhau ở mỗi tổ hợp.
Với cổng được quản lý, đừng sao chép một tuyến trỏ tới địa chỉ thiết bị riêng đoán được. Với thiết bị, đừng cho rằng việc lan truyền tuyến trong đám mây sẽ cấu hình hệ điều hành khách, vì nó không làm vậy.
Sai ở đây tạo ra một kế hoạch trông đầy đủ và gửi gói tới địa chỉ không bao giờ trả lời.
Bước 3: viết tuyến mà mỗi khối lượng công việc thực sự dùng
Mỗi ranh giới bên dưới là một lần tra cứu riêng, và một tuyến trong một trong số đó không phải tuyến của gói. Điền bảng bằng giá trị của bạn trước khi đường hầm đi vào hoạt động.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
Trong AWS, bảng tuyến của subnet khối lượng công việc là của bạn để cập nhật ngay cả sau khi BGP hoặc đường hầm khỏe; tổng quan định tuyến coi đó là một phần của kết nối. Trong Azure, bảng tuyến do người dùng định nghĩa được liên kết với subnet chứ không phải mạng ảo, nên hãy kiểm tra tuyến hiệu lực trên NIC của khối lượng công việc chứ không phải trong bảng VNet.
Một cổng Azure được quản lý có thể học tiền tố xa qua lan truyền cổng, và một UDR có thể vô hiệu quyết định đó. Chỉ thêm UDR khi có lý do, không theo phản xạ. Nếu thêm, hãy trỏ nó tới bước nhảy tiếp theo mà cổng công bố cho đường VPN thay vì bịa ra địa chỉ thiết bị. Sau đó đọc lại các tuyến hiệu lực trên NIC, vì quyết định thực sự được đưa ra ở đó.
Bước 4: dung hòa phạm vi
Với BGP, so sánh điều mỗi bên quảng bá với điều bên kia thực sự học được, từng tiền tố một. Với định tuyến tĩnh, so sánh các dải xa đã cấu hình với các tuyến khối lượng công việc bạn đã viết ở bước 3.
Một quan hệ IKE đồng ý về mật mã không phải bằng chứng rằng bên nào đã học 10.10.0.0/16 hoặc 10.20.0.0/16. Hai đường hầm có thể đang lên trong khi một bên quảng bá một /24 duy nhất thay vì /16 bạn đã hoạch định. Hãy kiểm tra tiền tố trong bảng định tuyến, không phải trong trạng thái đường hầm. Sự không khớp lộ ra sau đó như một subnet chạy được và một subnet không bao giờ trả lời.
Bước 5: kiểm thử dịch vụ, từ nguồn thật
Cho phép luồng dự kiến trong nhóm bảo mật và ACL mạng của AWS, trong NSG của Azure và trong bất kỳ bộ lọc thiết bị nào trên đường. Sau đó mở một kết nối từ 10.10.1.20 tới địa chỉ và cổng đã được phê duyệt của dịch vụ và xác nhận rằng phản hồi quay về đúng nguồn đó.
Cả nhóm bảo mật trên đám mây và NSG đều có trạng thái, nên một gói quay về bị từ chối là triệu chứng định tuyến, không phải quy tắc bạn quên viết ngược lại.
Ping từ bất kỳ cổng nào không quyết định điều gì. ICMP tới địa chỉ cổng chỉ luyện đường đi của mặt phẳng điều khiển, không phải dịch vụ TCP được chuyển tiếp mà khối lượng công việc cần.
Hoàn tác và hồ sơ
Ghi lại chủ sở hữu tuyến bên cạnh định danh đường hầm và giữ lại bảng tuyến trước khi thay đổi. Nếu phải gỡ thay đổi, hãy xóa các tuyến khối lượng công việc trước khi dỡ đường hầm, để không subnet nào còn trỏ tới một bước nhảy không còn tồn tại.
Khi đó, một lần di chuyển subnet hay kết nối spoke sau này có một chỗ xác định để cập nhật, thay vì một đường hầm đang chạy phải gánh lỗi cho tuyến mà nó chưa bao giờ sở hữu.