VPN のクラウドセキュリティグループ：リスナーを開き、全部は開けない

VPN サーバーは動いている、クライアントはタイムアウトする、そして最初の反応はセキュリティグループに全許可のルールを追加することだ。それで動くこともあり、それが最悪の結果である。なぜなら今や、どの境界が実際に閉じられたのか誰も分からないからだ。クライアントとデーモンの間には四つの独立したフィルターがあり、そのうちの一つだけがセキュリティグループだ。

ルールより先にプロトコルを特定する

ルールとはプロトコル、ポート範囲、送信元である。WireGuard は UDP、通常 51820 で待ち受ける。OpenVPN は設定次第で通常 UDP または TCP 1194 である。IPsec は UDP 500 と 4500 での IKE 交換に加え、ESP プロトコル自体を必要とする。これはポートではなくプロトコル番号だ。他のルールが TCP だからといって TCP と推測すると、正しく見えて何にも一致しないルールができる。

リスナーはチュートリアルではなく実行中のサービスから読む。一つのアドレスに束縛されたデーモンは、別のアドレスに届く通信を受け付けない。

送信元はインターネット全体ではなく、設計が許すクライアント範囲に限定する。

セキュリティグループはステートフル、サブネット ACL はそうではない

セキュリティグループはステートフルで許可のみである。許可された受信フローは応答を自動的に受け取り、考えるべき拒否ルールは存在しない。サブネット ACL はステートレスで両方向に評価されるため、対応する送信の一時ポート範囲がない受信許可はやはり失敗する。この違いが、コンソールで正しく見える多くのルールを説明する。

実行中のエンドポイントにどのポリシーが紐づいているかも確認する。インスタンスは複数のグループを持ちうるし、紐づいていないグループのルールは何も変えない。

実効ポリシーは紐づいたものの和集合であり、編集したファイルではない。

ホストのファイアウォールは別の境界である

クラウドのポリシーはネットワークインターフェースまで通信を通し、その後に OS がデーモンに見えるかどうかを決める。既定で拒否するポリシーのホストファイアウォール はセキュリティグループが許可したパケットを落とすが、クラウドのコンソールには拒否が表示されない。コンソールはそもそも関与していないからだ。パケットが出会う順番で両方を確認する。

ホストがディストリビューションのファイアウォールフロントエンドを使う場合は、プロファイル名ではなく基になるルールを確認する。プロファイルが有効でもポートが閉じていることがある。

インターフェースでのキャプチャが、どの境界がパケットを落としたかを教える。

リスナーを許可することはクライアントをルーティングすることではない

クライアントの通信を転送する VPN ゲートウェイには、開いたポート以上のものが必要だ。IP 転送、トンネルインターフェースから宛先ネットワークへの流れを許可するポリシー、そして多くの場合、自分宛てでない通信をプラットフォームが捨てないようにするためのインターフェースでの送信元・宛先チェックの無効化が要る。どれもリスナーのルールでは作られない。

ここで、機能するハンドシェイクと壊れたデータ経路が分かれる。だからトンネルの状態が健全に見えても何も読み込めないことがある。

ルーティングは独自の検証を伴う別の変更として直し、転送するゲートウェイには宛先を許可する出口ポリシーも必要だと記す。

戻る道を確保してから、ルールを狭める

リモートのファイアウォールポリシーを変える前に、セッションマネージャー、シリアルコンソール、帯域外ネットワークなど、独立した管理経路があることを確認する。唯一の管理経路が編集するルールを通っているなら、復旧手段はない。そのうえで狭いルールを適用し、実際のクライアントから試し、その試行をサーバー側の証拠と突き合わせる。同じマシン上の別サービスの応答は、リスナーに到達した証拠にはならない。

狭い許可が機能したら実験的な広い許可はすぐに外し、なぜそのルールがあるのかを記す。AWS はセキュリティグループのステートフルな挙動を文書化しており、誰かが近道として広い範囲を提案したときはその文書を引くべきだ。

関連付けも文書化する。さもなければ交換用インターフェースがポリシーを静かに失う。