Imprimantes entre bureaux : Résoudre « Je le vois mais ça n’imprime pas » sur VPN

Un modèle mental pratique : voir une imprimante vs imprimer dessus

« Je la vois » n’est pas un test significatif. Cela signifie généralement une de ces choses :
l’appareil a répondu à un echo ICMP, l’interface de découverte Windows a trouvé une diffusion mDNS/WS-Discovery localement,
les partages du serveur d’impression sont visibles, ou un objet de connexion obsolète existe depuis le mois dernier.
Rien de tout cela ne prouve que le client peut compléter le chemin d’impression réel.

L’impression est une chaîne. Cassez n’importe quel maillon et l’utilisateur perçoit le même résultat : rien ne sort, file bloquée, ou « Erreur – Impression ».
Votre travail est d’identifier quel maillon a échoué :

• Découverte : comment l’utilisateur a trouvé l’imprimante (GPO, manuel, mDNS, WS-Discovery, LDAP, « Ajouter une imprimante »).
• Établissement de la connexion : poignée de main TCP et authentification au service d’impression (SMB, IPP, LPD, raw 9100).
• Spooling : où le travail est rendu et stocké (spouleur client vs serveur d’impression vs disque/mémoire de l’imprimante).
• Transport : les octets traversent le VPN, survivent aux subtilités MTU/MSS, et sont autorisés par le pare-feu/NAT.
• Acceptation côté appareil : l’imprimante accepte le travail et imprime (ou rejette silencieusement à cause du format, des ACLs ou des paramètres de fonctionnalités).

Sur VPN, la séparation la plus courante est : ICMP fonctionne, SMB/IPP ne fonctionne pas ; ou SMB fonctionne mais l’impression s’arrête en cours de flux ;
ou les travaux atteignent le serveur d’impression mais n’atteignent jamais l’appareil parce que le serveur d’impression ne sait pas router vers le sous-réseau de l’agence.

Citation à garder pour quand quelqu’un dit « mais il répond au ping » :
idée paraphrasée — Vint Cerf, sous de nombreuses formes au fil des ans : être capable d’envoyer des paquets ne signifie pas qu’on a une application fonctionnelle.

Playbook de diagnostic rapide (vérifier 1/2/3)

Vérification 1 : Où le travail est-il réellement spoulé ?

Déterminez si le client imprime directement vers l’imprimante (IPP/9100/LPD) ou via un serveur d’impression (Windows Print Server, CUPS).
Cette seule décision change tout l’arbre de dépannage.

• Si c’est un serveur d’impression : le client peut-il atteindre le serveur via le VPN ? Le serveur peut-il atteindre l’imprimante sur le LAN de l’agence ?
• Si c’est direct : le client peut-il atteindre l’IP de l’imprimante sur le port requis et soutenir un long transfert TCP ?

Vérification 2 : Testez le vrai protocole d’impression, pas le ping

Identifiez le protocole et le port :
l’impression SMB implique typiquement le TCP 445 vers le serveur (puis le serveur parle à l’imprimante).
L’IPP utilise généralement le TCP 631.
JetDirect raw est TCP 9100.
LPD est TCP 515.
Ensuite testez ce port de bout en bout depuis la machine qui initie le travail.

Vérification 3 : Cherchez les signes de « plantage en cours de travail » (MTU/MSS, timeouts pare-feu stateful)

Une page ou deux s’impriment, puis ça bloque ? Ou des pages tests petites passent mais des PDFs volumineux jamais ?
C’est généralement de la fragmentation MTU, des problèmes de clamp MSS TCP, ou un pare-feu/NAT stateful qui expire les flux longue durée.
L’impression est essentiellement un « transfert de données en masse avec de l’attitude ».

Fiche de classification rapide

• File bloquée côté client : spouleur/driver/authentification client vers serveur d’impression.
• File bloquée côté serveur : connectivité serveur→imprimante, rendu/driver sur le serveur, ACLs de l’imprimante.
• Le travail disparaît : l’imprimante rejette le format, politique d’imprimante supprime, ou le serveur d’impression réessaie puis abandonne.
• Sortie partielle : MTU/MSS, VPN instable, DPI/IPS qui manipule IPP/SMB, ou limites mémoire/stockage de l’imprimante.

