DNS địa lý và anycast: kiểm tra điểm vào VPN bạn nhận được

Một câu trả lời DNS gần đó có vẻ như vấn đề đã được giải quyết cho đến khi kết nối hạ cánh ở nơi khác. DNS địa lý và anycast đều cố gắng rút ngắn đường đi, và chúng đưa ra quyết định đó từ những thông tin khác nhau. Không bên nào bảo đảm rằng cổng bạn đến được là có thể truy cập, rằng nó trình bày danh tính mà ứng dụng khách của bạn mong đợi, hoặc rằng phiên của bạn sống sót qua việc thay đổi nút. Các kiểm tra dưới đây tách bốn câu hỏi đó.

Kiểm tra xem trình phân giải thực sự báo cáo vị trí của ai

Máy chủ có thẩm quyền trả lời một truy vấn nhạy cảm với cấu trúc liên kết thường thấy địa chỉ của trình phân giải đệ quy đã hỏi, không phải địa chỉ của người đã nhập tên. Một trình phân giải tập trung có thể ở xa những khách hàng mà nó phục vụ, và câu trả lời phản ánh trình phân giải chứ không phải họ. Đó không phải là lỗi; giao thức hoạt động như vậy trừ khi có thông tin bổ sung được cung cấp. Đặc tả EDNS Client Subnet mô tả cả hạn chế và biện pháp khắc phục tùy chọn.

EDNS Client Subnet có thể mang thông tin mạng nguồn gốc khi mọi thành viên tham gia hỗ trợ và bật nó. Nó là tùy chọn, có hậu quả về quyền riêng tư và bộ nhớ đệm, và không phải là sự cho phép giả định rằng bất kỳ trình phân giải công cộng nào báo cáo vị trí người dùng chính xác. Hãy hỏi các nhà vận hành trình phân giải trước khi thiết kế xoay quanh nó.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Kiểm tra xem định tuyến anycast đã quyết định gì

Với anycast, nhiều vị trí quảng cáo khả năng tiếp cận cho một địa chỉ dịch vụ, và mạng đưa từng khách hàng đến nút mà định tuyến của họ ưu tiên. Lựa chọn đó do BGP và chính sách xung quanh thực hiện, không phải khoảng cách trên bản đồ. Sự gần gũi về cấu trúc liên kết cũng thường không đồng nghĩa với hiệu suất khứ hồi tốt hơn, vì đường đi trông ngắn có thể bị tắc nghẽn hoặc không đối xứng. Địa chỉ bạn nhận được không cho biết nút nào đã trả lời.

Xác nhận vị trí phục vụ từ phía dịch vụ, hoặc từ một phản hồi nêu tên nó, thay vì chỉ từ câu trả lời DNS. traceroute -n 198.51.100.20 hiển thị đường đi bạn đã đi và vẫn không nêu tên máy chủ ở cuối đường, vì vậy hãy đọc nó như một đường đi chứ không phải câu trả lời.

Kiểm tra xem phiên có sống sót qua việc thay đổi nút

Truy vấn DNS ngắn và phiên VPN dài, và hai bên có yêu cầu trạng thái hoàn toàn khác nhau. Định tuyến có thể dịch chuyển giữa phiên, và khi điều đó xảy ra, các gói sau có thể đến một nút chưa bao giờ thấy đường hầm của bạn. Việc đó có thể sống sót hay không phụ thuộc vào cách triển khai: trạng thái chia sẻ, kết nối lại có chủ đích, hoặc lỗi được ghi nhận. Chỉ địa chỉ thì không cung cấp điều nào trong số đó.

Hãy quan sát sự dịch chuyển thay vì giả định nó. sudo tcpdump -ni any -c 20 esp hiển thị các gói bên ngoài khi đường đi thay đổi, và sự thay đổi đột ngột ở địa chỉ đối tác chính là sự dịch chuyển đang diễn ra. Định nghĩa rõ ràng hành vi dự định cho cách triển khai bạn vận hành, sau đó kiểm tra bằng cách buộc thay đổi đường đi. Nếu thiết kế giả định sao chép phiên, hãy nêu tên cơ chế và nêu tên lỗi mà nó không bao phủ.

Kiểm tra xem danh tính còn khớp không

Mỗi điểm vào phải trình bày danh tính mà hồ sơ khách hàng của bạn mong đợi. Chứng chỉ được cấp cho tên dịch vụ hoạt động trên các nút, trong khi chứng chỉ theo từng nút buộc khách hàng phải chấp nhận thứ mới, và đó là nơi người dùng học cách bấm qua các cảnh báo. Giữ danh tính dự kiến và hồ sơ nhất quán với mô hình đầu vào.

Kiểm tra điều đó từ một khách hàng đã đến một nút bất thường, vì đó là trường hợp chứng chỉ theo nút trở nên hiển thị. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com in chuỗi và các tên, chính xác là điều khách hàng so sánh. Sau đó quyết định xem nên thu hẹp hồ sơ hay thay đổi mô hình chứng chỉ.

Kiểm tra hồ sơ, không chỉ câu trả lời đầu tiên

Đánh giá ba tình huống và viết bốn sự kiện cho mỗi tình huống: đầu vào bình thường, một vị trí không khả dụng và trường hợp phục hồi đã thống nhất. Bốn sự kiện là trình phân giải được dùng, địa chỉ được trả về, vị trí đã phục vụ và kết quả ứng dụng mới. Hồ sơ đó tách vấn đề chọn DNS khỏi vấn đề cổng, vấn đề định tuyến hoặc vấn đề trạng thái phiên. Không có nó, cả bốn trông giống nhau từ phía khách hàng.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Chạy các tình huống từ những mạng truy cập đại diện chứ không chỉ từ văn phòng, vì toàn bộ câu hỏi là điểm vào nào mà các khách hàng khác nhau thực sự đến được. Một mạng là một mẫu của một.