Công tắc ngắt đang chặn máy in của bạn? Ba bước kiểm tra nên làm trước

Máy in của bạn hoạt động cách đây một giờ. Sau đó bạn bật VPN, và giờ các lệnh in nằm chờ trong hàng đợi cho đến khi thất bại. Nguyên nhân khả dĩ không phải máy in mà là công tắc ngắt: nó loại bỏ lưu lượng sẽ rời khỏi máy ra ngoài đường hầm, và máy in trong LAN chính là loại lưu lượng đó. Quyết định thực sự không phải là sửa in ấn thế nào, mà là thiết bị này có nên chạm tới mạng cục bộ hay không. Ba điều kiện quyết định điều đó, và bất kỳ điều kiện nào cũng có thể kết thúc cuộc thảo luận sớm.

Công tắc ngắt loại bỏ những gì và vì sao

Công tắc ngắt là một quy tắc định tuyến gắn với một chế độ lỗi. Khi đường hầm hoạt động, các gói khớp sẽ đi ra ở dạng mã hóa; khi đường hầm sập, ứng dụng khách chặn tuyến mặc định để không có gì đi ra ở dạng văn bản thuần. Máy in trong cùng mạng con không bao giờ khớp với tuyến của đường hầm, nên nó bị coi là một nỗ lực thoát, dù lưu lượng không bao giờ rời khỏi tòa nhà.

Việc dò tìm khiến triệu chứng trở nên khó hiểu. Máy in quảng bá qua DNS multicast trên cổng 5353, và hàng đợi hiển thị trong hộp thoại thêm máy in được dựng từ những quảng bá đó. Trong khi chặn đang hoạt động, quảng bá có thể không đến, nên máy in biến mất khỏi danh sách dù địa chỉ của nó vẫn phản hồi. IPP trên 631, in thô trên 9100 và SMB trên 445 là những dịch vụ LAN thông thường không có đường đi qua đường hầm.

Trước tiên hãy chứng minh máy in có thể truy cập được

Trước khi thay đổi bất kỳ chính sách nào, hãy xác nhận máy in khỏe mạnh và xác nhận địa chỉ mà bạn nghĩ nó có. Đọc địa chỉ từ bảng điều khiển của máy in hoặc trang web của chính nó. Một mục cũ trong danh sách của hệ điều hành có thể trỏ tới địa chỉ mà DHCP đã cấp cho thiết bị khác vài tuần trước.

Ngắt kết nối VPN, sau đó kiểm tra địa chỉ và hai cổng in thông dụng:

nc -vz 192.168.1.50 9100
nc -vz 192.168.1.50 631

Trên Windows, tương đương là Test-NetConnection 192.168.1.50 -Port 9100. Kết nối lại VPN và lặp lại. Nếu các cổng phản hồi khi VPN tắt và hết thời gian khi VPN bật, bạn đã tái hiện được việc chặn và phần còn lại là câu hỏi chính sách. Nếu chúng thất bại ở cả hai trạng thái, hãy dừng lại: máy in, phân đoạn Wi-Fi hay cách ly máy khách là thủ phạm, và một ngoại lệ VPN chỉ làm tăng phơi nhiễm.

Ba điều kiện quyết định cho phép hay chặn

Hãy thực hiện theo thứ tự. Điều kiện đầu tiên thất bại sẽ quyết định kết quả, nên những điều kiện sau không cần kiểm tra.

Mạng dành cho khách là câu trả lời ‘không’ rõ nhất. Trên một phân đoạn khách sạn, dải địa chỉ cục bộ là mọi khách khác, nên một ngoại lệ chạm tới máy in của bạn cũng chạm tới laptop của họ. Một máy in không phải của bạn không phải lý do để mở phân đoạn đó.

Thiết bị được quản lý là câu trả lời ‘không’ thứ hai. Khi hồ sơ quản trị viên bắt buộc VPN luôn bật với khóa, ứng dụng khách tái lập việc chặn sau mọi thay đổi cục bộ, và cách lách có thể vi phạm chính sách bạn đã chấp nhận. Hãy yêu cầu một đường dẫn tài nguyên cục bộ được hỗ trợ thay vì sửa các thiết lập sẽ bị ghi đè.

