DNS của điểm cuối AWS Client VPN: vì sao ghim IP đã phân giải lại thất bại

Tuần trước, dig +short đã cho bạn một địa chỉ cho tên điểm cuối trong hồ sơ AWS Client VPN của bạn, và đường hầm đã kết nối. Tuần này, cùng hồ sơ đó đứng ở 'Connecting' trên máy tính xách tay của bạn trong khi bản sao chưa bị động đến của đồng nghiệp vẫn hoạt động. Không có gì bị chặn và chứng chỉ không hết hạn. Ai đó đã thay tên máy chủ của điểm cuối bằng địa chỉ đã phân giải đó, và dịch vụ không còn phản hồi ở đó nữa. Tên được xuất là phần được xây dựng để chịu được thay đổi đó.

Tên trong hồ sơ của bạn có thể không phải tên được truy vấn

Các hồ sơ xuất từ Client VPN thường mang remote-random-hostname. Khi bật tùy chọn đó, ứng dụng khách tạo một nhãn dùng một lần, ghép nó với tên điểm cuối bằng dấu chấm và phân giải tên kết hợp. Một bản ghi wildcard trong vùng của điểm cuối trả lời mọi nhãn, đó là lý do một tiền tố bịa ra vẫn phân giải được và đó là lý do thủ thuật này vẫn vô hình khi bạn cố tái tạo truy vấn bằng tay.

Vì vậy khi bạn dán tên điểm cuối vào terminal và nhận được câu trả lời, bạn đã phân giải một tên khác với tên ứng dụng khách dùng khi kết nối. Sự khác biệt đó không phải lỗi cần sửa trong hồ sơ. Nhãn được tạo lại có chủ đích: tùy chọn này ngăn bộ nhớ đệm giữ câu trả lời cũ, và nó không bao giờ nhận dạng máy hay phiên của bạn.

Tôi đã gặp trường hợp tương thích khi ứng dụng khách phớt lờ hoàn toàn tùy chọn đó. AWS ghi lại cách khắc phục: giữ tên điểm cuối thật và thêm phía trước một chuỗi ngẫu nhiên cùng dấu chấm, coi đó là mẫu đặt tên chứ không phải giá trị để dán. Áp dụng điều đó cho ứng dụng khách cũ là hợp lý; mã hóa cứng chuỗi có tiền tố làm điểm cuối thì không.

Vì sao một câu trả lời đã lưu không thể tiếp tục đúng

Địa chỉ của điểm cuối Client VPN do AWS quản lý và thay đổi theo thời gian, điều mà tài liệu thực hành tốt nhất nói thẳng. Câu trả lời bắt được chỉ là ảnh chụp của một lần phân giải. Một hồ sơ mã hóa cứng nó sẽ trở thành hồ sơ nhắm vào một máy chủ đã ngừng hoạt động ngay khi dịch vụ di chuyển, và lỗi hiếm khi trông giống DNS: bạn nhận được hết thời gian kết nối hoặc bắt tay bị treo, nên mọi người chạy theo định tuyến và chứng chỉ.

Cùng câu trả lời trong /etc/hosts thừa hưởng cùng thời hạn với một vấn đề thêm. Mục hosts sống sót qua khởi động lại, xuất lại và các sửa lỗi 'cài lại ứng dụng khách', nên lỗi quay lại mỗi khi địa chỉ di chuyển. Tôi từng thấy một mục nằm vô hại nhiều tuần, rồi làm hỏng mọi máy mang nó trong khi các bản cài mới vẫn kết nối bình thường. Sự phân chia đó, một nhóm hỏng còn nhóm khác ổn trên cùng một tài khoản, là manh mối rẻ nhất bạn sẽ có.

Giới hạn đúng phạm vi ngẫu nhiên hóa. Nó xảy ra theo từng lần thử kết nối. Một đường hầm đã thiết lập không phân giải lại điểm cuối của nó, không đổi máy chủ giữa phiên, và các yêu cầu riêng lẻ của ứng dụng không mỗi cái chọn một máy chủ VPN mới. Chỉ lần thử tiếp theo mới phân giải lại, nên một phiên chạy cả buổi chiều không nói gì về sáng mai.

Dịch vụ kiểm tra gì khi đường hầm được dựng lên

Client VPN yêu cầu địa chỉ bạn đang kết nối phải khớp với một địa chỉ đã phân giải cho tên DNS của điểm cuối. Chỉ yêu cầu đó giải thích vài lỗi trông không liên quan: bản ghi DNS tùy chỉnh trỏ nơi khác, một frontend tùy chỉnh chuyển tiếp đến địa chỉ điểm cuối thật, và một hồ sơ bị viết lại sang địa chỉ thô. AWS ghi lại cách bố trí bản ghi tùy chỉnh cộng chuyển tiếp là lỗi với các ứng dụng khách mới do AWS cung cấp. Việc kiểm tra hẹp; đó không phải phán quyết rằng mọi bí danh đều bị cấm.