Blague n°1 : Le ping est l’équivalent imprimante de faire signe à quelqu’un à travers une fenêtre — joli geste, pas un contrat de service.

Faits intéressants et contexte historique (les plus grands succès de l’impression)

• Port brut 9100 (JetDirect) est devenu populaire parce que c’est d’une simplicité désarmante : ouvrir TCP, streamer des octets, croiser les doigts. La sécurité n’était pas la priorité.
• LPD/LPR remonte aux premières journées UNIX et subsiste dans beaucoup d’imprimantes parce que les fabricants détestent retirer la « compatibilité héritée ».
• IPP (Internet Printing Protocol) a été conçu pour être plus adapté à Internet que LPD, et il utilise la sémantique HTTP — excellent pour les WAN quand c’est configuré correctement.
• L’impression Windows s’appuyait historiquement sur SMB/RPC et la distribution de drivers. Pratique en interne et pénible sur des liaisons contraintes.
• Découverte Bonjour/mDNS a fait que les imprimantes « apparaissent simplement » sur les réseaux locaux — puis a semé la confusion quand les VPN ne transmettent pas le multicast.
• PostScript vs PCL furent autrefois des guerres religieuses ; aujourd’hui c’est surtout « quel driver empêche ce PDF d’exploser ».
• Les vendeurs d’imprimantes ont ajouté du stockage embarqué pour le spooling et la rétention de travaux ; quand ce disque se remplit, les imprimantes peuvent échouer de manières qui ressemblent à des problèmes réseau.
• Durcissement SMB la dernière décennie (signage, chiffrement, dépréciations) a amélioré la sécurité mais accru la fragilité inter-sites si les configurations sont incohérentes.
• Les changements post-PrintNightmare ont poussé les organisations à repenser les installations de drivers et les politiques point-and-print ; l’impression sur VPN a cassé de nouvelles façons créatives.

Carte des pannes : où « je la vois » casse

1) La découverte ment (ou du moins exagère)

Les utilisateurs « voient » des imprimantes via des objets mis en cache, d’anciennes mappings GPO, ou une liste de partages du serveur d’impression. Cela ne garantit pas :
que les identifiants sont valides, que le serveur est joignable sur le bon chemin réseau, ou que l’imprimante derrière le serveur est en ligne.

2) Le routage VPN et le split tunneling ne sont pas neutres

Le split tunnel est génial jusqu’à ce que le serveur d’impression soit « interne » mais la plage d’IP des imprimantes soit « agence », et que le client fasse du hairpin incorrectement.
Ou le DNS renvoie une adresse interne que le client ne peut pas router.
Ou le VPN n’envoie pas les routes pour les VLANs d’imprimantes parce que quelqu’un a décidé que « les imprimantes sont peu risquées ».
(Elles ne le sont pas. Elles exécutent des OS complets et stockent des documents. En plus, elles sont exigeantes.)

3) Les politiques de pare-feu autorisent souvent ICMP mais bloquent les ports d’impression

Il est courant de voir ICMP autorisé pour le dépannage, tandis que TCP 9100/631/515/445 est refusé sur le VPN.
Ce n’est pas automatiquement une erreur — imprimer entre sites est une décision de sécurité — mais c’est la raison classique pour laquelle « je peux pinguer » devient un piège.

4) MTU/MSS et problèmes de fragmentation apparaissent comme « les travaux d’impression plantent »

Les flux d’impression peuvent être volumineux et longue durée. Le surcoût IPsec, l’encapsulation GRE, ou un réglage MTU trop ambitieux peuvent créer des trous noirs où
les petits paquets passent et les plus gros disparaissent. Vous obtenez des impressions partielles, des files bloquées et le comportement intermittent « marche pour la page test ».

5) L’authentification et l’identité se cassent entre domaines et tunnels

L’impression SMB via un serveur d’impression Windows peut échouer parce que le client ne peut pas obtenir de tickets Kerberos (DNS/mappage AD de site),
les horloges dérivent, ou NTLM est restreint. L’imprimante apparaît, les travaux sont soumis, puis vous obtenez accès refusé ou échecs silencieux.

6) Les drivers et le rendu peuvent échouer sans erreurs évidentes

Le VPN rend les liens lents. Les liens lents font que les drivers et les spouleurs expirent.
De plus, les drivers « universels » sont parfois universels comme du ruban adhésif : ça marche jusqu’à ce que ça ne marche vraiment plus.

