VGW hay TGW? Đường hầm IPsec của AWS Site-to-Site kết thúc ở đâu

Mọi người hỏi AWS Site-to-Site VPN ngừng bảo vệ gói tin ở đâu và mong một câu trả lời duy nhất: tại cổng. Phiên bản hữu ích của câu trả lời đó nêu rõ cổng nào, vì cổng riêng ảo và cổng trung chuyển là hai cách bố trí khác nhau với các đối tượng gắn khác nhau, và người đánh giá giả định sai sẽ dựng phần còn lại của đánh giá trên một sơ đồ không tồn tại. Hãy thực hiện ba kiểm tra dưới đây theo thứ tự. Mỗi kiểm tra hoặc xác nhận ranh giới hoặc cho bạn biết câu trả lời trước đó là về một tài nguyên khác.

Nêu tên ba điểm cuối trước khi đánh giá bất cứ điều gì

Một đợt rà soát mã hóa cho đường đi này cần ba thứ có tên: cổng khách hàng, đích AWS VPN kết thúc IPsec, và điểm cuối ứng dụng nhận gói bên trong. Hãy ghi chúng cùng với mã định danh tài nguyên trước khi mở dù chỉ một trang giao diện điều khiển, vì mọi thứ sau điểm này là một phát biểu về một trong ba thứ đó.

Cổng khách hàng là của bạn và cấu hình của nó hiển thị với bạn. Đích AWS là tài nguyên được quản lý, và sai lầm là giả định nó: một kết nối VPN có thể gắn vào cổng riêng ảo hoặc trực tiếp vào cổng trung chuyển, và không cái nào bao hàm cái kia. Điểm cuối thứ ba là thứ mọi người bỏ qua, và chỉ nó trả lời câu hỏi thực sự về dữ liệu ứng dụng.

Kiểm tra 1: cổng nào thực sự kết thúc đường hầm

Cả hai cách bố trí đều được hỗ trợ và hướng dẫn kiến trúc Site-to-Site VPN mô tả chúng cạnh nhau, nên hãy hỏi API thay vì một sơ đồ thường đã một năm tuổi. Một truy vấn chỉ đọc trên một kết nối trả về các trường đích VPN:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

Yếu tố phân biệt là TransitGatewayId, không phải VpnGatewayId. Kết nối có TransitGatewayId trống kết thúc tại một cổng riêng ảo độc lập, trong khi kết nối có trường đó được đặt kết thúc tại một phần gắn VPN của cổng trung chuyển, và VpnGatewayId vẫn có thể được điền trong trường hợp đó vì nó có thể nêu tên cổng nền của phần gắn. Hãy đọc trường TGW trước, sau đó xác nhận loại phần gắn từ danh sách phần gắn chứ không phải từ tên trường, vì phần gắn VPC trên cổng trung chuyển đó không phải là phần gắn VPN. Việc tìm thấy phiên bản đích trong một VPC đã kết nối không cho bạn biết gì về phần gắn VPN nào đã chở gói tin.

Trong khi ở đó, hãy kiểm tra các đường hầm. Kết nối mang hai đường hầm IPsec để dự phòng, và một kết nối có đường hầm thứ hai chưa bao giờ lên là một phát hiện thực sự về tính sẵn sàng dù nó không thay đổi gì ở ranh giới mã hóa:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

Kiểm tra 2: gói bên trong còn mang gì

Khi IPsec kết thúc, AWS chuyển tiếp gói đã giải đóng gói theo tuyến khớp với nó. Từ điểm đó lưu lượng là lưu lượng VPC thông thường, và sự bảo vệ của VPN đã kết thúc. Đây không phải lỗ hổng của dịch vụ; đây là ý nghĩa của ranh giới, và mục trong danh sách là nói rõ điều đó thay vì để "VPN đã mã hóa" thay chỗ cho "dữ liệu được mã hóa từ đầu đến cuối".

Bây giờ hãy xem bên trong có gì. Nếu gói bên trong là giao thức ứng dụng dạng văn bản thuần, không gì ở hạ nguồn thêm tính bảo mật cho đến khi thứ khác mã hóa nó. Nếu gói bên trong đã mang một phiên TLS, việc bỏ IPsec bên ngoài không thay đổi gì cho phiên đó: nó vẫn được bảo vệ đến điểm cuối của chính nó, bất kể điểm cuối đó ở đâu.

Cách sửa quá mức thường gặp là kết luận rằng mọi thứ sau cổng đều bị lộ. Không phải vậy. Vận chuyển dịch vụ, mã hóa lưu trữ và TLS ứng dụng là những cơ chế riêng với điều kiện riêng, và mỗi cơ chế phải được đánh giá theo điều kiện của chính nó thay vì suy ra từ hình dạng của VPN. Một mục nhật ký luồng hiển thị ACCEPT chứng minh việc định tuyến đã hoạt động và không nói gì về tính bảo mật, và đó chính xác là sai lầm mà danh sách này tồn tại để ngăn chặn.

Kiểm tra 3: điều gì kết thúc TLS phía sau cổng

Hãy theo bộ lắng nghe, không phải địa chỉ. Nếu bộ cân bằng tải hoặc proxy kết thúc TLS, kết nối mà ứng dụng khách của bạn giữ sẽ kết thúc ở đó, và proxy mở kết nối thứ hai tới phần phụ trợ, kết nối này có thể là văn bản thuần hoặc TLS với chuỗi tin cậy khác. Một địa chỉ IP riêng và tuyến khớp không phải bằng chứng về kết nối thứ hai đó.

Hãy kiểm tra điểm cuối mà bạn thực sự quan tâm từ bên trong VPC, với tên mà ứng dụng dùng chứ không phải IP bạn đã phân giải một lần:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

Lặp lại điều đó cho từng chặng mà yêu cầu đi qua. Nếu câu trả lời khác nhau giữa tên hướng tới ứng dụng khách và tên phần phụ trợ, bạn đã tìm thấy đúng đoạn mà VPN chưa bao giờ bao phủ, và đó là phát hiện cần ghi lại.

Ghi lại kết quả theo đoạn, không phải theo phán quyết

Đầu ra của danh sách này là một bảng nhỏ với một dòng cho mỗi đoạn: cổng khách hàng đến đích AWS VPN, cổng đến khối lượng công việc, khối lượng công việc đến kho dữ liệu, và mọi chặng proxy ở giữa. Mỗi dòng nói điều gì bảo vệ nó và sự bảo vệ đó phụ thuộc vào đâu. "Đã mã hóa" không có cơ chế và không có điểm cuối không phải là một dòng.

Sau đó trả lời yêu cầu ban đầu bằng đúng những thuật ngữ mà nó được đặt ra. Nếu yêu cầu là dữ liệu vẫn bảo mật cho đến khi khối lượng công việc nhận được, VPN chỉ đáp ứng đoạn đầu tiên, và các dòng còn lại cần vận chuyển ứng dụng, TLS dịch vụ hoặc mã hóa lưu trữ được cấu hình và xác minh riêng.

Hãy giữ mã định danh kết nối, trạng thái đường hầm và chủ thể chứng chỉ trong hồ sơ. Khi ai đó quay lại thiết kế sau sáu tháng, ba hiện vật đó trả lời câu hỏi về ranh giới trong vài phút thay vì bắt đầu lại cuộc tranh luận từ một sơ đồ.