AWS Client VPN：ログインは成功するのにサブネットへ届かない

クライアントは Connected と表示し、証明書も有効なのに、イントラネットのページはタイムアウトします。この差はほとんど認証の問題ではありません。AWS Client VPN はログインとは別に宛先を認可します。よくある原因は二つで、ID プロバイダーが送った値と一致しないグループ値と、広いルールを打ち消すより具体的な宛先ルールです。どちらも、見る場所さえ分かればエンドポイント設定で確認できます。

ログインは成功したが、ルールが一致していなかった

認証が答えるのは、利用者が誰かという点です。 認可ルール が答えるのは、その ID がどのネットワークプレフィックスに到達できるかという点です。利用者は前者を通り後者で失敗することがあり、クライアントは、すべての要求がタイムアウトする間つながったままの接続しか与えてくれません。

まず、失敗しているアドレスを宛先に含む認可ルールがエンドポイントにあるか確認します。一致するルールがなければ、接続は正しく動作しており、足りないのはポリシーです。

グループ値は実際どこから来るのか

Active Directory では、access-group フィールドに入るのはグループの表示名ではなく SID です。SAML フェデレーションでは、設定した SAML グループ属性が実際に運ぶグループ ID または名前が入ります。値をコピーするのはアサーションかディレクトリ検索からで、Wiki ページからではありません。

IAM グループは別の制御プレーンです。Client VPN エンドポイントを管理する権限があっても、IAM グループが利用者の VPN グループになるわけではなく、IAM グループ名を access-group フィールドに貼っても AD の SID や SAML 属性値には変換されません。

別のディレクトリにある同名のグループは何も証明しません。エンドポイントの認証方式と、同じシステムにおける利用者の所属またはアサーションを確認してください。

最長プレフィックスが優先される。0.0.0.0/0 も対象

認可は最長プレフィックス一致で評価され、全宛先のルールは最初ではなく最後に評価されます。Engineering 用に 10.46.0.0/16 のルールを、全員用に 0.0.0.0/0 のルールを追加しても、Engineering 外の利用者は広いルール経由で 10.46.20.10 に到達できません。

ここで修正が誤ることがあります。狭いルールを削除すると利用者のアクセスは戻りますが、広いルールが対象とするすべての ID にそのサブネットを与えることになります。何かを削除する前にグループとネットワークの対応表を作り、どのグループがどの範囲に届くべきかを書き留めてください。これらのルールは許可のみで、広い許可から例外を切り出す拒否エントリはありません。

変更は公正に評価するために新しい接続も必要です。ルールを編集したらクライアントを再接続し、そのうえで再試験します。

認可とデータ経路を切り分ける

一致するルールは経路ではない. エンドポイントには関連付けたサブネットと宛先のルートテーブルエントリが必要で、対象リソースのセキュリティグループが通信を受け入れる必要があります。戻り通信と DNS も機能しなければなりません。

成功すべき利用者と、除外されたままであるべき利用者を試します。二人ともログインできるのに片方だけがサブネットに届く、その差が欲しい証拠です。

IP アドレスは通るのにホスト名が通らないなら、認可に触る前にリゾルバーを見てください。どのルートもアドレスを覆っていないなら、関連付けかルートテーブルを直します。パケットが届いてサービスが拒否するなら、次はそのサービスのポリシーです。認可の対応表を全利用者に広げると、どの層が本当に壊れていたのかが見えなくなります。

チケットを閉じる前に、ID の出所、正確なグループ値、宛先プレフィックス、通信を運ぶルートを記録します。その記録があれば、次に接続済みだがアクセスできないという報告が来ても、また推測を重ねるのではなく二分間の照合で済みます。