Tâches pratiques : commandes, sorties, décisions (12+)

Ces tâches supposent que vous êtes SRE/opérateur avec accès à une passerelle Linux, un serveur d’impression (CUPS Linux ou Windows),
et éventuellement un poste utilisateur. L’objectif est de réduire l’impression à des états réseau et spool mesurables.
Chaque tâche inclut : commande, ce que signifie la sortie, et la décision que vous prenez.

Task 1: Confirm the route to the printer subnet (from the actual origin)

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

Sens : le trafic vers l’IP de l’imprimante passe par l’interface VPN (tun0) et le bon gateway.
Si vous voyez une passerelle locale ou une interface publique, votre split-tunneling est mal configuré.

Décision : Si la route est incorrecte, corrigez les routes poussées par le VPN / la table de routage du client avant de toucher aux imprimantes ou drivers.

Task 2: Verify DNS resolves the print server the way the VPN expects

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

Sens : le nom résout vers une IP interne. Si cela résout vers autre chose (ou pas du tout), votre client peut utiliser le DNS public.

Décision : Corrigez les paramètres DNS du VPN / split DNS. Ne durcissez pas les IPs sauf si vous aimez les incidents récurrents.

Task 3: Test the real printing port (IPP 631) instead of ping

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

Sens : la poignée de main TCP a réussi. Si ça timeoute, c’est routage/pare-feu/politique VPN, pas un driver.

Décision : Si bloqué, ouvrez les ports requis sur le chemin VPN/pare-feu ou migrez vers un modèle avec serveur d’impression.

Task 4: Test raw printing (JetDirect 9100) connectivity

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

Sens : le socket brut d’impression est joignable. Si 631 échoue mais 9100 passe, vous êtes sur un chemin de code différent (et probablement des règles de pare-feu différentes).

Décision : Préférez IPP pour la gérabilité quand c’est possible ; utilisez 9100 seulement si vous acceptez « moins de contrôle, plus de mystère ».

Task 5: Confirm the VPN path MTU (find the blackhole)

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

Sens : le Path MTU supporte ~1400 octets sans fragmentation. Si vous voyez « Frag needed » ou des timeouts à de plus grandes tailles, vous avez un problème MTU.

Décision : Appliquez un clamp MSS sur le VPN/pare-feu, baissez le MTU du tunnel, ou corrigez le filtrage PMTUD.
Ne « corrigez » pas cela en changeant de driver. Vous déplacerez seulement le problème.

Task 6: Check for stateful firewall/NAT timeouts (watch a stream)

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

Sens : la poignée de main réussit. Si plus tard vous voyez des retransmissions, des RSTs, ou de longs écarts, suspectez des middleboxes.

Décision : Si les sessions sont réinitialisées après N secondes, ajustez les timers de session du pare-feu ou routez via un serveur d’impression plus proche de l’imprimante.

Task 7: On CUPS server, list printers and confirm 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

Sens : CUPS sait où il envoie les travaux. Une IP erronée ici peut persister des mois parce que les imprimantes « bougent » et personne ne met à jour l’URI.

Décision : Si l’URI pointe vers un ancien sous-réseau, corrigez-la (lpadmin -p ... -v ...) et retentez avant de déboguer le VPN.

Task 8: On CUPS server, inspect queue state and job behavior

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

Sens : « idle » suggère que CUPS n’est pas actuellement bloqué. S’il indique « paused » ou « stopped », c’est administratif ou déclenché par une erreur.

Décision : Si en pause, lisez le journal d’erreurs et réactivez. Ne resoumettez pas les travaux dans une file en pause.

Task 9: Send a controlled test print (small, known-good)

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

Sens : Le travail est accepté par le spouleur. Si l’utilisateur imprime d’abord un PDF de 200 pages, vous n’apprendrez rien sauf la patience de vos files.

Décision : Si les petits travaux marchent mais les gros échouent, pivotez vers MTU/timeouts/limites de spooling.

Task 10: Tail CUPS error log while printing to catch protocol-level failures

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)

Sens : Ce n’est pas un problème de driver. C’est un timeout de connexion vers le port IPP de l’imprimante depuis le serveur.

Décision : Corrigez le routage/pare-feu du serveur CUPS vers le sous-réseau de l’imprimante, ou placez l’imprimante derrière un proxy d’impression local.

