DNS của VPN hoạt động nhưng tên .local vẫn thất bại: ai phân giải chúng?

Hai máy trên cùng một VPN, cùng tên máy chủ, và chỉ một máy phân giải được nó: khác biệt thường không phải đường hầm mà là bộ phân giải nào đã trả lời. Trên máy để bàn Linux, tên đó có thể đi qua công tắc dịch vụ tên, qua stub của systemd-resolved hoặc qua một bộ phân giải do ứng dụng mang theo, và mỗi bộ đều áp dụng quy tắc riêng cho cùng một hậu tố. Chính ở hậu tố các quy tắc mới khác nhau, vì .local không phải nhãn trung lập. Hãy tìm ra chương trình đang lỗi thực sự đi theo đường nào trước khi thay đổi thứ tự mà bất cứ thứ gì chạy.

Hai bộ phân giải, hai câu trả lời khác nhau

Tra cứu glibc truyền thống đi qua dòng hosts: trong nsswitch.conf và hỏi từng mô-đun lần lượt cho đến khi một cái trả lời. Máy khách nói chuyện với systemd-resolved qua trình lắng nghe stub lại hỏi một tiến trình duy nhất, và tiến trình đó áp dụng chính sách theo từng liên kết cùng các trường hợp đặc biệt của riêng nó. Ứng dụng mang theo bộ phân giải riêng, hoặc liên kết một thư viện làm điều đó, có thể bỏ qua cả hai. Vì vậy một tên máy chủ có thể có ba chủ sở hữu trên một máy, và chỉ một trong số họ biết VPN định làm gì.

Xác định chủ sở hữu trước khi thay đổi bất cứ điều gì, vì cách sửa khác nhau cho từng người trong ba. Trình duyệt và công cụ dòng lệnh trên cùng một máy để bàn có thể bất đồng một cách chính đáng, và sự bất đồng đó là manh mối chứ không phải lỗi. Nếu trình duyệt phân giải được tên mà công cụ thì không, bạn đang gỡ lỗi đường đi của bộ phân giải chứ không phải tuyến VPN. Xác nhận tuyến riêng, để lỗi định tuyến không bị nhầm với lỗi dịch vụ tên. Khi cả hai đồng ý, lỗi nằm phía trên máy chủ và cấu hình bộ phân giải ở đây không đáng để sửa thêm lần nữa.

Lệnh nào thực sự đã hỏi bộ phân giải của bạn

Hai lệnh chỉ đọc trả lời những câu hỏi liên quan, và so sánh chúng định vị vấn đề nhanh hơn đọc cấu hình. Dùng một tên nội bộ thật và giữ đầu ra riêng tư, vì bản ghi nội bộ vẫn là nội bộ. Chạy cả hai trong cùng phiên mà chương trình đang lỗi chạy:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Cái đầu hỏi qua các mô-đun đã cấu hình, đó là điều một chương trình điển hình trải nghiệm. Cái thứ hai hỏi trực tiếp systemd-resolved và báo cáo liên kết, giao thức và máy chủ đã trả lời. Hỏi máy chủ của công ty bằng địa chỉ chỉ chứng minh máy chủ có bản ghi, vì nó không nói gì về việc ứng dụng có bao giờ hỏi hay không. Đọc liên kết mang VPN và các miền mà nó tuyên bố, rồi so sánh danh sách đó với hậu tố trong tên đang lỗi.

Vì sao .local bỏ qua vùng unicast của bạn

tài liệu tham chiếu của systemd-resolved nêu rằng các tên nhiều nhãn kết thúc bằng .local thường đi đến DNS multicast khi mDNS được bật, thay vì DNS unicast thông thường. RFC 6762 dành riêng không gian tên đó cho multicast liên kết cục bộ, nên một vùng doanh nghiệp có thể có bản ghi đúng mà không bao giờ được hỏi cho hậu tố đó. Đường hầm có thể định tuyến bộ phân giải hoàn hảo mà vẫn thua cuộc đua. Một ping thành công từ bộ nhớ đệm không nói gì về lần tra cứu vừa xảy ra.

Có một ngoại lệ được ghi nhận, và nó giải quyết phần lớn các trường hợp này: khi một liên kết khai báo hậu tố đó là miền tìm kiếm hoặc miền định tuyến, tiến trình nền giữ nó trên đường unicast và bỏ qua trường hợp đặc biệt multicast. Đó là chính sách theo từng liên kết chứ không phải ưu tiên toàn cục. Hai máy có cùng máy chủ VPN có thể hành xử khác nhau khi một hồ sơ mạng khai báo miền còn hồ sơ kia thì không, vì vậy hãy đọc hồ sơ đang hoạt động chứ không phải hồ sơ bạn nhớ là đã sửa.

Ngoại lệ hẹp đánh bại việc sắp xếp lại toàn cục

Với một vùng đã tồn tại mà bạn không thể đổi tên, hãy để chủ sở hữu bộ phân giải và VPN khai báo miền trên kết nối mang nó. Một mục miền định tuyến cho đúng hậu tố đó cộng địa chỉ máy chủ dự định là thay đổi nhỏ với chủ sở hữu được nêu tên, và nó sống cùng liên kết thay vì trong một tệp được sửa bằng tay.

Nó cũng tồn tại qua lần ngắt kết nối, vì chính sách liên kết được áp dụng lại khi liên kết quay trở lại. Sửa nsswitch.conf dùng chung là phương án hấp dẫn và đắt hơn, vì nó thay đổi hành vi tra cứu cho mọi tên trên máy, kể cả khám phá cục bộ. Tắt tiến trình nền multicast cũng không tương đương: nó loại bỏ hành vi cục bộ mà không dạy cho bộ phân giải nào về vùng doanh nghiệp. Nếu dịch vụ là mới chứ không kế thừa, hãy đặt nó dưới một miền con do tổ chức bạn kiểm soát và bỏ qua hoàn toàn cuộc cạnh tranh. Chọn ngoại lệ hẹp khi tên được cố định trong phần sụn hoặc in trên nhãn, và chọn miền con mới khi bạn vẫn kiểm soát máy khách.

Cần chứng minh gì sau thay đổi

Chứng minh bản sửa bằng chính tra cứu của ứng dụng chứ không phải công cụ bạn cài để thử, và xóa mọi bộ nhớ đệm có thể trả lời thay nó. Sau đó xác nhận đường đi của bộ phân giải và liên kết đã trả lời. Cuối cùng kiểm tra rằng khám phá cục bộ vẫn hành xử như trước thay đổi, vì máy in ngừng xuất hiện là phần mà mọi người nhận ra sau cùng. Ba lệnh này kiểm tra tên, đường đi và danh tính TLS theo đúng thứ tự đó:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Địa chỉ đúng với chứng chỉ sai vẫn khiến máy khách nghiêm ngặt thất bại, vì vậy hãy kiểm tra tên mà ứng dụng mong đợi khi phân giải hoạt động. Xác nhận dịch vụ chấp nhận kết nối từ địa chỉ VPN chứ không chỉ từ dải văn phòng. Ghi phạm vi miền, máy chủ và chủ sở hữu vào tài liệu của kết nối. Nếu không, người tiếp theo gặp lỗi này sẽ chọn đúng bản sửa toàn cục mà bạn vừa tránh.