検出を使わずに VPN 経由でオフィスのプリンターに印刷する

自宅にいて、書類はオフィスのプリンターから出す必要があり、VPN はつながっているのに、プリンター追加の画面には何も表示されません。表示されないことはトンネルが壊れている証拠ではありません。検出はプリンターを見つける一つの仕組みにすぎず、設定済みのキューはまた別の仕組みです。ルーティングされた VPN は通常、後者を運び、前者は元の場所にそのまま残します。キューを手動で追加すれば、プリンターは「見つからない」状態を脱します。

順番に進め、失敗した最初の手順で止めてください。埋め合わせに新しいネットワーク設計を足してはいけません。

プリンターのニックネームではなく、キューを聞く

オフィスを管理している人から三つ確認します。利用者が機器に直接印刷するのかサーバー経由なのか、キューが対応するプロトコルは何か、設定すべき正確なアドレスまたは URI は何か。Upstairs Colour のような名前は人が機械を見つける助けにはなりますが、コンピューターには何も伝えません。三つの答えを書き留めてください。それが以後すべての受け入れ基準になります。

ほとんどのオフィスは二つの構成で足ります。プリンター自身が IPP を受け付ける場合は、標準の印刷パスで終わる URI に機器を直接設定します。プリントサーバーが名前付きキューを公開し、そのサーバーが背後にあるハードウェアへジョブを渡す場合は、使うアドレスはプリンターではなくサーバーのものです。どちらの例も説明のためのもので、まねをしてはいけません。実際に渡された URI を使ってください。

キューを明示的に追加する

CUPS を使う Linux クライアントでは、IPP Everywhere 対応の機器を一つのコマンドでキューに追加できます。ローカルプリンターを追加し、機器の URI を指し、ユニバーサルモデルを要求します: lpadmin -p Office_Printer -E -v ipp://10.20.30.15/ipp/print -m everywhere。管理ガイドには宛先、機器の URI、モデルのオプションが記載されており、このコマンドはローカルのキューだけに触れます。

このコマンドは経路を作らず、遠端で許可も与えません。だからこそ次の二つの節が必要です。他のクライアントでは対応するシステムの画面を使い、管理された Windows プリントサーバーでは、IPP のパスをでっち上げずに、渡されたサーバー名と共有名を使ってください。

名前解決、経路、戻り経路を確認する

キューのホスト名が目的のオフィスのアドレスに解決されることを確認し、次にノート PC がそのアドレスをトンネル経由でルーティングしていることを確認します。プリントサーバーと物理プリンターはアドレスも権限も異なることが多く、片方につながったからといってもう片方の証明にはなりません。

オフィス側には、クライアントの実際の送信元アドレスへの戻り経路が必要で、アクセスポリシーが選んだ印刷サービスを許可していなければなりません。両方が同時に成り立つ必要があります。戻り経路が欠けると、ジョブはノート PC を出たままどこにも届きません。

到達性とキューのポリシーを分けて考える

共有ポリシーは次の境界であり、到達性とは別の問いです。自分のサブネットにだけ共有された CUPS サーバーは、別の VPN プールから来るクライアントを、礼儀正しくログの上で拒否します。クライアント側には一般的な表示しか出ません。運用担当者には、印刷が必要な特定の遠隔利用者と送信元を許可してもらうべきです。キューをすべてのネットワークに開くのは、依頼に見合わないほど大きな変更であり、次のレビューで誰も感謝してくれません。

検出はまた別の話題です。マルチキャスト DNS はローカルリンクに限定されるため、ルーティングされた VPN はオフィスで見えるリストを埋め直しません。設定済みのキューはそのリストなしで動きますし、自動検出が本当に必要なら、プリンター一つのためにブリッジ VPN を作り直すのではなく、独自の設計が要ります。

小さなジョブを一つ送って結果を読む

短く機密性のないページを目的のキューに送り、キューがそれをどう扱ったかを確認します。ジョブは受け付けられる、認証のために保留される、機器での解放のために保留される、配信前に停止される、の四通りがあり、それぞれ担当が違います。

ノート PC 上で消える進行バーは、紙が動いた証拠ではありません。オフィスの誰かがまだジョブを解放したり受け取ったりする必要があるかもしれません。書類が重要なら、回るインジケーターではなく人に確認してください。