Windows 11で「IoT VLAN上のプリンタにだけ印刷できない」問題の原因と解決策まとめ

Windows 11からIoT VLANに置いたプリンタが「追加はできるのに印刷だけ失敗する」──しかもLinuxは普通に印刷できる。さらにCUPS（Pi上）経由でも、Web管理画面からのテスト印刷は通るのに、WindowsからCUPSプリンタとして登録すると失敗する。こうした現象は、プリンタ本体やドライバ不良というより、VLAN越え通信・名前解決・Windows側の印刷経路（プロトコル）・Windowsファイアウォール/ネットワークプロファイルが絡み合って起きることが多いです。

Windows 11で「IoT VLAN上のプリンタにだけ印刷できない」問題の原因と解決策まとめ

まず整理：今回の症状が示す「当たり所」

状況を分解すると、重要なヒントが揃っています。

Windowsはプリンタを“発見・追加”できる（＝探索や初期接続の一部は通っている）
LinuxはTrusted側からIoT VLANのプリンタへ印刷できる（＝ルーティング/ACLは最低限成立している）
Windows 11をIoT VLANに移すと印刷できる（＝プリンタ自体とWindowsドライバは完全に死んでいない）
CUPSのWeb UIからはIoT VLAN内で印刷できる（＝CUPS→プリンタはOK）
Windows（Trusted）→CUPS（IoT）登録だと失敗（＝Windows→CUPSの印刷通信が落ちている可能性）

この流れから、疑う順番はだいたい以下になります。

Windowsが使う印刷プロトコル/ポートがVLAN越えで塞がっている
Windowsのネットワークプロファイルが“Public”扱いで印刷関連がブロック
mDNS/WS-Discoveryなど“発見”はできても“印刷本番通信”が別経路で落ちる
CUPSをWindowsに追加したときの接続方式（IPP/LPD/RAW/SMB）が合っていない

最優先チェック：印刷で必要なポートを明示的に通す

プリンタは「見える」のに「印刷だけ失敗」というとき、最頻出がこれです。探索と印刷は別ポートを使います。

よく使われる印刷ポート（代表例）

RAW/JetDirect：TCP 9100（メーカーによっては9200系も話題に出ますが、まずは9100が鉄板）
IPP：TCP 631
LPD/LPR：TCP 515
SMB共有印刷：TCP 445（環境によっては危険度高めなので慎重に）
SNMP（状態取得）：UDP 161（印刷自体ではないが、Windowsが監視でこけるケースあり）
mDNS：UDP 5353（発見用）
WS-Discovery：UDP 3702（発見用）

ポイントは、ファイアウォールやVLAN間ACLで
「IoT VLAN → Trusted VLAN」ではなく「Trusted VLAN → IoT VLAN」へ、必要な宛先（プリンタIP or CUPS IP）に対して必要なポートだけを許可することです。
「一時的に全部許可したのにダメだった」という場合でも、実は“全部”がL3の話で、Windows側のローカルFWが落としていることもあるので、次の項目へ進みます。

Windows 11側の落とし穴：ネットワークプロファイルがPublicだと詰む

Windowsはネットワークを Private / Public で扱いを変えます。Public扱いだと印刷や探索がブロックされがちです。

確認ポイント

Windowsの「ネットワークのプロパティ」が プライベート になっているか
「ファイルとプリンターの共有」が許可されているか
Windows Defender Firewallで、該当ネットワークプロファイルに対して印刷関連がブロックされていないか

投稿内でも「Windows内部ファイアウォールが怪しい」「PublicだとFile and Printがブロック」という示唆があり、経験則的にも当たりやすい箇所です。
一時切り分けとしては、短時間だけWindowsファイアウォールを無効化して挙動が変わるか確認すると、原因がネットワーク側か端末側かが一気に分かれます（恒久対応は“無効化”ではなく例外ルールが基本）。

“発見できるのに印刷できない”を起こす mDNS/名前解決の罠

