AWS Client VPN đã kết nối nhưng không có internet: kiểm tra tuyến

AWS Client VPN đã kết nối nhưng không vào được internet? Hãy kiểm tra tuyến của máy khách, quyền của endpoint, lối ra của subnet và DNS theo đúng thứ tự đó.

Bạn đã kết nối tới endpoint của AWS Client VPN, subnet riêng trả lời, nhưng mọi trang công khai vẫn hết thời gian chờ. Sự kết hợp đó thu hẹp vấn đề vào một trong ba đối tượng ở phía được quản lý: tuyến mà máy khách cài đặt, tuyến của endpoint cùng quy tắc cấp quyền của nó, hoặc bước nhảy tiếp theo của subnet liên kết. Tôi kiểm tra theo thứ tự đó vì mỗi lỗi trông khác nhau từ phía máy khách. Hướng dẫn này nói về endpoint được quản lý gắn với VPC, không phải máy chủ OpenVPN trên một instance EC2 và không phải kết nối Cloud WAN hay Transit Gateway.

Bắt đầu từ điều máy khách thực sự định tuyến

Trạng thái đã kết nối chỉ chứng minh phiên TLS và việc cấp CIDR cho máy khách, không hơn gì nữa. Hỏi hệ điều hành xem một địa chỉ công khai sẽ đi đâu khi đường hầm đang bật. Trên Linux, ip route get 1.1.1.1 phải nêu tên giao diện đường hầm; trên macOS, netstat -rn -f inet | head -5 hiển thị mục mặc định; trên Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 in ra giao diện được chọn và bước nhảy tiếp theo.

Tiếp theo hãy đọc cờ split-tunnel, vì nó quyết định các tuyến do endpoint công bố có phải là những đích duy nhất mà máy khách gửi vào đường hầm:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

Khi SplitTunnel là true, một đích công khai chỉ dùng đường hầm khi endpoint công bố tuyến bao phủ nó, nên một 0.0.0.0/0 thiếu sẽ để lưu lượng đó trên giao diện cục bộ. Khi là false, máy khách bắt lấy lưu lượng, nhưng endpoint vẫn phải định tuyến và cấp quyền; nếu không, gói tin đi vào đường hầm và dừng ở đó. Hãy kết nối lại máy khách sau khi đổi một trong hai thiết lập, vì tuyến và máy chủ DNS được cấp tại thời điểm kết nối và máy khách đang chạy có thể giữ bộ cũ.

Đọc riêng tuyến của endpoint và quy tắc cấp quyền

Đây là hai đối tượng, và tạo cái này không tạo ra cái kia. Liệt kê các tuyến của endpoint và tìm tuyến mặc định có đích là subnet liên kết:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Mỗi tuyến có đúng một subnet đích, nên ba liên kết cần một tuyến mặc định tương ứng cho từng cái. AWS ghi lại yêu cầu phủ này, và triệu chứng thực tế của một khoảng trống là người dùng làm việc từ subnet này mà bị kẹt từ subnet khác, điều được đọc như lỗi gián đoạn chứ không phải thiếu tuyến. Tài liệu kịch bản Client VPN chính thức mô tả cách bố trí subnet công khai mà các tuyến này thuộc về.

Cấp quyền là đối tượng thứ hai. Khi không quy tắc nào phủ đích công khai, đường hầm vẫn mang gói tin và dịch vụ loại bỏ nó, nên tài nguyên riêng vẫn hoạt động trong khi internet thì không:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Một quy tắc cho CIDR của VPC không nói gì về 0.0.0.0/0. Thêm những phần còn thiếu cho đường hầm đầy đủ nghĩa là một tuyến cho mỗi subnet liên kết cộng một quy tắc cấp quyền mà bạn có thể kiểm toán sau này:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all cấp đích cho mọi máy khách của endpoint, nên chỉ giữ nó trong lúc đường hầm phải đầy đủ; quy tắc gắn với một nhóm thư mục là lựa chọn tốt hơn khi bạn có nhóm để gắn.

