Принтери між офісами: усунення проблеми «бачу, але не друкує» через VPN

Практична модель: «бачу принтер» vs друк на нього

«Я бачу його» — це не значущий тест. Зазвичай це означає одне з такого:
пристрій відповів на ICMP echo, Windows UI виявив mDNS/WS-Discovery локально,
видимі шарінги на принт-сервері, або існує застарілий об’єкт підключення з минулого місяця.
Жодне з цього не доводить, що клієнт може завершити реальний шлях друку.

Друк — це ланцюг. Розірви будь-яке посилання — і користувач бачить той самий результат: нічого не виходить, черга зависла або «Помилка — друк».
Ваше завдання — виявити, яке посилання зламалося:

• Відкриття/знаходження: як користувач знайшов принтер (GPO, вручну, mDNS, WS-Discovery, LDAP, «Додати принтер»).
• Встановлення з’єднання: TCP‑handshake і автентифікація до сервісу друку (SMB, IPP, LPD, raw 9100).
• Спулінг: де завдання рендериться і зберігається (спулер клієнта vs принт‑сервер vs диск/пам’ять принтера).
• Транспорт: байти проходять через VPN, виживають MTU/MSS особливості й дозволи файрвола/NAT.
• Прийняття на пристрої: принтер приймає завдання і друкує (або тихо відхиляє через формат, ACL чи налаштування функцій).

Через VPN найпоширеніший розрив такий: ICMP працює, SMB/IPP — ні; або SMB працює, але друк зупиняється в середині передавання;
або завдання доходять до принт‑сервера, але ніколи не потрапляють на пристрій, бо принт‑сервер не може маршрутизуватися в підмережу філії.

Цитата, яку варто пам’ятати, коли хтось каже «але він відповідає на ping»:
перефразована ідея — Вінт Серф, у багатьох варіаціях протягом років: можливість відправляти пакети не означає, що у вас працює застосунок.

Швидкий план діагностики (перевірте 1/2/3)

Перевірка 1: Де фактично спулиться завдання?

Визначте, чи клієнт друкує безпосередньо на принтер (IPP/9100/LPD), чи через принт‑сервер (Windows Print Server, CUPS).
Це одне рішення змінює весь дерево діагностики.

• Якщо через принт‑сервер: чи може клієнт дістатися сервера через VPN? Чи може сервер дістатися принтера в локальній LAN філії?
• Якщо безпосередньо: чи може клієнт дістатися IP принтера на потрібному порту і підтримати довгий TCP‑передач?

Перевірка 2: Тестуйте реальний протокол друку, а не ping

Визначте протокол і порт:
друк через SMB зазвичай використовує TCP 445 до сервера (потім сервер говорить з принтером).
IPP зазвичай — TCP 631.
Raw JetDirect — TCP 9100.
LPD — TCP 515.
Потім протестуйте цей порт кінцево‑до‑кінця з машини, що ініціює завдання.

Перевірка 3: Шукайте ознаки «вмирає в середині» (MTU/MSS, таймаути stateful файрвола)

Сторінка або дві надрукувалася, а потім зависла? Або маленькі тестові сторінки йдуть, а великі PDF — ніколи?
Це зазвичай MTU/фрагментація, проблеми з TCP MSS clamping або stateful файрвол/NAT, що завершує довгі потоки.
Друк по суті — «передача великих обсягів даних з характером».

Швидкий «шпаргалка» для класифікації

• Черга застрягла на клієнті: спулер клієнта/драйвер/автентифікація до принт‑сервера.
• Черга застрягла на сервері: з’єднання сервер→принтер, рендеринг на сервері, ACL принтера.
• Завдання зникає: принтер відкидає формат, політика принтера скидає, або принт‑сервер робить повтори й здається.
• Частковий вивід: MTU/MSS, ненадійний VPN, DPI/IPS ламає IPP/SMB, або обмеження пам’яті/диску принтера.

Жарт №1: Ping — це еквівалент примахування комусь через вікно: приємний жест, але не договір про роботу.

Цікаві факти та історичний контекст (хіти друку)

