Mount CIFS của bạn hỏng qua VPN vì thứ tự trong nsswitch

Đường hầm đã lên. Máy chủ tệp trả lời ping bằng địa chỉ. Sau đó mount.cifs với tên máy chủ ngồi đó một lúc và báo rằng không thể tới máy chủ, và bạn bắt đầu dựng lại một hồ sơ VPN vốn không bao giờ là vấn đề. Trên Linux, cái tên được glibc phân giải trước khi bất kỳ gói SMB nào tồn tại, và thứ tự trong bộ phân giải đó có thể kết thúc việc tra cứu trước khi DNS được hỏi. Đây là cách tôi đi, bắt đầu từ lệnh đã hỏng chứ không từ máy khách.

Đọc lỗi ở đúng chỗ

Hai công cụ đi những đường khác nhau tới cùng một tên, và so sánh chúng chỉ tốn một lệnh. getent đi qua chồng dịch vụ tên đã cấu hình; host và dig hỏi DNS trực tiếp và bỏ qua chồng đó. Nếu truy vấn trực tiếp trả về một địa chỉ còn getent không trả về gì, máy chủ DNS vẫn tới được và cấu hình bộ phân giải của bạn là thứ hỏng.

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

Lệnh thứ ba là trọng tài: nó buộc nguồn DNS và bỏ qua phần còn lại của chồng. Khi nó chạy mà getent thường thì không, bạn đã chứng minh lỗi nằm ở thứ tự, không ở đường hầm và không ở máy chủ.

Dòng hosts là một chuỗi dừng sớm

Bộ phân giải glibc đọc /etc/nsswitch.conf và đi qua mục hosts: từ trái sang phải. Nhiều bản phân phối gửi một dòng trong đó việc tra cứu multicast đứng trước kèm một hành động trả về sớm. Hành động đó không phải trang trí: khi mDNS trả lời “not found”, [NOTFOUND=return] kết thúc toàn bộ việc tra cứu, nên tên công ty không bao giờ được gửi tới bộ phân giải mà VPN đẩy vào. Không gì ghi lại điều đó, vì không có truy vấn nào được gửi để bộ phân giải từ chối. Đó là lý do mount có vẻ treo rồi báo không tới được máy chủ.

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

Hãy đưa DNS lên trước hành động trả về sớm thay vì xóa mDNS, và thay đổi nó qua quản lý cấu hình. Một chỉnh sửa tay sống được tới lần dựng image tiếp theo, rồi cùng phiếu đó lại đến từ một máy khác không nhớ bản sửa.

Bộ phân giải không phải miền tìm kiếm

Việc phân giải cũng cần tên được thử. Một tên chưa đủ điều kiện như fileserver chỉ trở thành fileserver.corp.example khi một miền tìm kiếm được gắn vào giao diện mang truy vấn. Một VPN đẩy máy chủ DNS mà không có danh sách tìm kiếm tạo ra một sự chia cắt rất cụ thể: tên đủ điều kiện đầy đủ phân giải được còn mọi tên ngắn đều hỏng.

Hãy thử cả hai dạng trước khi sửa hồ sơ, vì hai lỗi chỉ về hai hướng khác nhau. Trên máy chủ systemd-resolved, liên kết đường hầm có máy chủ và miền định tuyến riêng, nên hãy đọc liên kết chứ không phải tệp toàn cục.

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

Nếu truy vấn được gán cho một liên kết không mang đường hầm, miền định tuyến bị thiếu dù địa chỉ DNS có mặt. Đó là vấn đề chính sách trong cấu hình resolved, không phải vấn đề định tuyến trong đường hầm.

Container mang bản sao câu trả lời của riêng chúng

Một container dựng từ image chung thường mang resolv.conf cố định. Các thay đổi bộ phân giải trên máy chủ không tới được nó, và miền tìm kiếm cũng vậy, nên một công việc build mount chia sẻ qua đường hầm sẽ hỏng trong khi cùng lệnh đó chạy được ngoài container. Hãy cho container cài đặt DNS và tìm kiếm riêng trong tệp compose hoặc trong đối số run, không chỉ trong hồ sơ máy chủ.

Hãy kiểm tra bên trong container trước khi đổ lỗi cho image. Hai lệnh tái hiện toàn bộ chẩn đoán trong vài giây, và lệnh thứ hai chứng minh bộ phân giải nào thực sự trả lời.

Chỉ khi đó mới nhìn vào chia sẻ và bộ lọc

Khi tên đã phân giải, những lỗi còn lại là vấn đề mạng bình thường. SMB cần TCP 445 tới máy chủ, và việc duyệt danh sách nhóm làm việc phụ thuộc vào các dịch vụ tên mà đường hầm có lẽ không chuyển tiếp. Hãy ánh xạ theo tên máy chủ thay vì chờ danh sách đầy lên, và để máy khách cho bạn biết nó đã tới giai đoạn nào. Kết nối bị từ chối và timeout im lặng cũng đáng tách ra, vì cái đầu thường nghĩa là có gì đó đã trả lời còn cái sau là không gì cả.

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

Một địa chỉ đã phân giải với cổng 445 bị từ chối hoặc quá hạn là vấn đề tường lửa hoặc trình lắng nghe ở phía bên kia. Một tên chưa phân giải là vấn đề bộ phân giải. Còn một mount xác thực được nhưng trả lỗi quyền thì không phải cả hai, nên đừng mở lại câu hỏi mạng khi phiên đã được thiết lập.

Giữ kết luận hẹp như bằng chứng. Khi địa chỉ chạy mà tên không, đường hầm đang làm việc của nó, và bản sửa thuộc về thứ tự bộ phân giải, miền tìm kiếm hoặc cấu hình riêng của container.