Theo gói tin ra khỏi subnet liên kết

Tuyến của endpoint quyết định rằng AWS giao gói tin cho subnet đó. Nó không quyết định bước nhảy tiếp theo sau đó, bước này sống trong bảng tuyến VPC của chính subnet:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

Một tuyến mặc định dùng được trỏ tới internet gateway với subnet công khai, hoặc tới NAT gateway với subnet riêng, và trạng thái blackhole nghĩa là đích đã bị xóa và đường đi giờ chết trong im lặng. Đây là những bảng khác với danh sách tuyến của endpoint, và sửa cái này không sửa cái kia.

Bước nhảy này có hai bộ lọc. Nhóm bảo mật áp lên liên kết mạng đích phải cho phép lưu lượng ra tới đích công khai, và mọi ACL mạng áp dụng được phải cho phép yêu cầu cùng lưu lượng quay về trên cổng tạm thời. Nhóm bảo mật liên kết quá chặt là nguyên nhân phổ biến khiến truy cập riêng chạy được còn truy cập công khai thì không.

Chọn lớp đầu tiên theo triệu chứng thay vì đổi cả ba cùng lúc:

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

Tách lỗi DNS khỏi một tuyến đã chết

Phân giải tên hỏng khác với chuyển tiếp, và đường hầm đầy đủ làm cho khác biệt đó quan trọng vì giờ trình phân giải được đẩy tới thông qua đường hầm. Nếu endpoint chỉ định máy chủ DNS của VPC, địa chỉ của chúng cần được phủ tuyến và cấp quyền như mọi đích khác. Hỏi trực tiếp trình phân giải để xem bạn gặp lỗi nào: dig +short example.com @10.0.0.2, hoặc nslookup example.com 10.0.0.2 trên Windows.

Khi URL dạng số trả lời mà URL có tên thì không, hãy ngừng sửa tuyến mặc định và làm việc với DNS. Yêu cầu tới một địa chỉ IP không chứng minh gì về một host ảo có tên và chứng chỉ của nó, nên hãy giữ một bài kiểm tra có tên ở bước kiểm tra cuối.

Thời gian giúp ích. Một kết nối TCP không nhận phản hồi trong vài giây chỉ về định tuyến hoặc một bộ lọc, còn yêu cầu treo trong lúc tra tên chỉ về trình phân giải. Đổi tuyến mặc định khi trình phân giải không tới được thường biến một lỗi thành hai.

Hoàn tác gọn gàng, rồi kiểm tra đường ra

Cả hai đối tượng đều là phép thêm, nên hoàn tác là xóa chứ không phải sửa:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

Kết nối lại và xác nhận lưu lượng ra theo đường nào. So sánh địa chỉ công khai quan sát được với địa chỉ IP đàn hồi của NAT gateway, hoặc với internet gateway mà bạn định dùng, và kiểm tra rằng một tài nguyên riêng vẫn trả lời trong cùng phiên.

Kết thúc bằng một danh sách ngắn, và coi mục cuối là phần của thay đổi chứ không phải tài liệu:

  • Một 0.0.0.0/0 tuyến của endpoint cho mỗi subnet liên kết.
  • Một quy tắc cấp quyền phủ 0.0.0.0/0 cho những máy khách bạn muốn phục vụ.
  • Một tuyến mặc định của VPC không ở trạng thái blackhole trên mỗi subnet liên kết.
  • Lưu lượng ra của nhóm bảo mật liên kết, cộng lưu lượng quay về của ACL.
  • Địa chỉ trình phân giải đã được định tuyến và cấp quyền, xác minh bằng yêu cầu có tên.
  • Một bản hoàn tác được ghi lại cho tuyến và quy tắc.

Một lưu ý về phạm vi: đây là đường IPv4. Máy khách hai ngăn xếp giữ kết nối IPv6 mà nó đã có, nên tuyến mặc định IPv6 là quyết định riêng với quyền riêng của nó chứ không phải tác dụng phụ của tuyến này.

Bài viết liên quan