• Raw порт 9100 (JetDirect) став популярним, бо він простий: відкриваєш TCP, стримуєш байти й надієшся на краще. Безпека тоді була не в пріоритеті.
• LPD/LPR походить з ранніх UNIX‑днів і досі живе в багатьох принтерах, бо постачальникам не подобається видаляти «навігаційну сумісність».
• IPP (Internet Printing Protocol) був створений більш дружнім для інтернету, ніж LPD, і використовує семантику HTTP — добре для WAN, якщо налаштовано правильно.
• Windows‑друк історично спирався на SMB/RPC і розподіл драйверів. Зручно в межах LAN і прикро через обмежені канали зв’язку.
• Bonjour/mDNS виявлення зробило принтери «самі з’являються» в локальних мережах — потім всіх бентежило, коли VPN не форвардив мультикаст.
• PostScript vs PCL колись були релігійними війнами; сьогодні це більше «який драйвер змусить цей PDF не вибухнути».
• Вендори додали вбудоване сховище для спулінгу й збереження завдань; коли диск заповнюється, принтери можуть відмовляти так, ніби це мережа.
• Жорсткіша політика SMB за останнє десятиліття (підпис, шифрування, застарівання) підвищила безпеку, але зробила міжсайтну взаємодію крихкішою, якщо конфігурації неузгоджені.
• Зміни після PrintNightmare підштовхнули організації переосмислити встановлення драйверів і політику point‑and‑print; друк через VPN зламався новими, креативними способами.

Карта відмов: де «бачу, але не друкує» розвалюється

1) Відкриття бреше (або принаймні перебільшує)

Користувачі «бачать» принтери через кешовані об’єкти, старі GPO‑мапінги або список шарів принт‑сервера. Це не гарантує:
що облікові дані валідні, сервер доступний по потрібному маршруту, або принтер за сервером онлайн.

2) Маршрутизація VPN і split‑tunneling не нейтральні

Split tunnel добре, доки принт‑сервер «внутрішній», а діапазон IP принтерів — «філія», і клієнт неправильно робить hairpin.
Або DNS повертає внутрішню адресу, до якої клієнт не може прорутити.
Або VPN не штовхає маршрути для VLAN принтерів, бо хтось вирішив «принтери — низький ризик».
(Вони не низький ризик. Вони запускають повні ОСи й зберігають документи. І вони потребують уваги.)

3) Політики файрвола часто дозволяють ICMP, але блокують порти друку

Часто ICMP дозволено для діагностики, тоді як TCP 9100/631/515/445 заборонено через VPN.
Це не завжди помилка — друк між сайтами може бути рішенням із безпеки — але це класична причина, чому «я можу пінгувати» стає пасткою.

4) MTU/MSS і фрагментація проявляються як «завдання висить»

Потоки друку можуть бути великими й тривалими. Наклад IPsec, GRE або надмірний MTU можуть створити чорні діри, де
менші пакети проходять, а більші зникають. Ви отримуєте часткові друки, завислі черги й випадкові «тестова сторінка працює».

5) Автентифікація й ідентичність ламаються між доменами й тунелями

Друк через SMB до Windows‑принт‑сервера може провалюватися, бо клієнт не може отримати Kerberos‑квитків (DNS/AD site mapping),
годинники роз’їхалися, або NTLM обмежений. Принтер видно, завдання відправляються, а потім ви отримуєте доступ заборонено чи мовчазні відмови.

6) Драйвери й рендеринг можуть відмовляти без очевидних помилок

VPN робить лінки повільними. Повільні лінки викликають таймаути драйверів і спулерів.
Також «універсальні» драйвери іноді універсальні, як скотч: працюють, поки дуже не перестають.

Практичні завдання: команди, виводи, рішення (12+)

Ці завдання передбачають, що ви — SRE/оператор з доступом до Linux jump box, принт‑сервера (Linux CUPS або Windows),
і, опційно, робочої станції користувача. Мета — звести друк до вимірюваних мережевих і станів спулінгу.
Кожне завдання включає: команду, що означає її вивід, і рішення, яке слід прийняти.

Завдання 1: Підтвердьте маршрут до підмережі принтера (з фактичного джерела)

cr0x@server:~$ ip route get 10.42.18.25
10.42.18.25 via 10.8.0.1 dev tun0 src 10.8.0.12 uid 1000
    cache

Значення: трафік до IP принтера йде через VPN‑інтерфейс (tun0) і правильний шлюз.
Якщо ви бачите локальний шлюз або публічний інтерфейс — у вас split‑tunneling налаштований неправильно.

Рішення: Якщо маршрут неправильний, виправте pushed маршрути VPN / таблицю маршрутів клієнта до змін у принт‑конфігурації.

Завдання 2: Перевірте, як DNS резолвить принт‑сервер згідно з очікуванням VPN

cr0x@server:~$ getent hosts print01.corp.local
10.20.5.10     print01.corp.local

Значення: ім’я резолвиться на внутрішній IP. Якщо воно резолвиться інакше (або взагалі ні), клієнт може використовувати публічний DNS.

Рішення: Виправте налаштування DNS VPN / split DNS. Не хардкодьте IP, якщо не хочете постійних інцидентів.

