Không truy cập được NAS qua VPN: địa chỉ, đường về hay dịch vụ?
Một đường hầm riêng cần tuyến đến NAS, đường phản hồi và dịch vụ được phép. Xác định cái nào trong ba điểm đã hỏng trước khi thay đổi thông tin đăng nhập.
Đường hầm dựng lên, máy khách nhận được địa chỉ, và NAS không trả lời gì cả. Một triệu chứng duy nhất này bao trùm ba lỗi không liên quan, và thứ tự kiểm tra quyết định việc sửa chữa mất bao lâu. Đánh địa chỉ đến trước, vì một subnet chồng lấn có thể gửi yêu cầu của bạn đến thiết bị lạ. Đường về đến thứ hai, vì một yêu cầu đến mà không có phản hồi trông giống hệt một dịch vụ đóng. Dịch vụ và quyền đến sau cùng, và chỉ sau khi hai điều đầu đã được chứng minh.
Ba lỗi đều bị đọc thành không truy cập được
Chọn địa chỉ, định tuyến đường về và cấp quyền dịch vụ tạo ra cùng một thông báo nhìn thấy được: không có gì xảy ra. Chúng có bằng chứng, người phụ trách và cách sửa khác nhau, nên việc tách chúng ra chính là toàn bộ công việc. Một ping thất bại tự nó chứng minh được rất ít, còn một lần từ chối TCP thành công thực ra là tin tốt.
| Observation | Most likely conclusion |
|---|---|
| Route to the NAS address leaves the wrong interface | Overlapping or missing private route |
| Request visible on the server, no reply seen | Return path, gateway forwarding or translation |
| TCP connection refused rather than dropped | Reachable host, service not listening or filtered |
| TCP works, login or file access fails | Share permission, account or protocol version |
Đọc bảng như thứ tự kiểm tra chứ không phải danh sách nguyên nhân. Mỗi dòng giới hạn dòng tiếp theo, vì sự từ chối đã chứng minh đánh địa chỉ và đường về hoạt động. Dành hai mươi phút trong các quy tắc tường lửa trước khi kiểm tra tuyến đã chọn giao diện nào là cách phổ biến nhất để mất một buổi chiều. Làm từ trên xuống dưới và dừng ở dòng đầu tiên khớp.
Điều kiện một: địa chỉ đó có đúng thiết bị không?
Ghi lại subnet của NAS và dải mà VPN cấp cho máy khách, rồi so sánh cả hai với mạng mà laptop của bạn đang ở. Trong hướng dẫn này NAS ở 10.40.7.25 và pool VPN là 10.40.9.0/24, hai dải riêng tư tách biệt trong cùng một kế hoạch site; một hộ gia đình dùng 192.168.0.0/24 hoặc 10.0.0.0/24 có khả năng va chạm với một trong hai cao hơn nhiều.
Khi mạng cục bộ và mạng NAS chồng lấn, máy khách gửi lưu lượng đó đến cổng của chính nó và có thể chạm tới một thiết bị không liên quan tình cờ có cùng địa chỉ. Kiểm tra tuyến trước khi gõ thông tin đăng nhập vào bất cứ thứ gì trả lời.
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25Lệnh đầu tiên nêu giao diện và cổng mà kernel sẽ dùng, lệnh thứ hai hiển thị những hop đầu tiên thực sự trả lời. Nếu hai kết quả không khớp, hãy tin vào tra cứu, vì đó là đường gói tin sẽ đi. Danh sách hop dừng một hop trước NAS cũng là một phát hiện chứ không phải thất bại. Một tra cứu phân giải về card mạng vật lý thay vì đường hầm sẽ kết thúc điều tra tại điểm này.
Điều kiện hai: phản hồi có quay về không?
Máy khách cần tuyến về phía NAS, và mạng NAS cần đường về phía pool VPN. Chuyển tiếp tại cổng, quy tắc tường lửa và dịch địa chỉ có chủ đích đều ảnh hưởng đến cặp đó. Ghi chú của strongSwan về chuyển tiếp mô tả các lựa chọn tuyến về và dịch địa chỉ cho một subnet riêng phía sau cổng.
Khi yêu cầu đến và phản hồi đi ra qua một cổng khác, không thay đổi DNS nào sửa được sự bất đối xứng đó. Bắt gói ở cả hai phía giải quyết việc này trong một lần thử, và cũng cho thấy việc dịch có ghi lại nguồn mà NAS đã trả lời hay không. Quản trị viên chịu trách nhiệm ranh giới đó: chỉ cho phép các dịch vụ cần thiết và dải máy khách VPN, rồi ghi lại việc chọn định tuyến hay dịch địa chỉ.
Điều kiện ba: dịch vụ có ở đó và có được phép không?
Trang quản trị và dịch vụ chia sẻ tệp là hai điểm cuối khác nhau trên cùng một máy, và cái này có thể nhận kết nối trong khi cái kia bị tường lửa của máy chủ, cấu hình dịch vụ hoặc quyền chia sẻ chặn. Một thiết bị trả lời bằng từ chối đã chứng minh hai điều kiện đầu, điều này thu hẹp đáng kể điều kiện thứ ba.
Hãy thử với tài khoản thực sự cần tệp, không phải tài khoản quản trị dùng khi cài đặt, vì quyền quản trị không sửa được tuyến bị thiếu và tuyến không thể cấp quyền chia sẻ. Tên cũng thuộc phạm vi này: tên NAS được phát hiện ở nhà thường phụ thuộc multicast cục bộ mà đường hầm có định tuyến không mang theo, nên hãy thử tên máy chủ riêng đã được nhà sản xuất ghi lại hoặc chính địa chỉ để tách việc đặt tên khỏi truy cập.
Kiểm tra từ bên ngoài mạng NAS, rồi mở rộng dần
Một bài kiểm tra trên cùng LAN che giấu mọi phần chưa hoàn chỉnh của tuyến từ xa, vì vậy lần thử từ xa thành công đầu tiên xứng đáng được ghi vào nhật ký thay đổi. Chạy các kiểm tra từ máy khách chỉ đến NAS qua đường hầm, và giữ nguyên văn bản lỗi gốc của mỗi lần thử.
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guestKhi tuyến hoạt động, hãy truyền một tệp vô hại và xác nhận hành vi đọc hoặc ghi mà bạn thực sự cần. Nếu các lần truyền lớn bị kẹt trong khi lần nhỏ thành công, vấn đề còn lại là xử lý kích thước gói hoặc độ ổn định của kết nối chứ không phải đánh địa chỉ.
Đừng công bố cổng chia sẻ tệp hay quản trị ra internet để lách một lỗi chưa giải thích. Hãy sửa tuyến riêng, giữ phần mềm NAS được hỗ trợ, và kiểm tra việc khôi phục mọi thứ bạn sao lưu qua nó trước khi dựa vào bản sao lưu đó.