DNS trên AWS Client VPN: dùng resolver của VPC, không phải subnet

Endpoint nằm trong 10.0.8.0/24, nên resolver phải là 10.0.8.2. Đây là lập luận tôi nghe nhiều nhất, và nó sai hai lần. Route 53 Resolver trả lời trên dải IPv4 chính của VPC cộng hai, mà với VPC 10.0.0.0/16 là 10.0.0.2, bất kể endpoint dùng subnet nào. Lỗi thứ hai kín đáo hơn: đặt địa chỉ đúng vào endpoint không có nghĩa hệ điều hành của máy khách sẽ hỏi nó bất cứ điều gì. Cả hai lỗi cho cùng một triệu chứng: phân giải tên chạy được với một số máy khách và thất bại với những máy khác.

Huyền thoại bắt đầu từ việc gắn subnet

Việc gắn liên quan đến nơi các giao diện mạng đàn hồi cho kết nối máy khách nằm, không phải địa chỉ resolver nào tồn tại. Các subnet của endpoint cho máy khách một địa chỉ bên trong VPC, và mỗi subnet không mang resolver riêng.

Khi tách hai ý đó ra, phép tính không còn bí ẩn và việc xử lý sự cố chuyển sang máy khách, nơi phần lớn các trường hợp này thực sự kết thúc.

Tính địa chỉ từ dải chính của VPC

Lấy CIDR IPv4 chính của VPC và cộng hai vào địa chỉ mạng. 10.0.0.0/16 cho 10.0.0.2, 172.31.0.0/16 cho 172.31.0.2, và VPC có dải phụ vẫn giữ resolver trên dải chính. Một subnet 10.0.8.0/24 bên trong VPC đó không làm nó dịch chuyển. Ghi địa chỉ bên cạnh VPC ID trước khi chạm vào endpoint, vì con số là thuộc tính của VPC chứ không phải của kết nối.

VPC cũng trả lời trên địa chỉ link-local 169.254.169.253. Địa chỉ đó truy cập được từ bên trong VPC, nhưng không phải đích được định tuyến thông thường cho laptop ở đầu bên kia của đường hầm.

Vậy có hai địa chỉ resolver hợp lệ, và không địa chỉ nào là subnet cộng hai.

Cấu hình endpoint làm gì và không làm gì

Endpoint Client VPN có các trường máy chủ DNS, và ở nơi bảng điều khiển đưa ra tùy chọn resolver của VPC thì nó điền cùng ý tưởng đó. Đặt chúng thay đổi điều dịch vụ trao cho máy khách khi thiết lập kết nối. Nó không thay đổi điều một máy khách OpenVPN không được quản lý làm với giá trị đó, vì máy khách vẫn phải áp dụng nó vào hệ điều hành. Khoảng trống đó chính là nguồn gốc của «chạy trên Mac của tôi nhưng không trên máy Linux».

Trên Linux, tích hợp resolver thuộc về trình quản lý kết nối chứ không phải người dùng. Sửa /etc/resolv.conf bằng tay chứng minh địa chỉ hoạt động cho một phiên rồi biến mất khi kết nối lại — đó là lý do nhiều trường hợp đã sửa quay lại vào sáng hôm sau.

Kiểm tra resolver đang hoạt động trên máy khách sau khi kết nối, không phải trang cấu hình của endpoint.

Split tunneling có thể vô hiệu hóa resolver đúng

Với split tunneling, chỉ các tuyến được đẩy vào đường hầm mới được dùng. Nếu địa chỉ resolver không được một tuyến nào bao phủ, truy vấn đi ra qua giao diện cục bộ và router ở nhà trả lời. Địa chỉ trong endpoint vẫn đúng và việc tra cứu vẫn thất bại. Thêm tuyến cho resolver, rồi thử lại.

Các dải cục bộ chồng lấn cho cùng kết quả theo cách khó chịu hơn: truy vấn được trả lời, chỉ là từ máy chủ sai.

Đừng mở security groups cho địa chỉ Amazon DNS

Bản năng khi việc tra cứu hết thời gian là thêm một quy tắc cho phép UDP 53 tới địa chỉ resolver. AWS ghi rõ rằng security groups và ACL mạng không lọc lưu lượng Amazon DNS như cách chúng lọc lưu lượng tới một instance DNS riêng. Mở những quy tắc đó không thay đổi gì cho resolver của VPC và mở rộng ranh giới mà không có lý do. Một resolver do bạn tự vận hành là trường hợp khác và thực sự cần quy tắc riêng.

Nếu cả hai cùng xuất hiện trong thiết kế của bạn, hãy kiểm tra máy khách thực sự trỏ tới cái nào trước khi sửa bất kỳ quy tắc nào.

Xác minh đường đi, rồi đo thứ khác

Phân giải một tên công khai, phân giải một tên riêng được đăng ký trong vùng lưu trữ riêng gắn với VPC, và đọc resolver đang hoạt động của máy khách ở giữa hai bước. Trình tự đó tách «địa chỉ resolver sai» khỏi «vùng chưa được gắn» và khỏi «máy khách bỏ qua cấu hình». Mỗi trường hợp có cách sửa khác nhau, và không trường hợp nào là vấn đề thông lượng.

Một lần tra cứu thành công không nói gì về tốc độ truyền tải duy trì, nên hãy tách hai cuộc trò chuyện đó khi báo cáo.