Завдання 3: Тестуйте реальний порт друку (IPP 631) замість ping

cr0x@server:~$ nc -vz -w 3 10.42.18.25 631
Connection to 10.42.18.25 631 port [tcp/ipp] succeeded!

Значення: TCP‑handshake пройшов. Якщо таймаут — це маршрут/файрвол/VPN‑політика, а не драйвер.

Рішення: Якщо заблоковано, відкрийте потрібні порти на шляху VPN/файрволу або перейдіть на модель з принт‑сервером.

Завдання 4: Тестуйте raw друк (JetDirect 9100) на доступність

cr0x@server:~$ nc -vz -w 3 10.42.18.25 9100
Connection to 10.42.18.25 9100 port [tcp/*] succeeded!

Значення: socket‑друк доступний. Якщо 631 падає, а 9100 працює — ви на іншому кодовому шляху (ймовірно різні правила файрвола).

Рішення: За можливості віддавайте перевагу IPP для керованості; 9100 — коли ви погоджуєтесь на «менше керування, більше загадок».

Завдання 5: Підтвердьте Path MTU VPN (знайдіть чорну діру)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.42.18.25
PING 10.42.18.25 (10.42.18.25) 1372(1400) bytes of data.
1380 bytes from 10.42.18.25: icmp_seq=1 ttl=63 time=28.1 ms
1380 bytes from 10.42.18.25: icmp_seq=2 ttl=63 time=27.9 ms
1380 bytes from 10.42.18.25: icmp_seq=3 ttl=63 time=28.0 ms

--- 10.42.18.25 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms

Значення: Path MTU підтримує ~1400‑байтові пакети без фрагментації. Якщо ви бачите «Frag needed» або таймаути при більших розмірах — у вас проблема MTU.

Рішення: Застосуйте MSS clamping на VPN/файрволі, знизьте MTU на тунелі або виправте PMTUD‑фільтрацію.
Не «виправляйте» це зміною драйверів — ви лише пересунете проблему.

Завдання 6: Перевірте таймаути stateful файрвола/NAT (спостерігайте потік)

cr0x@server:~$ sudo tcpdump -ni tun0 host 10.42.18.25 and tcp port 9100
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:04:11.123456 IP 10.8.0.12.53122 > 10.42.18.25.9100: Flags [S], seq 123456789, win 64240, options [mss 1360,sackOK,TS val 1 ecr 0,nop,wscale 7], length 0
12:04:11.150000 IP 10.42.18.25.9100 > 10.8.0.12.53122: Flags [S.], seq 987654321, ack 123456790, win 28960, options [mss 1360,sackOK,TS val 2 ecr 1,nop,wscale 7], length 0
12:04:11.150200 IP 10.8.0.12.53122 > 10.42.18.25.9100: Flags [.], ack 1, win 502, options [TS val 3 ecr 2], length 0

Значення: handshake пройшов. Якщо пізніше ви бачите ретрансмісії, RST або великі паузи — підозрюйте middlebox‑и.

Рішення: Якщо сесії скидаються після N секунд, відрегулюйте таймери сесій файрвола або маршрутизовуйте через принт‑сервер ближче до принтера.

Завдання 7: На CUPS‑сервері — перелік принтерів і підтвердження device URI

cr0x@server:~$ lpstat -v
device for HR-Laser: ipp://10.42.18.25/ipp/print
device for Finance-Color: socket://10.42.18.30:9100

Значення: CUPS знає, куди надсилає завдання. Неправильний IP тут може зберігатися місяцями, бо принтери «переміщуються», а URI ніхто не оновлює.

Рішення: Якщо URI вказує на стару підмережу, виправте його (lpadmin -p ... -v ...) і повторно спробуйте перед тим, як копатися в VPN.

Завдання 8: На CUPS‑сервері — стан черги та поведінка завдань

cr0x@server:~$ lpstat -p HR-Laser -l
printer HR-Laser is idle.  enabled since Sun 28 Dec 2025 11:33:12 AM UTC
        Form mounted:
        Content types: any
        Printer types: unknown
        Description: HR-Laser
        Alerts: none
        Location: Branch-2
        Connection: direct

Значення: «idle» свідчить, що CUPS наразі не заблокований. Якщо написано «paused» або «stopped» — це адміністративна або помилкова зупинка.

Рішення: Якщо пауза — читайте лог помилок і знову ввімкніть принтер. Не відправляйте нескінченно повторно завдання в паузну чергу.

Завдання 9: Надішліть контрольований тестовий друк (маленький, відомий)

cr0x@server:~$ printf "VPN print test: $(date -Is)\n" | lp -d HR-Laser
request id is HR-Laser-1042 (1 file(s))

Значення: Завдання прийняте спулером. Якщо користувач спочатку надрукував 200‑сторінковий PDF, ви нічому не навчитесь, окрім терплячості черг.

Рішення: Якщо малі завдання працюють, а великі ні — переходьте до MTU/таймаутів/обмежень розміру спулу.

Завдання 10: Хвостіть лог CUPS під час друку, щоб зловити помилки на рівні протоколу

cr0x@server:~$ sudo tail -n 30 -f /var/log/cups/error_log
E [28/Dec/2025:12:10:22 +0000] [Job 1042] Unable to connect to 10.42.18.25:631 - Connection timed out
E [28/Dec/2025:12:10:22 +0000] [Job 1042] Backend returned status 1 (failed)

Значення: Це не проблема драйвера. Це timeout підключення до IP‑адреси принтера на порті IPP з боку сервера.

Рішення: Виправте маршрут/файрвол від CUPS‑серверу до підмережі принтера, або помістіть принтер за локальним проксі друку.

Завдання 11: Підтвердіть, що принт‑сервер може дістатися принтера (не тільки клієнт)

cr0x@server:~$ traceroute -n 10.42.18.25
traceroute to 10.42.18.25 (10.42.18.25), 30 hops max, 60 byte packets
 1  10.20.5.1  0.451 ms  0.389 ms  0.377 ms
 2  10.8.0.1   12.401 ms  12.380 ms  12.355 ms
 3  10.42.0.1  22.110 ms  22.099 ms  22.087 ms
 4  10.42.18.25  28.022 ms  27.991 ms  27.975 ms

Значення: Існує реальний маршрутизований шлях. Якщо маршрут обривається на хопі 2 або 3 — ваш site‑to‑site маршрут відсутній там, де ви думаєте.

Рішення: Виправте мережевий шлях принт‑сервер→філія; не витрачайте час на перевстановлення клієнтських принтерів.

Завдання 12: На Linux перевірте локальні правила файрвола, що можуть блокувати вихідний друк

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain output {
    type filter hook output priority filter; policy accept;
  }
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport { 22, 631 } accept
  }
}

Значення: Політика output — accept; input дозволяє 631. Якщо у вас була політика output=drop, ви могли б мовчки блокувати backend‑з’єднання.

Рішення: Якщо output обмежено — явно дозвольте tcp dport 631/9100 до підмереж принтерів.

Завдання 13: Перевірте доступність шарів Windows‑принт‑сервера (SMB) з Linux

cr0x@server:~$ smbclient -L //print01.corp.local -U 'CORP\svc-print%REDACTED'
	Sharename       Type      Comment
	---------       ----      -------
	IPC$            IPC       Remote IPC
	HR-Laser        Printer   HR-Laser on Branch-2
	Finance-Color   Printer   Finance-Color on HQ
SMB1 disabled -- no workgroup available

Значення: SMB‑підключення й автентифікація працюють; шари видимі. Якщо це падає — клієнти теж не зможуть під’єднатися надійно.

Рішення: Якщо автентифікація провалюється — перевірте AD‑зв’язок через VPN, синхронізацію часу і політики NTLM/Kerberos.

Завдання 14: Підтвердіть зсув часу Kerberos (класичний «працює в LAN, падає по VPN»)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 12:15:02 UTC
           Universal time: Sun 2025-12-28 12:15:02 UTC
                 RTC time: Sun 2025-12-28 12:15:01
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: Годинник синхронізований. Якщо клієнт або сервер мають зсув часу — Kerberos падає, і друк через SMB може перетворитися на повтори або access denied.

Рішення: Виправте NTP/chrony/AD джерело часу в першу чергу. Не відключайте Kerberos «щоб друк працював» — так легко отримати інцидент безпеки з паперовими документами.

Завдання 15: Перевірте MSS clamping на VPN‑краю (коли великі завдання зависають)

cr0x@server:~$ sudo iptables -t mangle -S | sed -n '1,80p'
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Значення: MSS прикладається до PMTU для переадресованих SYN. Якщо цього правила немає в середовищі IPsec/GRE, великі потоки можуть чорнодіритися.

Рішення: Додайте MSS clamping (або еквівалент на вашому файрволі/VPN), замість того щоб знижувати MTU на випадкових кінцевих точках.

Завдання 16: Шукаймовідмову на боці принтера (IPP коди відмов)

cr0x@server:~$ ipptool -tv ipp://10.42.18.25/ipp/print get-printer-attributes.test
ipptool: Using port 631
ipptool: Printer supports IPP/2.0
ATTR: printer-state (enum) = idle(3)
ATTR: printer-is-accepting-jobs (boolean) = true
ATTR: printer-up-time (integer) = 582113

Значення: Принтер приймає завдання й відповідає на IPP‑запити. Якщо він повідомляє, що не приймає завдань, призупинений або повертає помилки авторизації — це конфігурація пристрою.

Рішення: Виправте політику принтера (ACL, автентифікація, утримання завдань) або оновіть облікові дані, якщо використовується IPP з автентифікацією.

Жарт №2: Принтери — єдині IoT‑пристрої, які можуть зіпсувати вам день, а потім вимагати, щоб ви поповнили їхні цианові почуття.

Три корпоративні історії з полі бою

Інцидент через неправильне припущення: «Якщо пінгується, порт відкритий.»

Мультиофісна компанія розгорнула новий VPN‑клієнт з «чистішою безпековою позицією». Переклад: менше маршрутів, жорсткіші правила файрвола
і гарний інтерфейс, який переконав керівництво, що проблема вирішена за замовчуванням.
Наступного ранку працівники філій бачили принтери в списку Windows Add‑printer (закешовані раніше) і могли пінгувати IP принтерів.
Друк не працював скрізь.

Початкова реакція була передбачуваною: перевстановлення драйверів, видалити/додати принтери, перезавантажити спулери, перезавантажити принтери і — бо це корпоративне життя — перезавантажити надію.
Нічого не допомогло. Завдання зависали в станах «Spooling» або «Printing» вічно. Хелпдеск почав збирати скріншоти, ніби створював виставку мистецтва.

Неправильне припущення полягало в тому, що успіх ICMP означає успіх політики. У файрволі VPN була правило, що дозволяло ICMP до «внутрішніх підмереж»
для діагностики, але TCP 9100 і 631 не були дозволені від клієнтів VPN до VLAN принтерів. Це не було зловмисно.
Це була просто чиєсь ідея найменшого привілею, реалізована без моделі загроз для друку.

Виправлення було двоетапним: дозволити клієнтам VPN доступ до принт‑серверів, а не до VLAN принтерів; потім забезпечити, щоб лише принт‑сервери мали доступ до принтерів.
Команда також переписала рукопис: «Ping необов’язковий; завжди тестуйте реальний порт.» Майже відчувалося, як спадає колективний тиск.

Оптимізація, яка відскочила: «Приберемо принт‑сервер — друк прямо.»

Інша організація хотіла «зменшити залежності» і «прибрати одиночні точки відмови», тому вони перейшли на прямі інсталяції на принтер.
Користувачі підключалися до принтерів по IPP або raw TCP, навіть з дому через VPN. На слайді це виглядало блискуче.
Ніякого обслуговування принт‑серверів, ніякого розподілу драйверів, ніякої драми з чергами.

Це працювало — поки не перестало. Перші тріщини були тонкі: малі завдання друкувалися, великі — зависали.
Потім велика проблема: оновлення прошивки змінило TLS‑за замовчуванням для IPP, і старі клієнти більше не могли домовитись.
Половина парку для віддалених співробітників знеструмлена. Локально команда десктопів все ще друкувала, бо їхній LAN‑шлях не йшов через VPN‑middlebox‑и.

«Оптимізація» також збільшила площу ураження. Замість виправлення однієї конфігурації принт‑серверу їм довелося підтримувати зоопарк клієнтів:
різні ОС, різні версії драйверів, різні реалії MTU, різні профілі VPN. Дебаг став вправою в порівнянні хаосу.

Зрештою вони перебудували архітектуру навколо невеликої кількості принт‑серверів на регіон, плюс суворе правило:
клієнти VPN можуть друкувати тільки на принт‑сервери, ніколи безпосередньо в підмережі принтерів.
Не тому, що користувачів не можна довіряти (хоча), а тому що мережі поводяться краще, коли далека ділянка контрольована й прозора.

Нудна, але правильна практика, що врятувала день: «принт‑сервери поруч з принтерами, збережені логи і тест‑завдання»

Третя компанія мала звичку, яка виглядала невиразно: у кожному офісі була маленька VM з CUPS (або Windows‑принт‑сервер),
розміщена в тій самій LAN, що й принтери. Віддалені користувачі друкували на цей сервер через VPN. Сервер друкував локально.
Ніякого мультикаст‑виявлення. Ніякого прямого друку з віддалених клієнтів. Ніякої імпровізації.

Коли зміна VPN ввела невідповідність MTU, користувачі почали скаржитися, що PDF зависають на півдорозі.
Команда не чіпала драйвери на початку. Вони перевірили логи CUPS і побачили послідовні «connection reset by peer» на довгих завданнях,
але лише для сайту, чиї тунелі мали зміну інкапсуляції.

Оскільки дизайн тримав трафік принтерів локальним, їм потрібно було зробити надійним лише шлях VPN клієнт→сервер,
що було простіше: один IP, один набір портів і стабільний моніторинг. Вони застосували MSS clamping на краю VPN,
перевірили це контрольними тестовими друками, і інцидент завершився без масової перевстановлення образів.

Практика не була інноваційною. Вона була просто правильною. В операціях нудне — це функція.

Поширені помилки: симптом → корінна причина → виправлення

1) «Принтер показує онлайн, завдання зависають у стані ‘Printing’»

Корінна причина: Порт заблоковано (TCP 631/9100/445) через VPN; ICMP дозволено, тому всі обманюються.

Виправлення: Тестуйте з nc -vz. Відкрийте конкретний порт з правильного джерела (клієнт→сервер або сервер→принтер).
Краще: обмежте клієнтів так, щоб вони друкували тільки на принт‑сервери.

2) «Тестова сторінка друкується, PDF‑файли — ні»

Корінна причина: MTU/MSS чорна діра, таймаут stateful файрвола або DPI/IPS, що втручається у довгі потоки.

Виправлення: Тести Path MTU з ping -M do; увімкніть MSS clamping; відрегулюйте таймери сесій; уникайте прямого друку через VPN.

3) «Користувач може додати принтер, але отримує access denied при друку»

Корінна причина: Невідповідність автентифікації (проблеми Kerberos через VPN, обмеження NTLM, застарілі облікові дані) або дозволи шарів принтера.

Виправлення: Перевірте DNS/синхронізацію часу; підтвердіть доступ SMB до шарів; скоригуйте ACL і припущення щодо доменної довіри.

4) «Черга принт‑сервера показує завдання в стані ‘Sending data’»

Корінна причина: Принт‑сервер не може дістатися до підмережі принтера (відсутній маршрут, файрвол, асиметрична маршрутизація).

Виправлення: З боку принт‑сервера запустіть traceroute і перевірки портів до принтера. Виправте мережевий шлях сервер→принтер.

5) «Принтер інтермітентно друкує дублі або відновлює старі завдання»

Корінна причина: Raw 9100 з повторними спробами + ненадійний VPN може викликати повторну відправку; принтер не має надійного обліку завдань.

Виправлення: Віддавайте перевагу IPP із коректним статусом; зменшіть повтори; розмістіть локальний принт‑сервер біля принтерів.

6) «Працює в LAN, падає тільки коли віддалено»

Корінна причина: Split DNS, відсутні маршрути, політика VPN, що обмежує VLAN принтерів, або методи виявлення, які залежать від мультикасту.

Виправлення: Забезпечте друк через сервер, доступний по VPN; налаштуйте split DNS правильно; не покладайтеся на широкомовні виявлення між сайтами.

7) «Завдання зникають без сліду»

Корінна причина: Клієнт друкує безпосередньо на принтер без централізованих логів; принтер відкидає завдання через формат/ACL/пам’ять.

Виправлення: Централізуйте спулінг і логування; перевірте журнал принтера/адмін‑сторінку; підтвердіть драйвер і мову принтера (PCL/PS/PDF direct).

8) «Після оновлення VPN лише один офіс не може друкувати»

Корінна причина: Специфічна для сайту інкапсуляція/MTU тунелю; змінений крипто‑наклад; регрес у рекламі маршрутів.

Виправлення: Порівняйте MTU/MSS і маршрути між сайтами; проведіть контрольовані тести; застосуйте clamp або виправте розповсюдження маршрутів.

Проєктні рішення, які припиняють це назавжди (або майже)

Правило №1: Віддалені клієнти друкують на принт‑сервери, не в підмережі принтерів

Якщо ви візьмете одну принципову рекомендацію з цієї статті — візьміть цю.
Друк безпосередньо через VPN спокусливий, бо виглядає просто: менше серверів, менше рухомих частин.
На практиці це створює поверхню підтримки розміром з весь ваш парк кінцевих точок.

Розмістіть принт‑сервери там, де живуть принтери (та ж LAN або принаймні той самий сайт). Дозвольте VPN‑користувачам доступ лише до:
принт‑серверів на малому наборі портів (SMB 445, IPP 631, можливо HTTPS для управління).
Принт‑сервери звертаються до принтерів локально. Ви отримуєте спостережуваність, послідовні драйвери/рендеринг і менше сюрпризів з MTU.

Правило №2: Вибирайте протоколи свідомо

• IPP: найкращий дефолт для WAN, якщо підтримується; дає багатший статус і сучасні опції безпеки. Потребує коректного TLS і правил файрвола.
• SMB до Windows‑принт‑сервера: поширено в Windows‑орієнтованих організаціях; працює добре, коли DNS, час і політики чисті. Чутливий до змін політик жорсткості.
• Raw 9100: підходить для крайніх випадків і конкретних пристроїв; слабкий звіт статусу; повтори можуть викликати дублювання; безпека — це «надія».
• LPD: спадок; тримайте лише за потреби. Через VPN часто виникає питання «навіщо ми це досі використовуємо».

Правило №3: Моніторьте ланцюг, а не тільки пристрій

Моніторинг «принтер відповідає на ping» кращий за нічого і гірший, ніж ви думаєте.
Моніторьте:
глибину черги принт‑серверу, відсоток успішних бекенд‑підключень, досяжність портів принтера з сервера,
і стан тунелю VPN (латентність, втрата пакетів, MTU).
Якщо ви можете графічно відслідковувати «завдань у черзі > 5 хв», ви вловите відмови до того, як CFO спробує друкувати зарплату.

Правило №4: Зробіть MTU/MSS нудним

WAN‑збої друку часто — це мережеві розрахунки. IPsec додає наклад. GRE додає наклад. VLAN‑теги додають наклад.
Десь пристрій рве фрагменти або блокує ICMP «fragmentation needed», і PMTUD відмовляє.
Виправлення зазвичай — MSS clamping або послідовний MTU тунелю, а не новий драйвер принтера.

Правило №5: Централізована й консервативна стратегія драйверів

Якщо ви керуєте Windows‑принт‑серверами — контролюйте point‑and‑print і розгортання драйверів зі змістом.
Якщо ви використовуєте CUPS — стандартизуйте PPD/пакети драйверів і тримайте матрицю сумісності для поширених моделей.
Найгірша стратегія драйверів — «те, що користувач знайшов в інтернеті, коли був злий».

Чеклісти / покроковий план

Покроково: діагностика одного користувача, який «бачить, але не друкує»

1. Визначте шлях: безпосередньо на принтер чи через принт‑сервер? Отримайте URI принтера/ім’я шару.
2. Визначте протокол: SMB 445, IPP 631, raw 9100, LPD 515.
3. З джерела: перевірте маршрут до IP/підмережі призначення (ip route get).
4. Протестуйте порт: nc -vz до destination:port. Якщо падає — зупиніться і виправте мережу/політику.
5. Якщо принт‑сервер: з сервера перевірте досяжність IP/порту принтера. Підтвердіть маршрути і ACL.
6. Надішліть маленьке контрольоване завдання: однорядковий текст; зафіксуйте ID завдання.
7. Читайте логи: CUPS error_log або Windows Event Viewer/PrintService; шукайте таймаути, помилки автентифікації, збій бекенду.
8. Якщо «малі працюють, великі — ні»: тестуйте MTU/MSS і спостерігайте tcpdump; шукайте ретрансмісії/скидання.
9. Підтвердіть, що принтер приймає завдання: IPP‑атрибути або адмін‑інтерфейс принтера; перевірте статус hold/paused/error.
10. Тільки потім: розглядайте проблеми драйверів/рендерингу (невідповідність формату, PS vs PCL), якщо транспорт і доступ підтверджені.

Покроково: закріпіть середовище, щоб цей тикет більше не повторювався

1. Централізуйте спулінг: принт‑сервер на сайті поруч з принтерами; віддалі клієнти друкують тільки на сервер.
2. Обмежте правила файрвола: дозволяйте клієнтам VPN доступ до принт‑серверів; дозвольте принт‑серверу доступ до VLAN принтерів; блокуйте все інше за замовчуванням.
3. Стандартизовуйте протоколи: оберіть IPP (або SMB для Windows) як основний; документуйте винятки.
4. Виправте DNS і час: split DNS для внутрішніх імен; NTP/chrony послідовні для клієнтів і серверів.
5. Явно задайте MTU: налаштуйте MTU тунелю; застосуйте MSS clamping на краях; перевіряйте тестами.
6. Інструментуйте: глибина черги, рівень помилок завдань, перевірки доступності портів із серверів і метрики тунелів.
7. Рунбук: навчи хелпдеск припинити використовувати ping як доказ працездатності.

Чого не варто робити (бо це приємно, але нічого не вирішує)

• Не перевстановлюйте драйвери, поки не довели, що порт призначення досяжний кінцево‑до‑кінця.
• Не відкривайте VLAN принтерів широко для клієнтів VPN «тимчасово». Тимчасово — це шлях до привидів у мережі.
• Не покладайтеся на мультикаст‑виявлення через VPN, якщо ви не захоплюєтесь дебагом широкомовних доменів о 2‑й ночі.
• Не вважайте «працює на LAN HQ» доказом. Це зовсім інша мережа.

Питання та відповіді

1) Чому я можу пінгувати принтер через VPN, але не можу друкувати?

ICMP echo може бути дозволений, тоді як порти друку заблоковані. Або маршрут працює для ICMP, але не для реального TCP‑шляху через політики маршрутизації.
Тестуйте реальний порт (631/9100/445) з реального клієнта.

2) Чи варто дозволяти клієнтам VPN друкувати прямо на принтери?

Зазвичай ні. Це збільшує поверхню атаки і множить складність усунення несправностей.
Дозвольте клієнтам VPN доступ до принт‑серверів, а сервери нехай звертаються до принтерів локально.

3) Який протокол найкращий для друку між сайтами?

IPP загалом найкращий вибір для WAN, якщо підтримується і налаштований послідовно.
В Windows‑центрованих середовищах SMB через Windows‑принт‑сервер теж поширений і робочий — якщо DNS, час і політики чисті.

4) Чому малі завдання друкуються, а великі — ні?

Це класична поведінка MTU/MSS‑чорної діри або таймаут stateful‑пристрою для довгих трансферів.
Доведіть це тестами Path MTU і перехопленнями; виправте MSS clamping або MTU тунелю.

5) Який найшвидший спосіб довести, що це не драйвер?

З машини, що відправляє завдання, запустіть TCP‑connect тест до реального порту (nc -vz printer 631 або до принт‑серверу на 445/631).
Якщо TCP‑з’єднання не встановлюється — драйвери не ваша перша проблема.

6) Чому друк ламається після змін VPN або файрвола?

Бо друк використовує конкретні порти, довгі з’єднання і іноді автентифікаційні потоки, що залежать від DNS і часу.
Зміни VPN часто змінюють MTU, маршрути або політику в спосіб, який базовий веб‑перегляд не виявляє.

7) Як зрозуміти, чи відмова на боці клієнта чи сервера?

Відстежте, де застрягає завдання. Якщо воно ніколи не потрапляє в чергу принт‑серверу — це клієнт→сервер (автентифікація/мережа/спулер).
Якщо воно застрягає на сервері в стані «sending» — це сервер→принтер або відмова пристрою.

8) Що робити, якщо ми змушені підтримувати прямий друк (без принт‑серверів)?

Тоді ставтеся до принтерів як до production‑сервісів: присвойте стабільні IP, документуйте потрібні порти, моніторьте досяжність,
стандартизуйте драйвери і правильно виправляйте MTU/MSS. Прийміть також, що підтримка буде повільнішою, а інциденти гучніші.

9) Чи можна зробити «виявлення принтерів» через VPN надійним?

Можна форвардити мультикаст або запускати проксі виявлення, але це ускладнення з сумнівною користю.
Краще розгортайте через керовані інструменти (GPO/MDM) і використовуйте принт‑сервери з відомими іменами.

10) Чому принтери іноді тихо відхиляють завдання?

Невідповідність формату (PS/PCL/PDF direct), політика утримання завдань, вимоги автентифікації, заповнене сховище або навантаження пам’яті можуть викликати відмови.
Централізований спулінг з логами робить це видимим; при прямому друці часто слідів немає.

Висновок: наступні кроки, які можна виконати

Якщо ви застрягли в нескінченному циклі «бачу, але не друкує», перестаньте ставитися до друку як до магічного периферійного пристрою.
Це мережевий сервіс з протоколами, портами, автентифікацією і довготривалими потоками даних.
Підходьте до нього, як до будь‑якої іншої продукційної залежності: опишіть шлях, виміряйте шлях, логінуйте шлях.

1. Оберіть модель: клієнти VPN друкують на принт‑сервери; принт‑сервери друкують локально на пристрої.
2. Кодифікуйте дозволені потоки: клієнт → сервер порти; сервер → принтер порти. Усе інше заборонено.
3. Виправте MTU/MSS свідомо: clamp MSS або встановіть MTU тунелю; перевірте тестами; перестаньте гадати.
4. Інструментуйте і зробіть рукопис: глибина черги, журнали помилок і playbook на перші 15 хв для хелпдеску.
5. Стандартизуйте драйвери: зменшіть варіативність, зменшіть кількість тикетів і врятуйте майбутнього себе від гніву.

Зробіть це — і наступного разу, коли хтось скаже «але він онлайн», у вас буде краща відповідь, ніж перезавантажити принтер і молитися.