EC2のVPN専用ルール：接続されたすべてのセキュリティグループの合意が必要

VPNクライアントプール用のインバウンドルールを一つ追加し、何も削除していないのに、サービスは依然としてインターネットから到達可能です。壊れているものは何もありません。セキュリティグループには、狭いルールが打ち勝てる上書きも優先順位も最終的な拒否もありません。インスタンスに接続された各グループは、それぞれの許可を一つの統合された集合に追加し、忘れていた広いルールもその集合に残っています。インスタンスをVPN専用にするとは、それらすべてを監査することであり、一つのグループに耳触りのよいルールを追加することではありません。

ルールを書く前にサービスを書き出す

正確な宛先、プロトコル、ポート、そしてサービスが実際に待ち受けるネットワークインターフェースから始めます。複数のインターフェースや一つのポートに複数のサービスを持つインスタンスでは、接続されたグループが異なり得るため、インターフェースごとに監査する必要があります。次に、そのインターフェースがVPNユーザーに対して実際に受け取る送信元アドレスを、クライアントが自分の接続ウィンドウに表示するアドレスではなく、特定します。

変換とルーティングが関与すると、この二つのアドレスは人々の予想以上に頻繁に食い違います。

三つの送信元モデル、三つの異なるルール

プライベートなルーティングアクセスでは、経路がどうルーティングされ変換されるかに応じて、インスタンスはクライアントプールまたは企業レンジを受け取ります。企業の出口を経由して到達するパブリックエンドポイントでは、インスタンスは代わりに企業のNATアドレスを認識し、しかもその宛先が実際にVPN経路を使う場合に限ります。スプリットトンネリングでは家庭の接続に残ることがあるためです。マネージドClient VPNエンドポイントでは、文書化された関連付けとターゲットネットワークのモデルが適用され、クライアントアドレスは設定されたクライアントCIDRから取得されます。

機能しないのは、VPNゲートウェイをセキュリティグループの送信元として参照することです。グループ参照はVPC内またはピア接続されたネットワーク内の伸縮自在なネットワークインターフェースに一致し、パケットを転送するゲートウェイはそのどれでもありません。

接続されたすべてのグループにわたる和集合を読む

インスタンスを開き、そのネットワークインターフェースを見つけ、接続されているすべてのセキュリティグループを一覧にします。それぞれについて、プロトコルとポートを対象とするすべてのルールを確認します。広いポート範囲と両方のアドレスファミリーも含みます。0.0.0.0/0からのIPv4ルールは::/0の確認を免除せず、すべてのトラフィックを許可するルールはポートの疑問を完全に覆い隠します。この棚卸しの後に初めて、サービスに対する実効的な許可が何かを言えます。

AWSのルールリファレンスは、セキュリティグループを許可のみと説明し、接続されたすべてのグループのルールが集約されると述べています。これがこの失敗の背景にある仕組みそのものです。

ネットワークACLは、順序付けられた許可と拒否のエントリを持つ、別個のステートレスなポリシーであり、インスタンスではなくサブネットで評価されます。

拒否の壁で答えてはいけない

慣れ親しんだファイアウォールを模してサブネット全体のNACL拒否を追加するのは、間違った道具であり危険です。NACLエントリは順序付けられステートレスであるため、既存の許可の上に置かれた拒否は、維持しようとしていたセッションの戻り経路を含む無関係なトラフィックを静かに壊します。広いセキュリティグループの許可をそれが属するグループで修正し、ACLが本当に設計の一部でない限りそのままにしておきます。

インスタンスからパブリックアドレスを外すことはより強い保証であり、管理とアプリケーションの影響を伴うアーキテクチャの変更でもあります。許可リストのチェックボックスではありません。

新しいセッションでテストし、入る手段を確保する

既存の許可を廃止する前に、承認された独立した管理経路を確認してください。削除しようとしているルールが、セッションの復旧が依存するものかもしれないからです。次に、VPNからの新しい許可された接続と、承認された非VPNのテスト経路からの新しい拒否された接続を試します。既存の追跡済みセッションはルール変更を生き延びるため、古い開いたシェルは受け入れの証拠として役に立ちません。

最後に、アプリケーション自身の認可をそのままにしておきます。変換された企業の出口は数百人を表すことがあり、ネットワークの入場は個人のユーザーやそのデバイスを識別したことはありません。