vpncのグループシークレットかログインか：どの欄に何を入れるか

はじめて誰かからvpncプロファイルを渡されると、資格情報のダイアログは四つの項目を尋ね、一つのパスワードだけを求めているように読める。そうではない——グループの事前共有シークレットと個人のXAuthログインは別々の所有者を持つ別々の値であり、アカウントのパスワードをグループ欄に入れると、間違った欄ではなく悪いパスワードのように見える失敗になる。この対応を正しく取ることがここでの仕事のすべてだ。土台のプロトコルは他人の移行プロジェクトであり、だからこそこれは新しいIKEv1トンネルを作る根拠にはならない。

二つの秘密、二人の所有者、一つのダイアログ

グループシークレットはゲートウェイのプロファイルに属する。そのプロファイル経由で接続する全員が同じ値を使うからこそ、それは個人を識別できず、プロファイルの他の全利用者のために変えずに一台のノートPCから取り消すこともできない。XAuthのユーザー名とパスワードは代わりに人間に属し、ゲートウェイはIPsecの関連付けがすでに確立した後の第二段階でそれらを評価する。

人が見落とすのはこの二段階の形だ。トンネルの確立と利用者の認証は入力の異なる別のやり取りなので、資格情報の入力要求に決して到達しないクライアントはログインで失敗したわけではない。ダイアログは一つではなく二つの列として読む——左がプロファイル全体の値、右が個人の値だ。接続に失敗したとき、最後に入力した列が自動的に原因とは限らない。

欄はラベルではなく役割で対応づける

vpncはプロジェクトの文書で指示子に名前を付けており、どのグラフィカルなフロントエンドもそれを付け替える。各値の役割を訳せば、ラベルは問題にならなくなる：

グループ欄の隣に「ユーザー名」と「パスワード」を表示するフロントエンドは間違いではない——同じ三つの値を別の名前で見せているだけだ。壊れるのは、値が収まるという理由で欄を埋めることだ。ユーザーのパスワードとして貼られたグループシークレットはプロファイルを認証し、その後の利用者段階で失敗し、グループシークレットとして貼られたアカウントのパスワードはもっと早く、どんな要求よりも前に失敗して、テキスト欄に住む問題をファイアウォールで探させる。

グループ識別子でないもの

グループという語は誤読を招く。ここでのグループ識別子は、ゲートウェイにどのプロファイル設定を適用するかを伝える選択子であり、ディレクトリの所属については何も言わない——両側で名前が一致していても、運用者が確認するまでは偶然だ。認可はXAuthが成功した後に行われ、ゲートウェイが何を参照するよう設定されているかで決まり、そのどれもクライアントのダイアログには見えない。

同じ注意はグループシークレットにも当てはまる。それを知っていることは身元ではなく、一つの秘密をチーム内で回すことは、クライアントが表示できない結果を伴う運用上の決定だ。

接続する前に曖昧な指示を解決する

古い引き継ぎメモには「専用のパブリックIPを使う」といった一行がよくある。その表現は、向こう側の許可リストがあなたの通信の到着元として期待するアドレスを意味することがあり、これは運用者ネットワークの出口の性質で、ゲートウェイ欄に入力する端点とは何の関係もない。値がどこかへ行く前に、どちらを指すのか尋ねる。逆に入力すると、決して応答しないアドレスへ全パケットを送り、結果のタイムアウトは遮断されたポートのように読める。

組織の検証済みチャネルを通じて四つを尋ねる——どのクライアントとプロトコルが対応しているか、どの端点を使うか、ゲートウェイがどの身元を示すか、資格情報をどう受け渡すかだ。本物の秘密はスクリーンショット、チケット、共有のトラブルシューティング記録の外に保つ。証明書の検査を無効にしたり、古い暗号スイート一覧を貼り付けて別設定のサービスを互換に見せたりしてはいけない——検証を弱めることでしか動かない接続は、頼まれた接続ではない。

旧プロファイルを誠実に保つ

IKEv1は非推奨であり、移行の話が出たときに引用すべき文書はRFC 9395だ。欄の対応づけが成功しても、そのプロトコルが新しい設計に属する証拠にはならない——それが買うのは、置き換えが予定されるまでの動く接続と、その移行の書面化された範囲および担当者だ。

次に、ダイアログではなく要件に対して検証する。接続後、トンネルのインターフェースが期待したアドレスを持ち、内部の宛先がそこを通ることを確認し、元の要件が許可リスト用の出口アドレスを挙げていたなら、そのアドレスも確認する——トンネルが上がっていることとは別の事実だからだ。正しく認証しても何も経路づけないプロファイルは、作られた目的を果たしていない。