Task 11: Validate that the print server can reach the printer (not just the client)

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

Sens : Il y a un chemin routé réel. S’il meurt au hop 2 ou 3, votre route site-à-site n’est pas présente là où vous le pensez.

Décision : Corrigez le chemin réseau du serveur d’impression vers les VLANs de l’agence ; ne perdez pas de temps à réinstaller les imprimantes client.

Task 12: On Linux, check for local firewall rules blocking outbound printing

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
  }
}

Sens : La politique de sortie est accept ; l’entrée autorise 631. Si vous aviez une politique de sortie drop, vous pourriez bloquer silencieusement la connexion backend.

Décision : Si la sortie est restreinte, autorisez explicitement tcp dport 631/9100 vers les sous-réseaux d’imprimantes.

Task 13: Check Windows print server share reachability (SMB) from a Linux box

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

Sens : La connectivité SMB et l’authentification fonctionnent ; les partages sont visibles. Si cela échoue, les clients ne se connecteront pas non plus de manière fiable.

Décision : Si l’authentification échoue, vérifiez la connectivité AD sur le VPN, la synchronisation temporelle, et les politiques NTLM/Kerberos.

Task 14: Confirm Kerberos time skew (classic “works on LAN, fails on 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

Sens : L’horloge est synchronisée. Si l’horloge du client ou du serveur dérive, Kerberos échoue et l’impression via SMB peut se dégrader en tentatives répétées ou accès refusé.

Décision : Réparez NTP/chrony/la source AD de temps d’abord. Ne désactivez pas Kerberos « pour que l’impression marche ». C’est comme ça qu’on crée un incident de sécurité papier.

Task 15: Check MSS clamping on the VPN edge (when big jobs hang)

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

Sens : Le MSS est clampé sur le PMTU pour les SYNs forwardés. Si cette règle manque dans un environnement IPsec/GRE, les gros flux peuvent tomber dans un trou noir.

Décision : Ajoutez le clamp MSS (ou l’équivalent sur votre firewall/équipement VPN) plutôt que de baisser des MTU aléatoires sur les endpoints.

Task 16: Look for printer-side refusal (IPP response codes)

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

Sens : L’imprimante accepte les travaux et répond aux requêtes IPP. Si elle indique qu’elle n’accepte pas les travaux, est en pause, ou retourne des erreurs d’autorisation, c’est une configuration de l’appareil.

Décision : Corrigez la politique de l’imprimante (ACLs, auth, retenue de travaux) ou mettez à jour les identifiants si vous utilisez IPP avec authentification.

Blague n°2 : Les imprimantes sont les seuls appareils « IoT » capables de coincer votre journée puis de vous demander de recharger leur cyan émotionnel.

Trois mini-récits d’entreprise depuis le terrain

Incident causé par une mauvaise hypothèse : « Si je peux le pinguer, le port est ouvert. »

Une entreprise multi-sites a déployé un nouveau client VPN avec une « posture de sécurité plus propre ». Traduction : moins de routes, règles de pare-feu plus strictes,
et une belle interface qui a convaincu la direction que le problème était résolu par conception.
Le lendemain matin, le personnel d’agence pouvait « voir » les imprimantes dans la liste Windows d’ajout d’imprimante (mise en cache d’avant) et pouvait pinguer les IPs des imprimantes.
L’impression échouait partout.

La réponse initiale fut prévisible : réinstaller les drivers, enlever/rajouter les imprimantes, redémarrer les spouleurs, redémarrer les imprimantes, et — parce que c’est la vie en entreprise — redémarrer l’espoir.
Rien n’a changé. Les travaux restaient en « Spooling » ou « Printing » pour toujours. Le helpdesk commença à collectionner des captures d’écran comme s’ils montaient une expo d’art.

La mauvaise hypothèse était que le succès ICMP impliquait le succès des politiques. Le firewall VPN avait une règle autorisant ICMP vers les « sous-réseaux internes »
pour le dépannage, mais TCP 9100 et 631 n’étaient pas autorisés depuis les clients VPN vers les VLANs d’imprimantes. Ce n’était pas malveillant.
C’était juste l’idée de principe du moindre privilège exécutée sans modèle de menace pour l’impression.

La correction fut double : autoriser les clients VPN à atteindre les serveurs d’impression, pas les VLANs d’imprimantes ; puis s’assurer que seuls les serveurs d’impression pouvaient atteindre les imprimantes.
L’équipe réécrivit aussi le runbook : « Ping est optionnel ; testez toujours le port réel. » Vous auriez presque entendu la tension collective baisser.

Optimisation qui a échoué : « Évitons le serveur d’impression et imprimons direct. »

Une autre organisation voulait « réduire les dépendances » et « supprimer les points de défaillance uniques », ils ont donc poussé des installations directes vers l’imprimante.
Les utilisateurs se connectaient aux imprimantes par IPP ou TCP brut, même depuis leur domicile via VPN. Sur une slide, c’était brillant.
Pas de maintenance de serveur d’impression, pas de distribution de drivers, pas de drame de gestion de file.

Ça a marché — jusqu’à ce que ça ne marche plus. Les premières fissures furent subtiles : les petits travaux imprimaient, les gros s’arrêtaient.
Puis le gros problème : une mise à jour de firmware changea les paramètres TLS par défaut de l’imprimante, et les anciens clients ne purent plus négocier.
La moitié du parc devint indisponible pour le personnel distant. Localement, l’équipe bureau pouvait toujours imprimer car leur chemin LAN ne traversait pas les middleboxes VPN.

L’« optimisation » a aussi multiplié le rayon d’impact. Au lieu de corriger une configuration de serveur d’impression, ils durent supporter un zoo de clients :
différents OS, différentes versions de drivers, différentes réalités MTU, différents profils VPN. Le dépannage devint un exercice de comparaison du chaos.

Ils reconstruisirent finalement autour d’un petit nombre de serveurs d’impression par région, plus une règle stricte :
les clients VPN n’impriment que vers des serveurs d’impression, jamais directement vers les sous-réseaux d’imprimantes.
Pas parce que les utilisateurs ne sont pas dignes de confiance (bien que), mais parce que les réseaux se comportent mieux quand le saut longue distance est contrôlé et observable.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « Serveurs d’impression proches des imprimantes, logs conservés, et un job de test. »

Une troisième entreprise avait une habitude qui semblait peu glamour : chaque bureau avait une petite VM exécutant CUPS (ou un serveur d’impression Windows),
placée sur le même LAN que les imprimantes. Les utilisateurs distants imprimaient vers ce serveur via VPN. Le serveur imprimait localement.
Pas de découverte multicast. Pas d’impression directe depuis les clients distants. Pas d’improvisation.

Lorsqu’un changement VPN introduisit un décalage MTU, les utilisateurs commencèrent à se plaindre que les PDFs bloquaient en cours de travail.
L’équipe ne toucha pas un seul driver au début. Ils vérifièrent les logs CUPS et virent des motifs « connection reset by peer » constants sur les longs travaux,
mais seulement pour le site dont l’encapsulation du tunnel avait changé.

Parce que la conception gardait le trafic d’impression local, ils n’eurent qu’à rendre le chemin VPN fiable pour le client vers le serveur,
ce qui était plus simple : une IP, un ensemble de ports, et une surveillance cohérente. Ils appliquèrent le clamp MSS sur le bord VPN,
vérifièrent avec des impressions contrôlées, et l’incident se termina sans rituel de réimage du parc.

La pratique n’était pas innovante. Elle était simplement correcte. En ops, l’ennuyeux est une caractéristique.

Erreurs courantes : symptôme → cause racine → correction

1) « L’imprimante montre en ligne, les travaux restent en ‘Printing’ »

