mDNS bên trong VPN: vì sao tên .local không phân giải được

Máy in văn phòng xuất hiện trong mọi ứng dụng trên bàn làm việc và biến mất trên VPN, dù bạn có thể ping địa chỉ mà bạn biết nó có. Không có gì trong đường hầm bị hỏng: khám phá và khả năng tiếp cận là hai dịch vụ riêng, và mặc định chỉ một trong hai đi qua đường hầm định tuyến. Các kiểm tra dưới đây tách hai thứ đó trước khi bạn bắt đầu thêm tuyến. Một tuyến không thể sửa truy vấn chưa bao giờ rời khỏi liên kết.

Kiểm tra cái gì phân giải được hôm nay và cái gì chỉ trông như đã phân giải

Trước hết hãy tách hai câu hỏi: truy vấn unicast cho tên máy hỏi bộ phân giải, còn tìm kiếm _ipp._tcp hỏi liên kết cục bộ. Trên Linux, avahi-browse -a cho thấy multicast DNS có thể thấy gì, và resolvectl query name.local cho thấy ngăn xếp phân giải làm gì với tên đó. Trên macOS, dns-sd -B _ipp._tcp liệt kê các dịch vụ được khám phá mà không cần địa chỉ trước.

Nếu địa chỉ trả lời còn tên thì không, định tuyến hoạt động và khám phá thì không. Tên .local cũng có thể được trả lời ngay trên máy qua nss-mdns mà không cần cài avahi-browse, nên getent hoặc ping thành công tới tên đó không phải bằng chứng rằng khám phá đã đi qua đường hầm; kết quả tìm kiếm và kết quả bộ phân giải là hai bằng chứng khác nhau. Ứng dụng lưu bộ nhớ đệm những gì đã khám phá, vì thế sự cố thường xuất hiện nhiều giờ sau khi kết nối chứ không phải lúc kết nối. Đóng và mở lại ứng dụng, rồi kiểm tra xem mục trong bộ nhớ đệm chứa tên hay địa chỉ, vì địa chỉ vẫn hoạt động rất lâu sau khi khám phá dừng lại.

Vì sao truy vấn không bao giờ đi qua đường hầm

Multicast DNS gửi truy vấn tới 224.0.0.251, bên trong khối điều khiển mạng cục bộ, trên cổng UDP 5353. Bộ định tuyến không chuyển tiếp địa chỉ từ khối đó, nên truy vấn ở lại trên liên kết mà nó được gửi tới. Bên gửi cũng đặt TTL IP, hoặc giới hạn bước nhảy IPv6, thành 255 để bên nhận có thể từ chối gói đã đi qua bộ định tuyến; đó là cách giao thức phát hiện giả mạo ngoài liên kết, không phải cách nó ở lại cục bộ. Tính cục bộ đến từ địa chỉ đích, không phải từ TTL một bước nhảy.

Loại đường hầm cũng quan trọng. Giao diện kiểu tun chỉ chuyển gói IP và không gì khác, nên không nhóm multicast nào sống sót qua nó. Cầu kiểu tap mở rộng chính miền quảng bá, vì thế một số thiết kế cũ dùng cầu thay vì định tuyến, và thừa hưởng mọi vấn đề mà cầu mang lại.

Ngoại lệ cho LAN tin cậy không thay đổi điều nào trong số này, vì nó quyết định lưu lượng nào được dùng đường hầm thay vì dạy đường hầm chuyển tiếp multicast. Gói vẫn không có phân đoạn chung nào để được nghe thấy.

Chọn thiết kế đặt tên bạn có thể duy trì

Với tài nguyên công ty, câu trả lời bền vững là một tên máy được định tuyến do bộ phân giải mà VPN đẩy xuống phục vụ, cùng với DNS tách để tên nội bộ đi tới máy chủ nội bộ và mọi thứ khác thì không. Windows hiển thị nó dưới dạng bảng chính sách phân giải tên, macOS dùng bộ phân giải theo phạm vi cho từng giao diện, và hầu hết máy khách có cài đặt đẩy tương đương. Thiết bị giữ tên thông thường trong DNS nội bộ, và khám phá không còn là một phần của đường đi.

Một proxy khám phá hoặc bộ phản xạ mDNS có thể bắc cầu khoảng trống này, và đó là một thiết kế thực sự với máy chủ, mức phơi bày và yêu cầu máy khách riêng. Nó không xuất hiện vì bạn đã thêm một tuyến. Đừng bao giờ chuyển tiếp truy vấn .local tới bộ phân giải công cộng: miền này được dành riêng cho multicast cục bộ theo RFC 6762, và gửi nó ra ngoài tạo ra lỗi chậm và tiết lộ dữ liệu không cần thiết.

Xác minh dịch vụ, không phải tên

Một tên trong danh sách tìm kiếm chứng minh bước khám phá, không chứng minh dịch vụ trả lời. Mở hàng đợi in hoặc giao diện web và hoàn thành một thao tác thực, rồi lặp lại sau khi kết nối lại.

Khám phá lưu tên vào bộ nhớ đệm một cách hung hăng, nên một mục cũ có thể trông như thành công. Nếu xuất hiện chứng chỉ hoặc lời nhắc xác thực, đó là lớp tiếp theo và một vấn đề riêng. Ghi lại cơ chế bạn đã thay đổi, bộ phân giải hay khám phá, để người tiếp theo không phải mở lại toàn bộ câu hỏi.