Ngoại lệ nhỏ nhất mà ứng dụng khách của bạn hỗ trợ

Điều bạn muốn là một quy tắc giới hạn theo đích cho một địa chỉ máy in, không phải một nút bật ‘cho phép cục bộ’ toàn diện. Nút toàn diện thường bao trùm toàn bộ dải riêng và lưu lượng link-local, nhiều hơn mức một hàng đợi in cần, và biến mọi thiết bị trên phân đoạn thành một ngang hàng mà bạn đã chấp nhận.

Windows cung cấp chia đường hầm, và một số bản dựng còn cung cấp tùy chọn mạng cục bộ. Khi đường duy nhất được hỗ trợ là một mục máy chủ, hãy thêm một địa chỉ qua cổng vật lý sau khi đường hầm hoạt động, ví dụ route add 192.168.1.50 mask 255.255.255.255 192.168.1.1, rồi xóa nó khi phiên kết thúc. WireGuard hoạt động khác: AllowedIPs quyết định điều gì đi vào đường hầm, nên một hồ sơ đường hầm đầy đủ 0.0.0.0/0 mang lệnh in tới điểm cuối trừ khi một tuyến cụ thể hơn đi vòng qua nó, và wg-quick có thể cài các quy tắc tường lửa chặn mọi thứ khác.

Trên Android, thiết lập luôn bật chặn kết nối khi không có VPN chính là công tắc ngắt, và việc dò tìm máy in từ một ứng dụng bên trong khối chặn đó không có đường tới LAN. Mô hình theo từng ứng dụng và ngoại lệ được ghi lại trên trang VPN của Android, nơi cần kiểm tra trước khi bạn thay đổi bất cứ điều gì:Hướng dẫn kết nối VPN trên Android. Các bản macOS gần đây yêu cầu quyền truy cập mạng cục bộ riêng biệt với đường hầm, và iOS cũng làm vậy cho truy cập mạng cục bộ, nhưng hàng đợi vẫn có thể thất bại khi đường hầm bật vì ứng dụng khách của nhà cung cấp định tuyến mạng con vào đường hầm.

Dù bạn dùng ứng dụng khách nào, hãy giữ ngoại lệ ở một địa chỉ và hai hoặc ba cổng mà máy in thực sự dùng. Hãy giữ một hợp đồng thuê DHCP thay vì mở rộng quy tắc cho cả mạng con, vì địa chỉ có thể thay đổi.

Xác minh ngoại lệ và biết khi nào cần hoàn tác

Sau khi thay đổi, hãy kết nối lại và kiểm tra ba điều theo thứ tự. Máy in phản hồi trên các cổng của nó, một trang kiểm tra vô hại được in ra, và tra cứu địa chỉ vẫn trả về điểm cuối VPN thay vì nhà cung cấp của bạn. Nếu việc in hoạt động nhưng tra cứu cho thấy nhà cung cấp của bạn, bạn đã mở nhiều hơn máy in và nên hoàn tác.

Lặp lại kiểm tra sau khi khởi động lại và sau mọi bản cập nhật ứng dụng khách hoặc hồ sơ, vì các bản cập nhật khôi phục mặc định đủ thường xuyên để có ý nghĩa. Một ngoại lệ chỉ tồn tại đến lần kết nối tiếp theo không phải là quyết định, mà là một lỗ hổng tạm thời. Hãy ghi lại quy tắc chính xác để bạn có thể gỡ bỏ nó một cách có chủ đích.

Nếu thiết bị chỉ dành cho đường hầm, một laptop đi công tác hoặc máy chứa dữ liệu khách hàng, câu trả lời đúng là giữ việc chặn và in ở nơi khác: lưu thành PDF và in từ điện thoại hoặc máy khác, hoặc tới một máy chủ in mà đường hầm có thể định tuyến tới. Tắt công tắc ngắt cho một lệnh in đánh đổi sự bảo vệ thực sự lấy một chút tiện lợi.