VPN リスナーを意図したインターフェースだけに限定する

VPN サービスに到達できるかどうかは、ソケットがどこにバインドされているかと、ファイアウォールが何を許可するかで決まります。これは二つの別々の判断であり、ふつう人はどちらか一方しかしません。実際のリスナーを読むのに十秒かからず、推測では解けない問いに決着がつきます。まずそこから始め、それから一つずつ制御を変えてください。

以下はすべて、ホスト上で root または sudo を使ってコマンドを実行できることを前提としています。

何かを変える前にソケットを読む

Linux では、ss -lunp が UDP リスナーをローカルアドレス、ポート、プロセスとともに一覧表示し、ss -ltnp が TCP について同じことを行います。VPN のポートを探し、アドレスの列を注意深く読んでください。0.0.0.0:51820 と [::]:51820 はすべてのインターフェースを意味し、10.0.0.5:51820 は一つのインターフェース上の一つのアドレスを意味します。出力に馴染みがなければ、ss のマニュアルに列の説明があります。プロセス名が表示されない場合は、同じコマンドを sudo で実行してください。所有者の列には特権が必要だからです。

アドレスを書き留めてください。それがこの手順書の残りの部分が依存する事実です。

願望ではなくアドレスにバインドする

OpenVPN は local ディレクティブでリスナーを特定のアドレスにバインドします。これがプロセスレベルで範囲を絞るためのサポートされた方法です。すべての実装に同等の機能があるわけではなく、バインドオプションのないプロトコルはこの方法では狭められません。自分の実装にそれがなければ、ファイアウォールが唯一の制御になり、導入ノートでもそう明記すべきです。複数のアドレスを持つホストでは、トンネル側のアドレスにバインドしてください。浮動するアドレスにバインドするのはたいてい誤りです。

アドレス変更を乗り越える必要があるサービスには、設定行だけでなく、古いバインドに対する計画が必要です。

アドレスファミリーを別々に確認する

IPv4 と IPv6 は別々のソケットです。0.0.0.0 にバインドされたプロセスが、デュアルスタックソケットを通じて IPv6 をまだ受け付けることもあれば、受け付けないこともあります。ソケットオプションとプラットフォームの既定値によります。IPv4 の行だけを読むと、一度ならず導入レビューが欺かれてきました。リスナーが狭いと結論づける前に、両方のファミリーを一覧してください。

IPv6 が設計の一部でないなら、ファイアウォールがカバーしてくれることを期待するより、ソケットレベルで無効にするほうがすっきりします。これはポリシーの判断なので、他のインターフェースの選択と一緒に記録してください。

バインドの上にファイアウォールを重ねる

狭いバインドはファイアウォールのルールを置き換えませんし、ファイアウォールのルールはワイルドカードのバインドを狭めません。両方を使ってください。実装が対応している場所でバインドし、そのうえで、そこに到達すべき送信元からのみポートを許可します。クラウドのセキュリティグループはホストのファイアウォールの前に位置するので、経路が VPC の境界を越えるときは両方を確認してください。実効的なルールは二つの積集合であり、各層は到達可能性を削ることしかできません。

許可された送信元と、意図的に除外した送信元からテストしてください。localhost からの接続は、公開境界について何も証明しません。

選んだ内容を記録する

バインドしたアドレス、それを所有するインターフェース、ファイアウォールのルールとその目的を書き留めてください。NIC の交換やクラウドアドレスの再割り当ては、誰もプロファイルを編集しないまま公開範囲を変えることがあります。クラウドアドレスはレビュー間で思っている以上に動くので、メモに日付を入れてください。

そのメモがあるからこそ、次のレビューは考古学のプロジェクトではなく比較になるのです。