strongSwan trên EC2: để VPC định tuyến khối lượng công việc

Đường hầm đang hoạt động, instance cổng có thể ping mạng từ xa, và instance ứng dụng bên cạnh không truy cập được gì. Không có gì hỏng. Bài kiểm tra thành công bắt đầu từ máy chủ VPN, và nó chưa bao giờ hỏi liệu máy chủ đó có thể mang một địa chỉ nguồn khác qua cùng một quan hệ IPsec hay không. Hướng dẫn này khép lại khoảng trống đó trong bốn bước, theo thứ tự giữ cho mọi lỗi hiện rõ.

Trước tiên hãy ghi ra bốn địa chỉ

Mỗi bước bên dưới đều tham chiếu đến chúng, vì vậy hãy điền chúng cho tài khoản của bạn trước khi chạm vào bảng định tuyến.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

Ví dụ giả định một kết nối IPsec dựa trên chính sách đã được phê duyệt và đang hoạt động, cùng một luồng giữ nguyên nguồn. Đây không phải là ứng dụng khách truy cập từ xa có NAT vay một địa chỉ được cấp, và sự khác biệt đó quyết định liệu bộ chọn có phải thay đổi hay không.

Bước 1: cấp một tuyến cho subnet của khối lượng công việc

Bảng định tuyến thực sự được liên kết với subnet của khối lượng công việc cần một đường cho tiền tố từ xa trỏ đến giao diện mạng của cổng. Tuyến khách được cài bên trong instance không phải là một mục trong bảng định tuyến AWS đó, và không lượng cấu hình strongSwan nào tạo ra được một tuyến như vậy.

Hướng dẫn của AWS về định tuyến qua thiết bị mô tả các đích giao diện mạng và yêu cầu kiểm tra nguồn/đích của instance chuyển tiếp. Hãy giới hạn thay đổi kiểm tra đó cho vai trò cổng, và để các instance ứng dụng thông thường yên.

Đừng thay thế tuyến cục bộ của VPC hay mọi mục hiện có để nhường chỗ cho một mạng đã được phê duyệt. Hãy kiểm tra cái gì đang được liên kết và hoạt động, thay vì cái mà một trang bảng điều khiển hiển thị cho một bảng định tuyến không ai dùng. Hai bảng trông giống nhau có thể có các liên kết khác nhau. Bảng quan trọng là bảng mà subnet của khối lượng công việc được gắn vào.

Bước 2: bật chuyển tiếp trên máy khách

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

Nhân phải chuyển tiếp, và tường lửa của máy chủ phải cho phép đi qua. Hãy thêm các quy tắc chuyển tiếp dự kiến cho tiền tố của khối lượng công việc và tiền tố từ xa thay vì chấp nhận mọi thứ, và xác nhận subnet của cổng vẫn giữ được một tuyến vận chuyển dùng được cho lưu lượng của chính nó.

Nhóm bảo mật là nơi bước này thường bị kẹt. Một thiết bị trung gian không thừa hưởng hành vi tham chiếu nhóm bảo mật của giao tiếp instance trực tiếp, nên một quy tắc sao chép từ ví dụ Client VPN được quản lý có thể không bao giờ khớp. Hãy kiểm tra nhóm bảo mật và ACL của subnet trên đường thực tế, theo cả hai chiều.

Bước 3: mở rộng bộ chọn đến các nguồn thực

Một chính sách chỉ bao phủ 10.60.1.10/32 ở phía AWS giải thích một thành công bắt nguồn từ cổng mà không bao phủ 10.60.2.20. Một tuyến tới đích từ xa không mở rộng bộ chọn lưu lượng, và đó là nửa còn lại của cùng một bất ngờ.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Nếu thiết kế đã thống nhất bảo vệ toàn bộ VPC, cả hai bên phải chấp nhận 10.60.0.0/16 và 10.90.0.0/24. Nếu nó chỉ bảo vệ một khối lượng công việc, hãy cố ý dùng tiền tố hẹp hơn đó. Dù thế nào, hãy kiểm tra chính sách CHILD-SA đã cài, vì một cấu hình bạn đã sửa và một bên đã thu hẹp nó theo cách khác không phải là cùng một thỏa thuận.

Trang từ xa cũng phải định tuyến các phản hồi cho các nguồn VPC được giữ nguyên quay lại qua cổng IPsec dự kiến. Hãy giữ miễn trừ NAT được hỗ trợ cho lưu lượng được bảo vệ ở nơi có các quy tắc NAT nguồn khác; chuyển một khối lượng công việc chưa được phê duyệt thành một địa chỉ máy chủ được phép là một hợp đồng nhận dạng khác, không phải đường tắt đến quyền truy cập bạn muốn.

Bước 4: xác minh, rồi hoàn nguyên nếu cần

Hãy kiểm tra từ chính khối lượng công việc bằng một thao tác ứng dụng mới được phép, rồi lặp lại với một đích nên bị loại trừ. Ghi lại địa chỉ nguồn mà dịch vụ từ xa nhìn thấy và đường quay về mà nó dùng. Một lần ping cổng hay trạng thái IKE xanh không phải là bài kiểm tra đó.

Nếu khối lượng công việc vẫn thất bại trong khi cổng hoạt động, hãy lùi qua các bước theo thứ tự: bộ chọn, rồi chuyển tiếp và nhóm bảo mật, rồi bảng định tuyến được liên kết. Mỗi thứ có một triệu chứng riêng, và đoán mò sẽ bỏ qua đúng cái đang sai.

Hoàn nguyên đảo ngược cùng thứ tự đó. Hãy xóa tuyến của subnet khối lượng công việc sau cùng, sau khi khôi phục các bộ chọn trước đó, để không bỏ lại một subnet trỏ đến cổng không còn bảo vệ nguồn của nó. Tự lưu trữ có thể phục vụ nhiều hơn máy chủ cổng khi các hợp đồng này đúng, và Site-to-Site VPN do AWS quản lý là một mô hình vận hành khác, nơi strongSwan có thể nằm ở phía cổng khách hàng thay vào đó.