Đường hầm đầy đủ của Access Server trên EC2: vì sao một ô kiểm không đủ

Tắt kiểm tra nguồn và đích trên một phiên bản EC2 là câu trả lời được lặp lại nhiều nhất cho các câu hỏi về đường ra internet của Access Server, và tự nó không làm gì cho khách hàng của bạn. Việc kiểm tra là một ràng buộc chuyển tiếp của AWS: nó khiến phiên bản chấp nhận các gói mà nguồn hoặc đích không phải là địa chỉ của chính nó. Nó không bảo máy khách gửi lưu lượng internet qua đường hầm, không tạo tuyến đường lên trên và không thêm NAT. Điều hoang đường là ô kiểm chính là tính năng.

Việc kiểm tra thực sự kiểm soát gì

Mỗi giao diện mạng EC2 đều loại bỏ lưu lượng không được gửi đến nó, trừ khi phiên bản hoạt động như bộ định tuyến, thiết bị NAT hoặc cổng VPN và bạn tắt việc kiểm tra đó. Tắt nó cho phép chuyển tiếp. Quyền không phải là cấu hình: phiên bản vẫn cần tuyến đường đến cổng internet hoặc thiết bị NAT, bảng tuyến VPC vẫn cần mục tương ứng, nhóm bảo mật vẫn phải cho phép luồng, và máy chủ vẫn phải dịch hoặc định tuyến lưu lượng quay về.

Kiểm tra giá trị hiện tại bằng aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck trước khi thay đổi bất cứ điều gì. Nếu bạn thay đổi trong bảng điều khiển, hãy thay đổi vì phiên bản chuyển tiếp cho người khác, không phải vì máy khách không vào được internet.

Chính sách định tuyến của máy khách thuộc về Access Server

Trong Access Server 3, mở Access Controls và tìm phần Internet Access and DNS. Lựa chọn Internet Gateway cung cấp đường hầm đầy đủ hoặc chia tách; đường hầm đầy đủ bảo máy khách định tuyến lưu lượng mặc định vào VPN, đường hầm chia tách để lưu lượng internet trên đường cục bộ của máy khách. Lưu và áp dụng qua quy trình của sản phẩm, rồi kết nối lại máy khách thử nghiệm, vì chính sách được gửi khi kết nối.

Các bản phát hành cũ dùng menu khác và một số bản dựng Community của OpenVPN không có điều khiển tương đương. Kiểm tra phiên bản chính đã cài trước khi tìm một màn hình không tồn tại. Sau đó xác nhận máy khách nhận được gì: hồ sơ đường hầm đầy đủ phải cài tuyến mặc định qua đường hầm, còn hồ sơ đường hầm chia tách thì không.

Lần theo gói tin sau đường hầm

Khi máy khách gửi lưu lượng internet vào đường hầm, máy chủ phải chuyển tiếp và thường phải dịch nó. Access Server quản lý các quy tắc NAT và định tuyến của riêng nó, vì vậy hãy đọc cấu hình hiệu lực thay vì thêm quy tắc Community OpenVPN vào các tệp được tạo; các quy tắc không được quản lý sẽ bị ghi đè hoặc xung đột ở lần cập nhật sản phẩm tiếp theo. sudo iptables -t nat -L -n -v hoặc tương đương nftables cho thấy điều gì thực sự đang được dịch.

Phía AWS là một đường riêng. Một phiên bản trong mạng con công cộng đến cổng internet trực tiếp và giữ địa chỉ công cộng hoặc IP đàn hồi của nó. Một phiên bản trong mạng con riêng cần tuyến đến cổng NAT hoặc phiên bản NAT, và thiết bị NAT cần tuyến riêng đến cổng internet. Gắn cổng internet vào VPC tự nó không cấp địa chỉ trả về công cộng cho bất kỳ nguồn riêng nào, đó là lý do cùng một thiết lập Access Server hoạt động trong một mạng con và thất bại âm thầm trong mạng khác.

Kiểm tra bảng tuyến gắn với mạng con của phiên bản, không chỉ bảng chính của VPC. Các liên kết mạng con lấn át bảng chính, và một liên kết cũ là nguyên nhân phổ biến khiến cấu hình đang hoạt động dừng sau khi xây dựng lại.

Giữ đường ra IP và DNS riêng biệt

Thử một địa chỉ nguyên văn trước, rồi đến tên, từ cùng một ứng dụng khách. Nếu curl -4 https://checkip.amazonaws.com trả về địa chỉ công cộng nhưng tên máy chủ thất bại, đường hầm và đường NAT vẫn hoạt động và vấn đề là DNS: bộ phân giải được đẩy xuống, trạng thái bộ phân giải của máy khách, hoặc một nhóm bảo mật chặn bộ phân giải. Cài đặt DNS của Access Server nằm trong cùng khu vực Internet Access, nhưng chúng đi theo một đường mã khác.

So sánh địa chỉ trả về với đường ra bạn dự định. Nếu đó là địa chỉ công cộng của phiên bản, lưu lượng đang được phiên bản dịch; nếu đó là địa chỉ cổng NAT, đường mạng con riêng đang được dùng. Cả hai đều có thể đúng. Điều bạn không thể kết luận là trình duyệt trên máy chủ chứng minh việc chuyển tiếp cho máy khách.

Đừng để một ô kiểm khép lại cuộc điều tra

IPv6 là một quyết định riêng. Chính sách đường hầm đầy đủ cho IPv4 không nói gì về việc IPv6 có được mang, bị chặn hay bị rò rỉ, và máy khách hai ngăn xếp có thể tiếp tục dùng đường IPv6 cục bộ trong khi IPv4 đi qua đường hầm. Hãy thử họ địa chỉ mà bạn thực sự quan tâm, và quyết định rõ ràng liệu cái còn lại có nên bị tắt.

Cuối cùng, hãy thử trạng thái ngắt kết nối. Lựa chọn đường hầm đầy đủ mô tả chính sách định tuyến khi đang kết nối, không phải điều gì xảy ra khi đường hầm sập. Nếu yêu cầu là không có lưu lượng nào thoát ra ngoài VPN, đó là câu hỏi về kill-switch và tường lửa, và nó cần bài kiểm tra riêng thay vì suy luận từ bảng tuyến.