EC2 xuyên các vùng sẵn sàng: kiểm tra định tuyến trước khi dùng VPN

Trước khi cài đặt phần mềm VPN giữa hai phiên bản EC2, hãy trả lời một câu hỏi: chúng có trong cùng một VPC không? Nếu có, đường đi riêng đã tồn tại và việc đặt ở các vùng khác nhau không thay đổi điều đó. Phần lớn công việc trong tình huống này là xác nhận mỗi subnet thực sự dùng bảng định tuyến nào, rồi tìm hiểu xem sự cố có phải là vấn đề định tuyến ngay từ đầu hay không. Một đường hầm thường là câu trả lời sai cho câu hỏi cụ thể này.

Kiểm tra 1: cùng một VPC hay các VPC khác nhau

VPC mang tính khu vực và trải rộng các vùng sẵn sàng, trong khi mỗi subnet thuộc đúng một vùng. Hai phiên bản ở các vùng khác nhau của cùng một VPC vẫn nằm trong cùng miền định tuyến riêng.

Các VPC khác nhau không bao giờ có được tuyến riêng chỉ vì chúng dùng chung một khu vực hay nhãn vùng. Trường hợp đó cần một kết nối được hỗ trợ cùng công việc về tuyến và quyền riêng, đây là một quyết định tách biệt.

Kiểm tra 2: bảng định tuyến của subnet nói gì

Hãy ghi lại sơ đồ với giá trị thật. Một VPC tại 10.60.0.0/16 với các subnet 10.60.1.0/24 và 10.60.2.0/24 cho các phiên bản 10.60.1.10 và 10.60.2.20 một đường đi qua tuyến cục bộ của VPC.

Sau đó hãy xem các bảng gắn với cả hai subnet, không chỉ bảng bạn tìm thấy đầu tiên. Một tuyến kiểm tra hoặc tuyến thiết bị cụ thể hơn có thể ghi đè tuyến cơ sở, và bản thân đích của tuyến cục bộ cũng có thể bị thay thế trong các cấu hình mới hơn. Một tuyến cục bộ hiển thị ở đâu đó trong bảng điều khiển không chứng minh rằng cả hai khối lượng công việc đều dùng nó.

Hãy dùng địa chỉ và tên riêng mà VPC thực sự cấp. Địa chỉ riêng không nhất thiết phải bắt đầu bằng 10, và việc bịa ra một địa chỉ từ trí nhớ chính là cách chẩn đoán sai một môi trường đang hoạt động.

Kiểm tra 3: định tuyến hay cấp quyền

Định tuyến chỉ đưa gói tin đến giao diện mạng của đích. Nhóm bảo mật của đích vẫn phải chấp nhận nguồn và dịch vụ, các quy tắc ra của nguồn phải cho phép yêu cầu, và mọi ACL mạng phải cho phép cả hai chiều vì ACL không lưu trạng thái.

Phía sau đó là tường lửa của khách, việc ràng buộc của trình lắng nghe và danh tính của chính ứng dụng. Bất kỳ thành phần nào cũng có thể từ chối một yêu cầu mà định tuyến đã chuyển đến hoàn hảo.

Việc chấp nhận phải là thao tác thật của ứng dụng. Một ping thành công không cấp quyền truy cập ứng dụng và không chứng minh tên TLS cùng thông tin đăng nhập là đúng, và một ping bị chặn không chứng minh mọi dịch vụ riêng đều ngừng hoạt động.

Kiểm tra 4: có thực sự cần một kết nối riêng

VPN vẫn có thể thuộc về thiết kế, nhưng vì một lý do được nêu: kết nối VPC này với văn phòng, cho phép máy tính xách tay truy cập hoặc đáp ứng yêu cầu lớp phủ. Lý do đó khác với liên lạc thông thường trong cùng một VPC.

Cũng hãy nhớ VPC không phải là gì. Nó không phải là phần mở rộng của một đoạn Ethernet trong nhà. Một ứng dụng phụ thuộc vào việc phát hiện bằng quảng bá có yêu cầu riêng cần đánh giá. Đó là lỗ hổng thiết kế chứ không phải lỗi định tuyến.

Kiểm tra 5: câu hỏi về mã hóa

Một địa chỉ riêng và một quy tắc cho phép không nói gì về bảo vệ mật mã ở lớp ứng dụng. Nếu dữ liệu cần bảo vệ từ đầu đến cuối, điều đó đến từ giao thức và mô hình danh tính mà dịch vụ thực sự hỗ trợ.

Hãy tách riêng các khẳng định về lớp mạng và lớp ứng dụng trong ghi chú thiết kế, vì gộp chúng lại chính là cách một buổi đánh giá cuối cùng khẳng định một sự bảo vệ mà không ai triển khai.

Cần ghi lại những gì

Ghi lại cả hai ID subnet, bảng định tuyến gắn với từng subnet, các tham chiếu nhóm bảo mật và thao tác ứng dụng bạn đã kiểm tra. Đó là bốn sự kiện, và chúng giải quyết phần lớn các tranh luận sau này về đường đi này.

Chỉ riêng việc đặt trong một vùng không bao giờ nói với bạn rằng hãy thêm VPN, và cũng không bao giờ giải thích vì sao một yêu cầu riêng thất bại.