「プリンタ名で追加」「自動検出で追加」ができる場合、裏側で mDNS（Bonjour）やWS-Discovery に頼っていることがあります。ここがVLANを跨ぐと、発見だけ半端に成功して、実通信が別方式で転けることが起きます。

対策の考え方

VLAN越えでmDNSを使いたいなら、mDNSリフレクタ/リピータ（Avahi reflector等）を適切に配置
ただし、より堅牢なのは “プリンタをIP直指定で追加” して探索依存を減らすこと

この手のトラブルは「名前でつながっているように見えて、実際は別経路」といったズレが起点になりがちです。まずはIP直指定が切り分けとして強いです。

CUPS経由で失敗する場合：WindowsがCUPSへどう繋いでいるかを疑う

CUPSは優秀ですが、Windows側での追加方法によって成功率が変わります。
「CUPSのWeb UIからテスト印刷は通る」のに「WindowsからCUPSプリンタとして印刷が落ちる」なら、Windows→CUPS間で以下が起きがちです。

ありがちな失敗パターン

Windowsが IPPではなく別方式 でつないでいる（または自動認識が誤る）
CUPS側が受けるのはIPP(631)なのに、ACL/FWで631が塞がっている
Windowsがプリンタ状態取得（SNMP等）で失敗してジョブ送信まで行かない
ドライバが合わず、CUPS経由でもレンダリングが崩れる（ただし今回、同VLANなら印刷できたので優先度は少し下）

実務的に強い解決ルート

Windows側でプリンタ追加時に「自動検出」より
“TCP/IPアドレスまたはホスト名で追加” → “プロトコル/ポートを明示” を選ぶ
可能なら IPP（631） を第一候補として試す（CUPSはIPPが得意）
プリンタ監視が原因っぽいときは、Windowsのプリンタポート設定で
SNMPステータス有効 を一時的にオフにして切り分け

スプーラー詰まり・古いジョブが原因のケース

ネットワーク要因が濃厚でも、Windowsはスプーラーが変に固着して「何をやっても失敗」になることがあります。

Print Spoolerサービスの再起動
失敗ジョブの削除、スプールフォルダのクリア

これは根本原因ではないことも多いですが、切り分けの初動としては効果があり得ます。

最短で解くための「おすすめ切り分け順」

面倒な遠回りを避けるなら、次の順番が効率的です。

Windowsファイアウォールを短時間だけ無効化して印刷できるか
- できたら端末側設定（Private化や例外ルール）に寄せる
プリンタをIP直指定で追加し、プロトコルを固定（RAW 9100 or IPP 631）
- “発見”依存を捨てる
VLAN間ACLで、Trusted→IoTの必要ポートを明示許可
- プリンタIPまたはCUPS IPに限定して穴を最小化
mDNS/WS-Discoveryを跨がせたいならリフレクタ導入
- ただし運用上はIP直指定の方が安定することが多い
スプーラー再起動、ドライバ再インストール
- 最後に整える

セキュリティ面の注意点（IoT VLANに置いた意味を壊さない）

IoT VLANにプリンタを隔離した目的は「Trustedと完全に同等にしない」ことのはずです。
なので、対策は次の思想で組むのがおすすめです。

許可は Trusted → プリンタ（またはCUPS）への必要ポートだけ
可能なら 送信元はPCの固定IP に限定
SMB（445）など横展開リスクの高い経路は、必要性がないなら避ける
“一時的に全許可”で直ったら、最後に必ず絞る

まとめ：原因は「Windows特有の経路」と「プロファイル/ポート」の組み合わせが多い

今回の症状は、プリンタやCUPSが壊れているというより、**Windows 11が印刷時に使う通信（プロトコル/ポート）と、Windows側のネットワーク扱い（Public/Firewall）**が噛み合っていないパターンが濃厚です。

まずは、WindowsのネットワークをPrivateに寄せる・Windowsファイアウォールの影響を切り分ける・IP直指定でプロトコルを固定する。ここまでで多くは解消します。
そのうえで、VLAN間は「必要ポートだけ」開ける形に落とし込み、IoT隔離の効果を保ちながら快適に印刷できる構成にしていきましょう。