Cause racine : Port bloqué (TCP 631/9100/445) sur le VPN ; ICMP autorisé, donc tout le monde est trompé.

Correction : Testez avec nc -vz. Ouvrez le port spécifique depuis la source correcte (client→serveur ou serveur→imprimante).
Mieux : restreindre les clients aux seuls serveurs d’impression.

2) « La page de test s’imprime, les PDFs non »

Cause racine : trou noir MTU/MSS, timeout d’un appareil stateful, ou DPI/IPS qui interfère avec les flux longs.

Correction : Tests Path MTU avec ping -M do ; activer le clamp MSS ; ajuster les timers de session ; éviter l’impression directe sur VPN.

3) « L’utilisateur peut ajouter l’imprimante mais obtient accès refusé en imprimant »

Cause racine : problème d’auth (Kerberos via VPN, restrictions NTLM, identifiants obsolètes) ou permissions de partage d’imprimante.

Correction : Validez DNS/synchronisation temporelle ; confirmez l’accès SMB aux partages ; corrigez les ACLs et les hypothèses de confiance de domaine.

4) « La file du serveur d’impression montre des travaux bloqués en ‘Sending data’ »

Cause racine : Le serveur d’impression ne peut pas atteindre le sous-réseau de l’imprimante (route manquante, pare-feu, routage asymétrique).

