Tên máy chủ VPN thất bại, địa chỉ IP vẫn hoạt động: nên xem ở đâu

Bạn mở được thư mục chia sẻ bằng địa chỉ và cùng thư mục đó bằng tên thì thất bại, nghĩa là đường hầm vẫn chở gói tin còn tầng tên thì không. Một quan sát đó tiết kiệm một vòng đường vòng qua thay đổi tường lửa và tuyến đường. Tên cần một hậu tố, một trình phân giải và một đường dẫn cho truy vấn, và máy khách VPN có thể cài một tuyến đường mà không cài bất kỳ thứ nào trong số đó. Hãy đi qua bốn kiểm tra dưới đây theo thứ tự và dừng ở cái đầu tiên bị hỏng.

Tên đặt câu hỏi mà địa chỉ không đặt

Địa chỉ là đích mà ngăn xếp có thể dùng ngay. Tên ngắn là một câu hỏi phải được mở rộng bằng hậu tố, gửi đến trình phân giải và được trả lời bởi thứ gì đó biết vùng. Một đường hầm chỉ cài tuyến đường mà không cài trình phân giải sẽ để cái đầu chạy và cái sau hỏng. Đó là lý do triệu chứng trông rất nhất quán trên những sản phẩm VPN rất khác nhau.

Hãy làm việc từ địa chỉ ra ngoài: trước hết là tên đầy đủ, sau đó là tên máy chủ trần, và ghi lại cái nào trong ba cái hoạt động. Mẫu cho bạn biết nên kiểm tra tầng nào trước khi mở một màn hình cấu hình. Đoán tuyến đường khi FQDN phân giải được là công sức lãng phí.

Đọc trình phân giải mà đường hầm thực sự đã cài

Hỏi hệ điều hành trình phân giải nào xử lý truy vấn cho vùng nội bộ, không phải cái mà giao diện máy khách VPN quảng cáo. Một máy chủ đẩy trình phân giải công cộng không có vùng nội bộ tạo ra đúng thất bại này, và đó là lỗi cấu hình chứ không phải sự cố định tuyến.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Trên máy khách Windows đã gia nhập miền, chính sách định tuyến không gian tên quyết định truy vấn nào đi đến trình phân giải nào, và cài đặt DNS riêng của bộ điều hợp VPN xuất hiện trong chi tiết bộ điều hợp. Hãy đọc chính sách hiệu lực thay vì hồ sơ, vì chính sách đã lưu trong bộ nhớ đệm có thể sống lâu hơn kết nối đã cài nó. Nếu trình phân giải trả lời tên đầy đủ mà không trả lời tên ngắn, vấn đề đã chuyển sang danh sách hậu tố.

Get-DnsClientNrptPolicy
ipconfig /all

Dừng lại nếu vùng nội bộ phân giải được qua đúng máy chủ. Trình phân giải không phải vấn đề của bạn.

Hậu tố giải thích các tên ngắn thất bại

Tên một nhãn được mở rộng bằng danh sách hậu tố của kết nối trước khi truy vấn được gửi đi. Nếu VPN không cung cấp hậu tố nội bộ, fileserver không bao giờ trở thành fileserver.corp.example, và truy vấn đi ra như một cái tên mà không trình phân giải công cộng nào biết. Đẩy hậu tố, hoặc gõ tên đầy đủ, kiểm tra giả thuyết mà không thay đổi gì trên máy chủ.

nslookup fileserver.corp.example
ping -a 192.168.50.20

Trên Linux, dịch vụ phân giải gắn một máy chủ DNS với một liên kết và một tập hợp miền định tuyến, nên một máy chủ bị đẩy xuống không gắn với liên kết của đường hầm sẽ hành xử như thể nó không ở đó. Hãy kiểm tra trạng thái theo từng liên kết thay vì tệp stub, thứ có thể chỉ trỏ đến trình phân giải cục bộ. Cùng sự phân tách đó cũng xuất hiện ở chiều ngược lại: một miền tìm kiếm có mặt nhưng không được áp dụng cho giao diện đường hầm tạo ra lỗi tên ngắn trông có vẻ ngẫu nhiên.

Nếu thêm hậu tố khắc phục được, công việc còn lại là cung cấp hậu tố đó qua hồ sơ VPN thay vì yêu cầu mỗi người dùng tự gõ.

NetBIOS và WINS là một cơ chế khác

SMB cũ vẫn có thể tra cứu một tên trần bằng dịch vụ tên NetBIOS, dịch vụ này trả lời qua phát sóng hoặc qua một máy chủ WINS. Phát sóng ở lại trong một miền phát sóng và dừng ở bộ định tuyến đầu tiên, nên không thể vượt qua đường hầm; WINS hoạt động vì máy khách có một địa chỉ unicast để đăng ký và để hỏi. Đó là lý do một VPN chỉ chở IP vẫn có thể hỗ trợ tên cũ khi WINS được cấu hình và có thể truy cập.

nbtstat -n
nbtstat -R

Với SMB hiện đại, hãy dựa vào DNS và tên đầy đủ, và cho đường dẫn cũ nghỉ hưu. Nếu nó thực sự cũ, hãy cung cấp WINS hoặc thay thế ứng dụng; con đường giữa là một hàng đợi hỗ trợ không bao giờ trống.

Cuộc đi kết thúc khi bạn có thể nói tầng nào đã hỏng: trình phân giải, hậu tố hay khám phá cũ. Ghi lại trình phân giải đã trả lời và dạng tên đã hoạt động, vì người tiếp theo sẽ bắt đầu từ cùng triệu chứng.