AWS Client VPN với tunnel chia tách: nên công bố những tuyến nào

Bảng điều khiển cung cấp một công tắc cho tunnel chia tách, nên quyết định có vẻ như một ô chọn. Không phải vậy. Thứ thực sự đến máy khách là tập tuyến đã công bố của điểm cuối, và danh sách đó quyết định tiền tố riêng nào dùng tunnel, lưu lượng internet chung ở lại cục bộ hay đi ra qua AWS, và máy khách còn nói chuyện được với resolver nào. Ba câu hỏi quyết định thiết kế, và mỗi câu đều có thể bị trả lời sai trong khi kết nối vẫn thành công.

Cờ tunnel chia tách không phải danh sách đích

AWS mô tả tunnel chia tách là việc thêm các tuyến của điểm cuối vào bảng tuyến của máy khách khi thiết lập kết nối. Một tuyến cho VPC riêng giới hạn tunnel trong đích đó; mọi thứ khác đi theo đường thông thường của máy khách. Tuyến mặc định là một chỉ dẫn khác với hiệu ứng khác, vì thế tài liệu về tunnel chia tách cảnh báo không nên công bố 0.0.0.0/0 trên một điểm cuối được cấu hình cho chế độ này: nó thường phá kết nối thay vì mở rộng. Bảng tuyến của điểm cuối là chính sách, và bảng tuyến của máy khách là kết quả bạn có thể kiểm tra.

Đọc bảng tuyến của điểm cuối và các tuyến đã cài trên máy khách cùng lúc. Nhãn mô tả ý định; các tuyến mô tả điều gì xảy ra.

Quyết định một: lưu lượng internet chung có nên ở lại cục bộ?

Nếu việc duyệt web phải dùng kết nối riêng của người dùng, chỉ công bố những đích riêng mà công việc cần và dừng ở đó. Đừng thêm tuyến internet vì một bài hướng dẫn tunnel đầy đủ có một tuyến như vậy, và đừng cho rằng tuyến thêm cải thiện bảo mật. Nó thay đổi đường đi, không thêm chính sách, và thường tốn độ trễ mà bạn không dự trù.

Nếu lưu lượng internet phải đi ra qua AWS, hãy dựng kiến trúc truy cập internet đã được ghi lại: tuyến điểm cuối, quy tắc ủy quyền, đường đi của subnet liên kết, chính sách bảo mật và một lối ra thượng nguồn hoạt động. Chỉ một tuyến mặc định không cung cấp bất kỳ điều nào trong số đó.

Quyết định hai: những tiền tố riêng nào, được ai cho phép?

Công bố tập đích nhỏ nhất phục vụ khối lượng công việc thực tế, và xác minh rằng mỗi subnet liên kết có thể định tuyến tới chúng. Đích của tuyến điểm cuối và định tuyến VPC của subnet là các lớp khác nhau, và một tuyến tồn tại ở lớp này không phải bằng chứng về lớp kia. Ủy quyền lại tách riêng: một đích có thể tới được mà vẫn bị từ chối vì nhóm của máy khách không có quy tắc cho phép.

Thử một phiên thành công chỉ chứng minh một đường. Hãy kiểm tra mọi subnet liên kết, vì một liên kết subnet được thêm sau đó chính là nơi tuyến bị thiếu thường nằm.

Khi một đích phải tới được bằng tên, lưu ý rằng câu hỏi tiếp theo là phân giải tên, không phải tuyến.

Quyết định ba: resolver nào đi theo tunnel?

Máy khách có thể nhận một máy chủ DNS chỉ tới được qua VPN, và resolver đó chỉ hoạt động nếu địa chỉ của nó nằm trong một tuyến được ủy quyền. Xác minh cả hai nửa: địa chỉ resolver đi theo một tuyến đã công bố, và máy chủ trả lời các tên mà ứng dụng hỏi. Một yêu cầu thành công theo địa chỉ nhưng thất bại theo tên máy chủ cho thấy vấn đề đặt tên, không phải định tuyến, và gỡ lỗi tunnel trong trường hợp đó phí mất buổi chiều.

Tên công cộng nên được phân giải như trước khi kết nối, đây là một lý do nữa để chính xác về những gì bạn công bố.

Thay đổi tập tuyến, rồi xác minh cả hai thế giới

AWS ghi rằng việc thay đổi tuyến trên điểm cuối tunnel chia tách sẽ đặt lại kết nối của máy khách. Hãy lập kế hoạch thay đổi với điều đó: áp dụng, kết nối lại qua máy khách được hỗ trợ, và đọc lại các tuyến đã cài thay vì tin vào trạng thái đã áp dụng trước khi chỉnh sửa. Trạng thái đã áp dụng cũ là lý do phổ biến nhất khiến một thay đổi đúng trông như hỏng.

Chỉ chấp nhận thiết kế khi một tài nguyên riêng và một đích công cộng đều hoạt động như dự định, theo tên và theo địa chỉ, trong những họ địa chỉ bạn thực sự hỗ trợ. Một tunnel xác thực không giống một tunnel chia tách đúng.

Viết danh sách tuyến vào runbook bên cạnh lý do, để người tiếp theo phân biệt được một loại trừ có chủ đích với một loại trừ bị quên.