誰かが VPN を動かすと称する charm を見つけ、デプロイし、アプリケーションを公開し、クライアントが接続するのを待ちます。デプロイは成功し、ポートは開き、それでもトンネルは動きません。無関係な三つの約束が一つにまとめられていたからです。charm とは、特定の契約を持つデプロイ実装です。その約束を一つずつたどれば、ギャップは展開の後ではなく前に見えてきます。

ステップ一:読んでいる成果物を固定する

候補のメタデータを読みます:発行者、ソースリポジトリ、チャネル、リビジョン、ベース、アーキテクチャです。次に、ワークロード内の VPN ソフトウェアを誰が保守し、誰がそのセキュリティ更新を提供するのかを明らかにします。多くの場合、この二つは別の主体です。よく保守された charm の中の保守されていない upstream は、悪い週を待っているサポート問題です。

juju info CHARM_NAME は Juju 3.6 でチャネル、ベース、アーキテクチャを報告し、ドキュメントは特定のリビジョンの問い合わせをこれらのフィルターと組み合わせられないと注記しています。コマンドが拒否する組み合わせを作るのではなく、リビジョンを単独で問い合わせてください。チャネルは複数をカバーできるため、ベースとアーキテクチャも読んでください。

確認した正確な組み合わせをデプロイの隣に記録します。そうすれば、チャネルを移すリフレッシュは前後のある意図的な変更であり、月曜日の不意打ちではありません。

ステップ二:設定を契約として読む

charm が果たす役割を決めます。リモートアクセスを終端するのか、既存の VPN に参加するのか、まったく別の何かなのか。次に、クライアントの登録、信頼された発行者、資格情報のローテーション、失効をどう文書化しているかを探します。この四つが運用できるかどうかを決め、生成されたクライアントファイルはチケット用のファイルではなく機微な出力です。

charm が実際に公開するインターフェースとアクションに従います。同じソフトウェアの別の charm に登録アクションがあるからといって、こちらにもあると決めつけないでください。

調整が手作業の編集に何をするかを尋ねます。charm が次の更新で設定ファイルを上書きするなら、手作業の修正の寿命はアップグレード一回分です。その挙動がどこに文書化されているかを保守担当者に尋ね、沈黙は不明として扱います。

ステップ三:リスナーと転送経路を分ける

外側のリスナーはトンネルを受け入れるソケットです。転送はその内部のトラフィックに起きること、戻り経路は応答が戻れるようにするものです。charm は最初のものを提供し、残り二つをインフラチームに任せることができます。

出口は三つ目の部分です。トンネルのクライアントがこのホスト経由でインターネットに到達すべきなら、アドレス指定か変換の仕組みが必要であり、それはポートを開くことでは作られません。最初のクライアントが来る前に、その部分に所有者を割り当ててください。

ステップ四:公開はファイアウォール操作である

Juju 3.6 では、アプリケーションを公開するとクラウドのファイアウォール規則が調整され、既定では任意の送信元からワークロードが開いたポートへのトラフィックが許可されます。コマンドの endpoint と CIDR のセレクターは、まさにこの既定を狭められるように存在します。

公開は VPN ユーザーを作らず、その資格情報を検証せず、転送ポリシーも導入しません。また、ワークロードが想定したアドレスとトランスポートで待ち受けていることも証明しません。だからこそ、公開後のテストは成功メッセージより重要です。ユニット上の待ち受けソケットとクラウドの規則の両方を確認してください。

ステップ五:四つのテストで受け入れる

承認されたデプロイの後、新しいクライアントを登録し、意図したプライベートサービスを確認します。次にそのアイデンティティを取り消し、次のログインだけが拒否されるのではなく、アクセスが実際に終わることを確認します。管理していないネットワークから、次にオフィスの内側から同じ確認を繰り返します。この二つの経路は別の問いに答えるからです。

アップグレードと再接続で締めくくります。そこでは調整、資格情報の扱い、サービスの再起動が互いに影響するからです。ドキュメントがこれらの操作の一つを誰が所有するか説明できないなら、同じ charm 名の背後にある保守されていないレシピで埋めるのではなく、導入のギャップとして書き留めてください。書かれたギャップは決定であり、静かに埋められたギャップは将来の障害です。サービス決定の所有者に、見つけた日付とともに渡してください。

関連記事