Correction : Depuis le serveur d’impression, lancez traceroute et des vérifications de port vers l’imprimante. Corrigez le chemin réseau serveur→imprimante.

5) « L’imprimante imprime parfois des doublons ou reprend de vieux travaux »

Cause racine : Raw 9100 avec retries + VPN instable peut provoquer des renvois ; l’imprimante manque d’un comptage robuste des travaux.

Correction : Préférez IPP avec statut approprié ; réduisez les retries ; placez un serveur d’impression local aux imprimantes.

6) « Marche sur LAN, échoue uniquement à distance »

Cause racine : Split DNS, routes manquantes, politique VPN limitant les VLANs d’imprimantes, ou méthodes de découverte reposant sur le multicast.

Correction : Forcez l’impression via un serveur accessible sur VPN ; configurez correctement le split DNS ; arrêtez de compter sur les broadcasts entre sites.

7) « Les travaux disparaissent sans trace »

Cause racine : Impression client directe vers l’imprimante sans logs centralisés ; l’imprimante supprime les travaux à cause du format/ACL/mémoire.

Correction : Centralisez le spooling et les logs ; vérifiez le journal/console d’administration de l’imprimante ; validez le driver et le langage imprimante (PCL/PS/PDF direct).

8) « Après une mise à jour VPN, une seule agence ne peut plus imprimer »

Cause racine : encapsulation/MTU spécifique au site ; changement de crypto/surcoût ; régression d’annonce de routes.

Correction : Comparez MTU/MSS et routes entre sites ; utilisez des tests contrôlés ; appliquez le clamp ou corrigez la distribution des routes.

Choix de conception qui empêchent ça pour toujours (ou presque)

Règle n°1 : Les clients distants impriment vers des serveurs d’impression, pas vers les VLANs d’imprimantes

Si vous devez retenir une seule chose de cet article, retenez celle-ci.
L’impression directe vers l’imprimante sur VPN est séduisante car elle paraît simple : moins de serveurs, moins d’éléments en mouvement.
En pratique, cela crée une surface de support de la taille de tout votre parc d’endpoints.

Placez les serveurs d’impression où se trouvent les imprimantes (même LAN, ou au moins même site). Autorisez ensuite les utilisateurs VPN à atteindre seulement :
le(s) serveur(s) d’impression sur un petit ensemble de ports (SMB 445, IPP 631, peut-être HTTPS pour la gestion).
Les serveurs d’impression atteignent les imprimantes localement. Vous obtenez de l’observabilité, des drivers/rendus cohérents, et moins de surprises MTU.

Règle n°2 : Choisissez les protocoles intentionnellement

• IPP : meilleur choix par défaut pour le WAN si supporté ; offre plus de statut et d’options de sécurité modernes. Nécessite toujours TLS et politiques de pare-feu correctes.
• SMB vers un serveur Windows : courant dans les environnements Windows ; fonctionne bien quand AD/DNS/temps sont propres. Sensible aux changements de durcissement de politiques.
• Raw 9100 : bon pour les derniers recours et les bizarreries d’appareils ; faible retour de statut ; les retries peuvent causer des doublons ; sécurité « espérons que ça suffise ».
• LPD : legacy ; ne le gardez que si nécessaire. Sur VPN c’est souvent une conversation « pourquoi fait-on ça ».

Règle n°3 : Surveillez la chaîne, pas seulement l’appareil

Surveiller « l’imprimante répond au ping » est mieux que rien et pire que vous ne le pensez.
Surveillez :
la profondeur des files des serveurs d’impression, les taux de succès des connexions backend, la joignabilité des ports d’imprimante depuis le serveur,
et la santé du tunnel VPN (latence, perte de paquets, MTU).
Si vous pouvez grapher « travaux bloqués > 5 minutes », vous détecterez les pannes avant que le CFO n’essaie d’imprimer la paie.

