コンテナ更新を実行する管理端末は、一般端末用ではなく管理用VLANに置くのが基本です。SSHの送信元をその管理端末に限定し、更新対象のサーバー管理面へだけ到達を許可します。ただし、VLANやACLを変える作業では、管理端末自身を切り離さないよう、有線経路または既存SSHセッションを戻し手段として残してください。
配置チェックリスト
- 更新コマンドを打つ端末を、日常利用のPC・IoT端末と分けた管理用VLANに置く。
- 管理用VLANから更新対象サーバーのSSH管理面へ到達できることを確認する。
- 一般端末用VLANから同じSSH管理面へ到達できないことを別端末で確認する。
- 更新前に旧image digest、設定ハッシュ、データ退避先を記録する。
- ACL変更中は有線の管理経路または既存セッションを残し、失敗時に戻せるようにする。
SSH・ACL設定の要点
| 対象 | 許可の考え方 | 確認する結果 |
|---|---|---|
| 管理端末 | 管理用VLANから対象サーバーのSSHへ限定 | 更新・確認・切り戻しを実行できる |
| 一般端末 | 対象サーバーのSSH管理面は拒否 | SSH接続が成立しない |
| 更新対象 | 管理端末からの管理通信だけを受ける | 公開URLの新しい応答を読める |
| 戻し手段 | 変更中も一つだけ維持 | 誤設定時に変更前ルールへ戻せる |
根拠・実測範囲
既存のアクセス設計では、管理端末・一般端末・IoT・サーバーを役割として分け、管理面への到達可否を先に決めています。SSHは「決めた送信元だけ」を許可し、許可側と拒否側を別セッションで確認する前提です。隔離環境では誤banを想定し、手動解除後にbanリストから対象が消えることまで確認されています。この結果は、公開SSHを広げる根拠ではなく、管理端末を限定したままロックアウトから戻る操作を先に用意するためのものです。
更新側では、新しい版を起動できることではなく、同じデータを壊さず旧版へ戻せることを重視します。したがって管理端末の配置を決めても、更新前のdigest・設定・データ退避と、更新後の公開面確認は省略できません。詳細はコンテナ更新・公開・切り戻しの手順、VLANとSSH防御の設計、自宅ラボ運用の意思決定地図を参照してください。
よくある質問
管理端末は普段使いのPCを兼ねてもよいですか？
一般端末と同じVLANのまま兼用するより、更新操作専用として管理用VLANへ分ける方が、SSH送信元の限定を保ちやすくなります。
VPN接続中の端末はどこに置くべきですか？
認証済みVPN端末も、管理面へ届いてよい主体として明示します。常設入口を重ねず、管理用VLANと同じ到達条件にそろえます。
ACL変更でSSHを切った場合はどうしますか？
残していた有線経路または既存セッションから変更前ルールへ戻します。戻し手段を残せない変更は、実施前に条件を見直します。
AIを活用して制作しています。編集方針
検証に使っているラボ環境
当ブログの検証記事は、自宅の常設ラボ（使い捨てVM/LXCを回す母艦＋GPU＋VLAN分離ネットワーク）を使って書いています。この記事で実測した範囲と、机上整理や未計測の範囲は本文に記しています。使っている機材と選定理由、全体構成は1本にまとめています。
ラボ構成のまとめを見る →
