Truy cập chập chờn trên AWS Client VPN: rà soát từng subnet được liên kết

Một người dùng kết nối, mở ứng dụng nội bộ và nhận được phản hồi; đồng nghiệp trên cùng điểm cuối lại bị quá thời gian từ một laptop giống hệt trên cùng mạng Wi-Fi. Mẫu này là dấu hiệu của một điểm cuối client VPN có nhiều hơn một subnet được liên kết, nơi các đường đi không tương đương. Tôi lần theo việc này từ bảng điều khiển ra ngoài, vì hai thẻ quyết định phần còn lại của cuộc điều tra có đáng làm hay không. Không có gì trong cấu hình máy khách giải thích điều đó.

Bắt đầu từ điểm cuối và liệt kê các liên kết

Trong bảng điều khiển VPC, mở Client VPN endpoints, chọn điểm cuối và đọc thẻ Associations. Mỗi liên kết là một subnet trong vùng sẵn sàng, và máy khách rơi vào subnet mà dịch vụ chọn khi kết nối được thiết lập. Ghi lại ID subnet và bảng tuyến mà mỗi subnet thực sự dùng, vì hai danh sách đó chính là phép so sánh bạn sắp làm.

Nếu điểm cuối chỉ hiển thị một liên kết, giả thuyết này sai và máy khách là nghi phạm tốt hơn.

So sánh bảng tuyến của điểm cuối với từng liên kết

Mở thẻ Route table trên cùng điểm cuối. Mỗi CIDR đích ở đó có một mục tiêu, và với client VPN mục tiêu là một liên kết chứ không phải cổng. AWS yêu cầu một mục đích cho mỗi subnet được liên kết, nên một tuyến chỉ nhắm tới một trong số đó khiến việc truy cập phụ thuộc vào nơi phiên đã rơi xuống. Hãy kiểm tra đích bạn thực sự quan tâm, rồi kiểm tra quy tắc cấp quyền của nó, vì tuyến cung cấp đường đi còn quy tắc quyết định ai được dùng.

Khi bạn lập bảng cả hai lớp, rất khó bỏ sót lỗi.

Hàng thứ hai chính là toàn bộ lỗi trong phần lớn phiếu yêu cầu. Tuyến của điểm cuối có đó, nên không ai nhìn xa hơn, và gói tin chết một bước nhảy sau đó bên trong VPC.

Theo từng subnet vào bảng tuyến hiệu lực của nó

Một subnet không có liên kết rõ ràng với bảng tuyến sẽ thừa hưởng bảng chính của VPC. Hãy đọc bảng thực sự có hiệu lực, không phải bảng có tên trông đúng, và so sánh đích với mục tiêu thay vì nhãn trên hàng.

Hướng dẫn của AWS về truy cập chập chờn mô tả điều này như độ phủ tuyến trên các liên kết, và đó là mô hình đúng. Điểm cuối đưa gói tin tới một subnet, và bảng của subnet đó vẫn phải biết mạng ứng dụng nằm ở đâu.

Sửa hàng còn thiếu trong bảng sở hữu nó. Sao chép toàn bộ bảng tuyến từ một subnet đang hoạt động cũng sao chép các lựa chọn internet, thiết bị và cách ly vốn không hề dành cho subnet này, và sự đánh đổi đó thường tệ hơn sự cố bạn bắt đầu.

Kiểm tra quy tắc cấp quyền, rồi đến đường quay về

Quy tắc cấp quyền tính theo đích và theo nhóm, và được đánh giá tách biệt với tuyến. Một đích có tuyến khắp nơi nhưng không có quy tắc cho nhóm của người dùng sẽ hành xử như một hố đen với bảng tuyến trông vẫn khỏe.

Đường quay về cũng đáng được chú ý như vậy. Một kết nối peering cần tuyến trong VPC ứng dụng trỏ ngược về CIDR của máy khách, quy tắc nhóm bảo mật cho phép lưu lượng ở cả hai đầu, và ACL mạng không bỏ rơi nó. Khả năng tiếp cận một chiều, khi ping chạy được mà bắt tay TCP thì không, thường chỉ về một ACL hoặc nhóm bảo mật chứ không phải VPN.

Các nhóm bảo mật của chính điểm cuối nằm trên giao diện mạng đàn hồi của liên kết, nên một quy tắc cho phép cổng ứng dụng từ CIDR của máy khách phải được gắn vào liên kết, không chỉ vào phiên bản.

Xác minh bằng cách kết nối lại, không phải bằng một yêu cầu may mắn

Với split tunnel, tuyến của điểm cuối được đẩy xuống khi kết nối được thiết lập, nên một tập tuyến đã thay đổi không bao giờ đến được máy khách còn duy trì kết nối. Ngắt và kết nối lại qua máy khách được hỗ trợ, rồi xác nhận rằng các tuyến mới có trên máy.

Cuối cùng, đối chiếu nhật ký kết nối với địa chỉ mà máy khách nhận được, và lặp lại bài kiểm tra đủ nhiều để chạm vào nhiều hơn một liên kết. Một yêu cầu thành công sau khi sửa chỉ chứng minh một đường đi hoạt động, còn phiếu yêu cầu là về đường còn lại.