Règle n°4 : Rendez le MTU/MSS ennuyeux

Les échecs d’impression WAN sont souvent des mathématiques réseau. IPsec ajoute du surcoût. GRE ajoute du surcoût. Les tags VLAN ajoutent du surcoût.
Quelque part, un appareil laisse tomber des fragments ou bloque les messages ICMP « fragmentation nécessaire », et PMTUD échoue.
La correction est généralement le clamp MSS ou un MTU de tunnel cohérent, pas un nouveau driver d’imprimante.

Règle n°5 : Gardez une stratégie de drivers centralisée et prudente

Si vous exécutez des serveurs d’impression Windows, contrôlez le point-and-print et le déploiement des drivers avec intention.
Si vous exécutez CUPS, standardisez les PPDs/packages drivers et maintenez une matrice de compatibilité pour vos modèles courants.
La pire stratégie de drivers est « ce que l’utilisateur a trouvé sur internet quand il était en colère ».

Checklists / plan étape par étape

Étape par étape : diagnostiquer un utilisateur qui « le voit mais n’imprime pas »

1. Identifier le chemin : direct-to-printer ou via serveur d’impression ? Obtenez l’URI de l’imprimante/nom du partage.
2. Identifier le protocole : SMB 445, IPP 631, raw 9100, LPD 515.
3. Depuis l’origine : vérifiez la route vers l’IP/destinataire (ip route get).
4. Testez le port : nc -vz vers destination:port. Si ça échoue, arrêtez et corrigez réseau/politique.
5. Si serveur d’impression : depuis le serveur, testez la joignabilité vers l’IP/port de l’imprimante. Confirmez routes et ACLs.
6. Envoyez un petit travail contrôlé : une ligne de texte ; capturez l’ID du job.
7. Lisez les logs : CUPS error_log ou Event Viewer/PrintService Windows ; cherchez timeouts, erreurs d’auth, échecs backend.
8. Si « petit marche, gros échoue » : testez MTU/MSS et observez avec tcpdump ; cherchez retransmissions/resets.
9. Confirmez que l’imprimante accepte les travaux : attributs IPP ou interface admin de l’imprimante ; vérifiez état hold/paused/error.
10. Ensuite seulement : envisagez les problèmes de driver/rendu (mismatch format, PS vs PCL) si transport et accès sont prouvés.

Étape par étape : durcir votre environnement pour que ce ticket cesse de revenir

1. Centralisez le spooling : serveurs d’impression par site proches des imprimantes ; les clients distants impriment uniquement vers ces serveurs.
2. Contraintez les règles de pare-feu : autorisez les clients VPN vers les serveurs d’impression ; autorisez les serveurs d’impression vers les VLANs d’imprimantes ; bloquez le reste par défaut.
3. Standardisez les protocoles : choisissez IPP (ou SMB vers serveurs Windows) comme principal ; documentez les exceptions.
4. Corrigez DNS et temps : split DNS pour les noms internes ; NTP/chrony cohérents sur clients VPN et serveurs.
5. Rendez le MTU explicite : configurez le MTU du tunnel ; appliquez le clamp MSS sur les bords ; validez avec des tests.
6. Instrumentez : profondeur des files, taux d’erreurs de jobs, vérifications de joignabilité des ports depuis les serveurs, et métriques de santé des tunnels.
7. Runbook : formez le helpdesk à arrêter d’utiliser le ping comme preuve de vie.

Ce qu’il ne faut pas faire (parce que ça fait du bien mais ne résout rien)

• Ne réinstallez pas les drivers avant d’avoir prouvé que le port de destination est joignable de bout en bout.
• N’ouvrez pas largement les VLANs d’imprimantes aux clients VPN « temporairement ». Le temporaire, c’est la façon dont les réseaux sont hantés.
• Ne dépendez pas de la découverte multicast via VPN à moins d’aimer déboguer des domaines de broadcast à 2 h du matin.
• N’acceptez pas « marche chez moi au LAN HQ » comme preuve. C’est un réseau différent.

FAQ

1) Pourquoi je peux pinguer l’imprimante via VPN mais pas imprimer ?

L’ICMP echo peut être autorisé tandis que les ports d’impression sont bloqués. Ou le routage est correct pour l’ICMP mais pas pour le chemin TCP réel à cause du routage politique.
Testez le port réel (631/9100/445) depuis le client réel.

