Đường hầm chia tách đang bật mà máy in vẫn ngoại tuyến: vì sao

Đường hầm của bạn đang bật, internet hoạt động, đường hầm chia tách đã được bật từ nhiều tháng trước, vậy mà máy in bên cạnh bàn vẫn hiện là ngoại tuyến. Sự kết hợp đó không phải mâu thuẫn, vì đường hầm chia tách là quyết định định tuyến chứ không phải lời hứa về khả năng kết nối. Ba cơ chế nằm giữa hàng đợi in và tờ giấy, và chúng hỏng theo những cách trông giống hệt nhau từ biểu tượng trên khay. Hãy theo dõi địa chỉ trước, rồi tuyến, rồi bộ lọc.

Bắt đầu với địa chỉ phía sau hàng đợi

Đọc địa chỉ hoặc tên máy chủ được lưu trong hàng đợi in, rồi so sánh với địa chỉ mà máy in hiển thị trên màn hình mạng của chính nó. Hàng đợi vẫn trỏ tới địa chỉ cũ sẽ hành xử đúng như lỗi định tuyến, và rất khó phân biệt hai thứ chỉ bằng triệu chứng. Lấy cả hai giá trị trước khi thay đổi bất kỳ giá trị nào. Một trong hai thường đã cũ, và cái cũ thường là hàng đợi.

Hàng đợi dựng trên tên máy chủ thêm việc phân giải tên vào đường đi, một cơ chế tách biệt khỏi định tuyến. Nếu tên máy chủ được phân giải khác đi bên trong đường hầm, hàng đợi sẽ tới một máy khác hoặc không tới đâu cả. Địa chỉ số loại bỏ biến đó trong suốt cuộc kiểm tra.

Ghi lại cặp giá trị, vì phần còn lại của cuộc điều tra so sánh chúng thay vì đoán.

Tuyến cho địa chỉ đó được chọn như thế nào

Giả sử máy in ở 192.168.1.50 và mạng văn phòng cũng dùng 192.168.1.0/24. Tuyến qua đường hầm bao phủ subnet đó giờ có thể cạnh tranh với tuyến trực tiếp tới máy in trong căn hộ của bạn, và mục cụ thể hơn sẽ thắng. Đổi cổng sang cùng địa chỉ số không thể xóa bỏ sự mơ hồ đó, vì sự mơ hồ nằm trong bảng định tuyến.

Một hồ sơ VPN cài tuyến mặc định sẽ bắt mọi thứ, và tiền tố liên kết cục bộ khi đó chỉ tiếp cận được qua đường hầm. Hồ sơ đường hầm chia tách thay vào đó cài các tiền tố doanh nghiệp, điều này thường khôi phục đường đi cục bộ. Hãy kiểm tra tuyến thực sự được chọn cho địa chỉ máy in, không phải tên của thiết lập đã tạo ra nó.

Đọc bảng và tuyến đã chọn cùng nhau, vì bảng cho thấy các ứng viên còn tra cứu cho thấy người thắng.

Get-Printer | Select-Object Name, PortName, DriverName
Get-PrinterPort -Name 'IP_192.168.1.50' | Select-Object PrinterHostAddress
route print -4 | Select-String '192.168.1'

Vì sao khám phá thất bại khi địa chỉ hoạt động

Khám phá máy in tự động trên mạng cục bộ phụ thuộc vào DNS multicast hoặc giao thức phát sóng cũ hơn, và cả hai đều giới hạn trong một liên kết. Bộ định tuyến không chuyển tiếp multicast đó theo mặc định, và VPN cũng là bộ định tuyến. Thêm hàng đợi dựa trên địa chỉ sẽ sửa trường hợp khám phá là thứ duy nhất bị hỏng, và đó chính là lý do cách xử lý tạm này thường bị nhầm là may mắn.

Có thể ghi lại sự khác biệt dễ dàng: nếu địa chỉ trả lời trên cổng in nhưng máy in không bao giờ xuất hiện trong danh sách thêm máy in, thì phạm vi khám phá là thủ phạm. Nếu cả hai đều không hoạt động, thì tuyến hoặc bộ lọc là thủ phạm. Hai phép thử, hai người phụ trách khác nhau và không cài lại trình điều khiển ở giữa.

Kiểm tra địa chỉ trực tiếp thay vì chờ danh sách đầy lên. Các lệnh bên dưới làm đúng điều đó.

Test-NetConnection 192.168.1.50 -Port 9100
nslookup 192.168.1.50
ping -c 2 192.168.1.50

Bộ lọc truy cập cục bộ của máy khách thêm gì

Máy khách đầu cuối có thể lọc lưu lượng cục bộ độc lập với bảng định tuyến. Thiết lập này thường được gọi là truy cập mạng cục bộ, và nó có thể chặn lưu lượng tới phân đoạn cục bộ trong khi đường hầm được kết nối, ngay cả khi tra cứu tuyến có vẻ đúng. Đó là một lớp chính sách, và không việc sửa tuyến nào thay đổi được nó.

Trên thiết bị được quản lý, hãy hỏi quản trị viên hồ sơ nhắm tới điều gì thay vì tự gạt công tắc. Bộ lọc thường tồn tại vì ai đó đã quyết định rằng máy đang kết nối không nên tiếp cận mạng quán cà phê, và đó là quyết định hợp lý.

Đọc trạng thái hoặc nhật ký của chính máy khách để biết chính sách đang áp dụng, vì giao diện thường giấu nó sau một dòng tóm tắt. Mục nhật ký đó thường nêu tên quy tắc đã quyết định.

Kiểm tra đường đi bằng một công việc nhỏ

Khi địa chỉ, tuyến và bộ lọc đều trỏ tới máy in, hãy gửi một tài liệu ngắn duy nhất tới cùng hàng đợi trong khi đường hầm vẫn kết nối. Cách này tái hiện lỗi ban đầu trung thực hơn việc cài lại trình điều khiển chỉ được thử sau khi ngắt kết nối. Giữ công việc bình thường, vì bạn đang kiểm tra đường đi chứ không phải thiết bị.

Sau đó lặp lại khi đường hầm ngắt kết nối, để biết đường đi bạn đã sửa có phải là đường từng hoạt động hay không. So sánh đó là bằng chứng duy nhất rằng thay đổi có ý nghĩa.

Test-NetConnection 192.168.1.50 -Port 9100
Get-PrintJob -PrinterName 'Front Desk'
Get-NetRoute -DestinationPrefix 192.168.1.0/24

Nếu công việc in được ở cả hai trạng thái, hàng đợi, tuyến và bộ lọc đồng ý và lỗi đã hết. Nếu chỉ in được khi ngắt kết nối, đường hầm vẫn bắt địa chỉ máy in hoặc bộ lọc vẫn chặn nó, và bước tiếp theo là tra cứu tuyến chứ không phải trình điều khiển khác. Ghi lại lớp nào trong ba lớp bạn đã thay đổi, và phiếu đó sẽ không mở lại vào tháng sau.