SMBクライアントとしてのルーターとパケット転送装置：どちらが適切か

SMBトラフィックを転送することは、それを終端することと同じ作業ではなく、片方を担うルーターがもう片方を扱えるとは限りません。転送とは、ルーターが中身を一度も解析しないパケットを動かすことです。マウントとは、ルーターがファイルクライアントになることであり、同梱していないかもしれないソフトウェア、守るべき資格情報、そして今や自分のものとなった障害モードを抱えます。どちらを選ぶかは、ファイルがどこで必要かという問いであり、ルーティング基盤に何をインストールさせられるかという問いではありません。

転送と終端は別の作業

転送の役割でルーターが負う責任は一つ、経路が要求するポリシーを適用しながらクライアントとサーバーの間でパケットを届けることです。共有に対して認証せず、ファイルデータをキャッシュせず、サーバーがSMB2を話すかSMB3を話すかも気にしません。ストリームのそこまで深く読まないからです。共有に到達できなくなれば、利用者にはエラーが見え、ルーターはルーティングを続けます。

クライアントの役割では、ルーターがプロトコルの会話に加わります。ダイアレクトを交渉し、認証し、名前を解決し、マウントポイントを保持し、その上で動くすべてにローカルのファイルシステム像を提示します。これはライフサイクルを持つ本物のサービスであり、ゲートウェイをファイル作業フローの依存先に変えます。さらにその依存先のあらゆる障害モードを引き継ぎます。起動時の待ちや古い資格情報も含まれます。

比較は能力だけの話ではありません。共有をマウントできる基盤が、そうすべき基盤であるとは限らず、マウントできない基盤が依然としてトラフィックをルーティングする正しい場所であり得ます。

カーネルのCIFSマウントに実際に必要なもの

Linuxベースの機器では、カーネルのCIFSクライアントとユーザー空間のクライアントは別々の能力であり、小さなイメージにはどちらも入っていないことがよくあります。カーネル対応が動作中のイメージにあり、マウントヘルパーが存在し、サーバーと交渉するSMBダイアレクトが双方の受け入れるものでなければなりません。それについてはLinux CIFSクライアントのガイドがカーネルの仕組みとマウントオプションを説明しており、ベンダーのビルドに含まれると決めつける前の正しい参照先です。

能力の周りで設計する前にその有無を確認し、コマンド名の存在ではなくバージョンを確認してください。パッケージ一覧のモジュール名は、動作するクライアントと同じではありません。

lsmod | grep -w cifs
modinfo cifs | head -5
mount.cifs --version
smbclient -L //fs02.corp.internal -U svc-router -m SMB3

読み込まれるカーネルモジュールとバージョンを報告するユーザー空間ツールがあっても、マウントがVPNの鍵更新を生き延びる保証にはなりません。したがって、その確認は証明ではなく開始条件として扱ってください。イメージがSMB1対応しか提供しないなら、それはサーバー側で有効にする理由ではなく、止まる理由です。

資格情報と送信元の同一性はノートPCのものと異なる

転送された要求はトンネルを通ってノートPCの同一性を運びますが、ルーター上で生成された要求はルーター自身の送信元アドレス、リゾルバ経路、出力フィルタリングを運びます。それらは別のファイアウォール規則、別のDNSビュー、サーバー側の別の許可リストに落ちることがあります。したがって、ワークステーションから動く複製は、ルーター自身のマウントについて何も証明しません。マウントはルーター自身のシェルから試してください。背後にあるワークステーションからではありません。

その役割が認められるなら、ルーターには狭く権限を与えたサービスIDを用意してください。パスワードをマウントのコマンドラインに直接置かないでください。シェル履歴に残り、マウントの実行中はプロセス表にも現れます。

資格情報は基盤の保護された仕組みで保存し、厳しい権限のファイルから読んでください。そのファイルはマウントを実行するアカウント以外には読めないようにすべきです。

install -m 600 /dev/null /etc/cifs-reports.creds
printf 'username=svc-router\npassword=REPLACE_ME\ndomain=CORP\n' > /etc/cifs-reports.creds
mount -t cifs //fs02.corp.internal/reports /mnt/reports -o credentials=/etc/cifs-reports.creds,vers=3.1.1,ro

共有が消えたとき、障害は誰のものか

存在しないリモートファイルシステムは、存在しない経路とは違う振る舞いをします。マウントはそれに触れるプロセスを止め、トンネルができる前の起動時に失敗し、マウントポイントの下にローカルディレクトリがあると、サーバー向けの書き込みが誤った場所に落ちることがあります。それは今やネットワークチームが負うストレージ障害であり、望んだかどうかは関係ありません。誰もその所有に同意していませんが、マウントとともにやってきます。

起動順序とマウントオプションはその現実を前提に設計してください。短いタイムアウトと文書化された復旧手順を伴う読み取り専用マウントは、他のすべてが依存する書き込み可能マウントより弁護しやすいものです。何かがマウントを試みる前にトンネルが上がることを確認してください。停電後の最初の起動が止まってしまいます。

本格的なファイル処理や、データを先へ再輸出するものには、別のホストのほうが所有の境界を明確にすることが多いです。ルーターはルーティングを続け、ファイル作業フローはネットワークを道連れにせず再起動できるマシンを得ます。

判断を実際の作業に照らして確認する

どの作業がファイルを必要とし、その作業がどこで動くかを書き出してください。答えがワークステーションなら、共有をルーティングし、そこで止めます。答えが機器上のサービスなら、最初のマウントの前にクライアント能力、対応ダイアレクト、資格情報の経路を確認し、そのうえで機器が本当に適切なホストかを決めてください。

マウントされた像と空き容量をルーター自身から確認してください。作業負荷がそれらを見るのはそこだからです。確認は再接続の後にも繰り返し、きれいな起動の後だけにしないでください。

findmnt -t cifs -o TARGET,SOURCE,OPTIONS
df -h /mnt/reports
ls -l /mnt/reports | head

ファイルを一覧するのに、満杯または読み取り専用のファイルシステムを報告するマウントは、午前2時にどの障害に出会うかをすでに告げています。復旧経路も確認してください。きれいにアンマウントし、トンネルを落とし、再び上げて、機器を再起動せずにもう一度マウントします。その手順が毎回サポート案件を必要とするなら、クライアントの役割にルーターは不適切な場所です。