2) Devons-nous autoriser les clients VPN à imprimer directement vers les imprimantes ?

Habituellement non. Cela augmente la surface d’attaque et multiplie la complexité de dépannage.
Autorisez les clients VPN à atteindre des serveurs d’impression, et laissez les serveurs parler aux imprimantes sur les LAN locaux.

3) Quel protocole est le meilleur pour imprimer entre sites ?

IPP est généralement le meilleur choix pour le WAN quand il est supporté et configuré de façon cohérente.
Dans les environnements centrés Windows, l’impression SMB via un serveur Windows est aussi courante et praticable — si DNS, temps et politiques sont propres.

4) Pourquoi les petits travaux s’impriment mais les gros échouent ?

C’est le comportement classique d’un trou noir MTU/MSS ou d’un appareil stateful qui timeoute les transferts longs.
Prouvez-le avec des tests Path MTU et des captures ; corrigez avec clamp MSS ou corrections de MTU de tunnel.

5) Quelle est la façon la plus rapide de prouver que ce n’est pas un driver ?

Depuis la machine qui envoie le travail, lancez un test de connexion TCP vers le port réel (nc -vz printer 631 ou vers le serveur d’impression sur 445/631).
Si vous ne pouvez pas établir une connexion TCP, les drivers ne sont pas votre premier problème.

6) Pourquoi l’impression casse après des changements VPN ou pare-feu ?

Parce que l’impression utilise des ports spécifiques, des connexions longue durée, et parfois des flux d’authentification dépendants de DNS et du temps.
Les changements VPN modifient souvent le MTU, le routage, ou les règles politiques de façons que la navigation basique n’expose pas.

7) Comment savoir si l’échec est côté client ou côté serveur ?

Suivez où le travail est bloqué. Si le travail n’atteint jamais la file du serveur, c’est client→serveur (auth/réseau/spouleur).
Si c’est bloqué sur le serveur en « sending », c’est connectivité serveur→imprimante ou refus côté appareil.

8) Que faire si nous devons absolument supporter l’impression directe (aucun serveur d’impression autorisé) ?

Traitez alors les imprimantes comme des services de production : attribuez des IP stables, documentez les ports requis, surveillez la joignabilité, standardisez les drivers,
et corrigez MTU/MSS correctement. Acceptez aussi que le support soit plus lent et que les incidents soient plus bruyants.

9) La « découverte d’imprimante » via VPN peut-elle être fiabilisée ?

Vous pouvez forwarder le multicast ou exécuter des proxys de découverte, mais c’est de la complexité pour une valeur douteuse.
Préférez le déploiement géré (GPO/MDM) et des serveurs d’impression avec des noms connus.

10) Pourquoi les imprimantes rejettent parfois les travaux silencieusement ?

Mismatch de format (PS/PCL/PDF direct), paramètres de politique de travail, exigences d’authentification, stockage plein, ou pression mémoire peuvent provoquer des suppressions.
Le spooling centralisé avec logs rend cela visible ; l’impression directe souvent non.

Conclusion : prochaines étapes réalisables

Si vous êtes coincé dans la boucle sans fin « je le vois mais ça n’imprime pas », arrêtez de traiter l’impression comme un périphérique magique.
C’est un service réseau avec des protocoles, des ports, de l’authentification et des flux de données longue durée.
Traitez-le comme toute autre dépendance de production : définissez le chemin, mesurez le chemin, loggez le chemin.

1. Choisissez le modèle : les clients VPN impriment vers des serveurs d’impression ; les serveurs d’impression impriment localement vers les appareils.
2. Codifiez les flux autorisés : ports client → serveur ; ports serveur → imprimante. Tout le reste refusé.
3. Corrigez MTU/MSS intentionnellement : clamp MSS ou définissez MTU du tunnel ; vérifiez avec des tests ; arrêtez de deviner.
4. Instrumentez et faites un runbook : profondeur des files, logs d’erreurs, et un playbook des 15 premières minutes que votre helpdesk peut suivre.
5. Standardisez les drivers : réduisez la variabilité, réduisez les tickets, réduisez la colère de votre futur vous.

Faites cela, et la prochaine fois que quelqu’un dira « mais elle est en ligne », vous aurez une meilleure réponse que de redémarrer l’imprimante et prier.