Chia sẻ SMB chỉ hỏng khi qua VPN: lỗi chữ ký hay xung đột mạng con?
Một chia sẻ chạy tốt trên LAN có thể hỏng chỉ qua đường hầm. Hãy tách lỗi từ chối chữ ký, mạng con chồng lấn và phiên SMB cũ.
Một ổ đĩa được ánh xạ chạy tốt ở văn phòng nhưng hết thời gian chờ ở nhà tự nó gần như không cho bạn thông tin hữu ích nào. Đường hầm rõ ràng đang truyền gói tin, nếu không sẽ chẳng có gì đến được máy chủ. Thứ đã hỏng nằm ở một trong ba lớp: tên được phân giải thành địa chỉ sai, máy khách từ chối ký phiên, hoặc một phiên cũ sống lâu hơn kết nối đã mang nó. Mỗi lớp có cách sửa khác nhau, và hai trong ba nằm ở phía máy khách.
Ba sự cố mặc cùng một lỗi
Chữ cái ổ đĩa không cho biết lớp nào đã hỏng, và nội dung lỗi thường đủ chung để khớp cả ba. Hãy tách chúng bằng hai câu hỏi nhanh: máy chủ có trả lời tại địa chỉ IP của nó không, và cổng 445 có chấp nhận kết nối không?
Những câu trả lời đó tạo ra bảng quyết định thay vì phỏng đoán. Nếu IP chạy mà tên không, đó là phân giải tên. Nếu cả hai chạy mà đăng nhập bị từ chối, đó là chữ ký. Nếu cả hai chạy mà việc đọc tệp bị treo sau khi đường hầm gián đoạn, đó là một phiên cũ.
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session state and timers |
Hãy xử lý theo đúng thứ tự đó, vì một cái tên phân giải đến máy chủ sai sẽ làm mọi bài kiểm tra sau trở nên vô nghĩa.
Phân giải tên trước khi chạm vào chia sẻ
Nếu máy chủ trả lời tại địa chỉ của nó mà tên chia sẻ hết thời gian chờ, đường hầm đang làm đúng việc của nó và máy khách đang tìm sai chỗ. Với truy cập từ xa, hai nguyên nhân giải thích phần lớn hiện tượng này.
Thứ nhất là chồng lấn địa chỉ. Khi văn phòng dùng 192.168.70.0/24 và router ở nhà cấp cùng dải, một tên máy phân giải thành 192.168.70.20 có thể trỏ tới thiết bị cục bộ thay vì máy chủ sau đường hầm. Windows khi đó có thể gửi yêu cầu cục bộ, từ chối tuyến, hoặc phân giải tới một máy in tình cờ có địa chỉ đó. Cách sửa là đánh số lại một bên, không phải thêm một tuyến khác.
Thứ hai là phạm vi DNS. Một bộ điều hợp VPN không có máy chủ DNS nội bộ, hoặc có nhưng không truy cập được qua đường hầm, để các tên ngắn đi tới trình phân giải công cộng. Hãy đọc các mục DNS của bộ điều hợp và hỏi trực tiếp tên nội bộ trước khi chạm vào chia sẻ:
> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15Nếu truy vấn đó trả về địa chỉ mong đợi, việc phân giải tên đã rõ và vấn đề nằm cao hơn trong ngăn xếp.
Đọc yêu cầu ký ở cả hai đầu
Một máy chủ truy cập được mà từ chối mọi lần đăng nhập là dấu hiệu lệch chính sách chứ không phải lỗi mạng. Windows có thể bắt buộc ký SMB ở phía máy khách, và một máy chủ hay NAS không ký thì không thể hoàn tất phiên, dù đường hầm có khỏe đến đâu.
Bạn có thể đọc thiết lập của máy khách mà không phải lục trình soạn chính sách:
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionGiá trị tương ứng phía máy chủ nằm trong cấu hình SMB của máy chủ, và hai bên phải khớp nhau. Trong một trường hợp được báo cáo, máy khách bật yêu cầu bằng chính sách cục bộ trong khi máy chủ hoàn toàn không ký; tắt yêu cầu đó và chạy gpupdate /force đã khôi phục chia sẻ ngay lập tức. Đó là bước chẩn đoán để xác nhận nguyên nhân, không phải cách sửa lâu dài.
Nên bật ký ở cả hai đầu khi máy chủ hỗ trợ. Thay đổi một thiết lập bảo mật để chia sẻ hoạt động cần được ghi lại cùng giá trị trước đó và lý do, để không ai phải phát hiện lại nó trong lần đánh giá tiếp theo.
Xóa phiên cũ trước khi tinh chỉnh bộ hẹn giờ
Một chia sẻ chỉ treo sau khi VPN rớt và kết nối lại thường đang giữ một phiên mà máy chủ đã bỏ. Máy chủ đóng các phiên SMB nhàn rỗi theo bộ hẹn giờ Autodisconnect trong LanmanServer\Parameters, mặc định là 15 phút, trong khi máy khách có SessTimeout riêng trong LanmanWorkstation\Parameters. Một gián đoạn dài hơn các giá trị đó để mỗi đầu có một hình dung khác nhau về phiên.
Hãy tái hiện theo một thứ tự cố định để kết quả có ý nghĩa: kết nối đường hầm, mở chia sẻ, ngắt đường hầm hai phút, khôi phục nó, rồi thử đọc một tệp. Nếu ổ gắn tự hồi phục, hãy để yên các bộ hẹn giờ. Nếu nó treo cho đến khi bạn gắn lại, hãy kết nối lại chia sẻ sau khi đường hầm đã lên thay vì gắn nó trước khi nó tồn tại, và kiểm tra xem trình trợ giúp gắn có thử lại không.
Tăng thời gian chờ là bước cuối hợp lý cho một liên kết chập chờn, nhưng nó chỉ chữa triệu chứng. Một máy khách chờ lâu hơn cho một phiên mà máy chủ đã quên thì vẫn chờ.
Kết thúc bằng việc đọc một tệp qua ổ gắn, rồi ngắt và khôi phục đường hầm thêm một lần nữa. Bài kiểm tra chấp nhận đó bao trùm cả ba lớp cùng lúc, và là bài duy nhất khớp với việc người dùng thực sự làm.