Đây cũng không phải quy tắc chung về giao thức VPN. remote dạng số hoàn toàn hợp lệ trong một triển khai OpenVPN thông thường, và nhiều nơi chạy như vậy. Ràng buộc đến từ cách bố trí được quản lý, không phải từ giao thức bên dưới.

Điều đó khiến việc nới lỏng xác minh chứng chỉ thành phản xạ sai. Nếu một hồ sơ hỏng sau khi đổi địa chỉ, tắt xác minh máy chủ sẽ di chuyển lỗi thay vì sửa phân giải hoặc yêu cầu khớp địa chỉ, và để lại một ứng dụng khách sẽ tin mọi thứ. Giữ nguyên CA đã xuất, xác minh máy chủ và cài đặt xác thực lẫn nhau đúng như khi nhận được.

Danh sách cho phép, lưu lượng ra và DNS riêng là ba vấn đề riêng biệt

Một quy tắc tường lửa phải cho phép một đích trước khi máy tính xách tay kết nối liên quan đến trình lắng nghe bên ngoài. Cho chủ mạng biết tên điểm cuối, giao vận và cổng đã cấu hình, rồi hỏi liệu kiểm soát của họ có theo được hành vi DNS của dịch vụ hay không. Một quy tắc giữ một địa chỉ bắt được là ảnh chụp với thời hạn không được ghi. Nếu kiểm soát chỉ chấp nhận các đích bất biến, hãy giải quyết khoảng trống đó trước khi triển khai thay vì lặng lẽ mã hóa cứng câu trả lời.

Một đối tác cần địa chỉ nguồn cố định cho các yêu cầu sau khi đường hầm lên có yêu cầu khác: lưu lượng ra. Điều một trang web thấy phụ thuộc vào tuyến ứng dụng và chính sách tách đường hầm, không phụ thuộc vào địa chỉ mà ứng dụng khách đã kết nối. Lưu lượng tách đường hầm có thể không bao giờ chạm tới AWS.

DNS riêng bên trong đường hầm là lớp thứ ba. Bộ phân giải cấp cho ứng dụng khách trả lời các tên nội bộ sau khi kết nối; nó không thể phân giải điểm cuối công khai trước khi đường hầm tồn tại. Lỗi phân giải điểm cuối và lỗi phân giải ứng dụng nội bộ xảy ra ở các giai đoạn khác nhau, và trộn chúng sẽ đưa bạn đến nhật ký sai.

Họ địa chỉ cũng nằm trong cùng danh sách. Câu trả lời IPv4 không nói gì về đường đi được phép của một điểm cuối IPv6 hoặc hai ngăn xếp, nên ảnh chụp chụp trong một họ không phải bằng chứng cho họ kia.

Kiểm tra một kết nối mà không ghim bất cứ thứ gì

Bắt đầu từ hồ sơ như khi được xuất và đọc xem nó thực sự yêu cầu gì:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Sau đó so sánh ba thứ: tên điểm cuối mà hồ sơ giữ, địa chỉ mà ứng dụng khách báo cho lần thử mới, và tên hiện phân giải thành gì. Một tên phân giải được chỉ chứng minh bản ghi trả lời; giao vận và xác thực tách biệt, và điểm cuối không cần trả lời ping. Nhật ký của chính ứng dụng khách là nguồn duy nhất cho mục giữa, nên hãy ghi lại trong lúc thử chứ không phải sau đó.

Một địa chỉ trả lời hôm nay là bằng chứng về hôm nay; tên là thứ dịch vụ giữ hợp lệ. Ghi lại quan sát, gửi cho người sở hữu điểm cuối, và để hồ sơ trỏ vào tên.

Hai thói quen nên bỏ: tắt kiểm tra chứng chỉ để vượt qua bắt tay bị treo, và chồng nhãn trước tên điểm cuối với hy vọng một cái sẽ dính. Nhãn được phân giải qua bản ghi wildcard hoặc vấn đề ở chỗ khác. Nếu hồ sơ được cấu hình đúng vẫn hỏng, hãy gửi truy vấn chính xác và sự kiện kết nối, không phải tên máy chủ dài hơn.

Trước khi đóng lại: hồ sơ vẫn mang tên điểm cuối đã xuất, không tệp hosts nào ghim địa chỉ, remote trong nhật ký ứng dụng khách khớp với phân giải hiện tại, và quy tắc tường lửa nêu tên điểm cuối thay vì một địa chỉ. Đó cũng là trạng thái cần bàn giao cho người tiếp theo.