Client VPN 証明書を再インポートしても新しいエンドポイントが必要な理由

Client VPN 接続が切れ、ACM の証明書を差し替えても、何も変わりません。証明書オブジェクトは、エンドポイントが使っていたものではなかったのです。エンドポイントは作成時に証明書への関連付けを保存し、検証に使うクライアント CA、認証タイプ、サブネット、認可ルールもあわせて固定のプロパティとして保持し、これらの関連付けには、差し替え証明書を受け付ける変更呼び出しがありません。ARN の背後にあるバイト列を差し替えるのは証明書の変更であり、それを取り込んだエンドポイントの変更ではありません。

エンドポイントが保存するのは証明書ではなく参照です

この仕組みは、障害の全体を説明するからこそ正確に述べておく価値があります。create-client-vpn-endpoint は サーバー証明書の ARN とクライアントルート証明書チェーンの ARN を受け取り、生成されたエンドポイントはそれらの参照と認証オプションを固定プロパティとして保持します。API には、既存のエンドポイントのサーバー証明書を差し替える操作はありません。

当て推量なしで関連付けを確認できます。aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 は証明書の ARN、クライアントルートチェーンの ARN、認証タイプ、クライアント CIDR、関連するサブネットを出力します。これは再現すべきプロパティの全集合であり、再インポートの前後で実行しても出力は動きません。これが、再インポートでは決して解決しなかったという証拠です。

再インポートがエンドポイントに届かない理由

再インポートは既存の ARN の下に新しい証明書本体を書き込みます。証明書の期限が近い場合には正当な操作であり、秘密鍵が一致しチェーンが検証される限り ACM は受け付けます。しかし、エンドポイント作成時の検証を再実行することはないため、関連付けとその背後の素材はエンドポイント構築時のまま残ります。

症状がネットワーク障害のように見えるのもそのためです。認可が評価される前に TLS ハンドシェイクが失敗またはリセットされるので、セキュリティグループ、ルート、認可ルールはすべて無実に見え、実際に無実です。

チェーンはクライアント証明書の一部です

障害の残り半分はクライアント証明書にあり、こちらは見落としやすいものです。クライアント証明書は、インポート画面でその欄が任意に見えても、それを発行したチェーンとともにインポートする必要があります。チェーンがないと、エンドポイントはクライアント証明書から設定済みのクライアントルート CA までの経路を構築できず、接続はパケットを落とすファイアウォールのようなソフトリセットで終わります。openssl verify -CAfile root-ca.pem client.crt はその問いにローカルで一秒で答えるので、最初に実行すべきコマンドです。

チェーン付きの再インポートはその半分に対する本当の修正であり、それでも単独では足りません。ACM オブジェクトが変わった後は、古い関連付けを持つエンドポイントはテストを続ける相手として誤っています。両方の手順は同じ修理に属するため、二段階の修正は矛盾ではありません。

エンドポイントの再作成は移行です

代替エンドポイントの作成は移行であり、再試行ではないため、再試行として扱うと、チームは半端に設定されたエンドポイントを二つ抱えることになります。新しいエンドポイントは新しい ID を取得し、計画していなければ全ユーザーに新しい DNS 名を取得します。クライアントプロファイルはアドレスではなく名前を指すようにしておけば、切り替えは再配布ではなくレコード変更になります。

これを安全に保つ順序は短く、同じ CIDR、サブネット、認可ルールで新しいエンドポイントを作成し、aws ec2 export-client-vpn-client-configuration で新しいプロファイルをエクスポートし、一人のユーザーで検証します。その後になって初めて、古いエンドポイントを落とします。

古いエンドポイントの廃止には独自の順序があります。削除する前に、古い CA をまだ信頼する新しいエンドポイントが消えたと思っていた証明書を受け付け続けるため、廃止予定のクライアント証明書を失効させてください。次に古いエンドポイントを削除し、その認可ルールを外して、古いプロファイルが閉じたと思っていた対象ネットワークへ再接続できないようにします。記憶と照合する移行は動作するエンドポイントを二度作り直す原因になるので、古いエンドポイントの ID と関連付けの識別子を変更記録に書いてください。

診断の順序を決める

設定を変える前に、三つの障害を切り分けます。クライアントが TLS を完了できない、TLS は完了するが認可されない、接続はできるが宛先に届かない、のいずれかです。証明書の関連付けは一つ目、クライアントアドレスを覆わない認可ルールは二つ目、ルートやセキュリティグループは三つ目に属し、三つ目ではエンドポイントの再作成がほぼ常に誤った一手です。

何ヶ月も動いていたエンドポイントが、証明書もポリシーも変えずに止まった場合は、それ自体が別のケースです。同一設定での再構築でサービスが戻ることはありますが、それは設定を再現可能に保つ理由であって、インシデントのたびに再構築する理由ではありません。

次の再構築を即興ではなく差分にするために、エンドポイントのパラメータ、証明書とチェーンの ARN、認可ルール、クライアント CIDR の四つをバージョン管理下に置きます。Client VPN の認証ドキュメントには、どの証明書がどの役割を担うかが載っており、証明書が問題だと決めつける前に確認する価値があります。再インポートで何も変わらずエンドポイントがリセットし続けるなら、疑わしいのは関連付けであり、答えは記録済みパラメータから構築した新しいエンドポイントです。エンドポイントが新しいオブジェクトを取り込むなら、関連付けはすでに正しく、障害はクライアントチェーンか認可層にあります。