OpenVPN Access Server は実際にどのポートで待ち受けているのか？
Access Server ホストのソケット一覧をたどり、既定のリスナーを見分け、ループバックと公開済みポートを区別し、ポートを閉じる前に転送を確認します。
実行するのは ss -lntup です。Access Server ホストでこれを実行すると、想定の倍の長さの一覧が返ります。項目の半分は、セットアップ時に誰も触れなかったデーモン形のポートです。反射的に 443 と 1194 以外をすべて閉じると、自分のクライアントポータルを壊すことになります。
Access Server は単一のリスナーではありません。VPN サービスであり、Web サービスであり、クラスタの参加者でもあり、設定した TCP デーモンの数に応じてデーモン固有の追加ポートやファイアウォールのリダイレクトを生成できます。
一覧は順番にたどります。ソケットを読み、見慣れたものを対応づけ、残りを所有者とバインドで分類し、最後に実際に何がそれらを公開しているかを確認します。
単一の読み取り専用コマンドから始める
sudo ss -lntup は、待ち受けている各ソケットのトランスポート、ローカルアドレス、ポート、所有プロセスを返します。フラグが重要です。-l は待ち受け、-n は数値表示、-t は TCP、-u は UDP、-p はプロセスです。root がないとソケットは得られてもプロセス名は得られませんが、分類に必要なのはまさにその列です。
意見を固める前に、各行について 四つの項目を記録します。プロトコル、バインドアドレス、ポート、コマンドです。Access Server のバージョンと設定済みのデーモン数もその一覧の横に控えてください。どちらも期待値を変えます。
同じに見える二行は同じではありません。同じ番号の TCP と UDP は別々の公開範囲を持つ別々のソケットであり、0.0.0.0 と :: は別々のアドレスファミリーに対する別々のバインドです。127.0.0.1 にだけバインドされたサービスは他のホストから直接は到達できませんが、ローカルのリダイレクトが依然として公開する可能性があります。
見分けるべきリスナー
これらの既定値はほとんどの配備をカバーし、比較の基準になります。あくまで既定値であり、完全な許可リストではありません。
| Socket | Role to confirm |
|---|---|
| UDP 1194 | OpenVPN UDP tunnel listener |
| TCP 443 | OpenVPN TCP listener, optionally forwarded to the web service |
| TCP 943 | Admin and client web interfaces, and cluster control in Access Server 3.0 and later |
| TCP 945 | Cluster control in older configurations that predate the move to 943 |
それ以外のすべてには説明が必要で、推測では足りません。製品が自分のために導入するコンポーネントに属するローカル専用リスナーをよく見かけます。覚えているポート番号ではなく PID とサービスの設定で確認し、見慣れないというだけで未知のポートを敵視しないでください。
見慣れた組み合わせの外にあるソケットも、自動的に残骸とは限りません。TCP デーモンを複数設定すると、Access Server はデーモンごとにリスナーを作成してトラフィックをそこへ転送するため、その数とポート値はその設定に従います。
何かを閉じる前に分類する
不確かな行ごとに、次の順序で三つの問いに答えます。
- 所有者と目的。 PID をユニットまたはプロセスに対応づけ、そのサービスの設定を読みます。所有者を特定できないなら、そのソケットについて何かを決める準備はできていません。
- バインドの範囲。 ループバックは名前空間内に限定されます。ワイルドカードバインドに到達できるかは、ルーティング、ホスト側のフィルタリング、クラウド側の規則次第であり、バインドアドレスは必要条件であって十分条件ではありません。IPv4 と IPv6 は別々の判断として確認します。
- 公開される経路。 サービスの転送、デーモン固有のリダイレクト、外部プロキシ、実際に効いているファイアウォール方針を探します。ここを飛ばす人が多く、無害に見えるバックエンドポートを到達可能な管理経路に変えるのはこの手順です。
同じ問いもホストの外から見ると意味が変わります。ホスト側のファイアウォール規則がないポートでもクラウドのセキュリティグループで閉じられることがあり、許可的なホスト規則があるポートでも何もルーティングしていなければ到達できません。一覧の結論を書く前に両端を見てください。
公開される経路がソケット一覧と異なる場合
Access Server 自身のドキュメントは、最も混乱を招くケースを扱っています。TCP デーモンを複数動かすと、前面のポートがデーモン固有のポートへ転送され、見た目の構成がソケット一覧と一致しなくなります。Web インターフェースのフィルタリングのチュートリアル はその規則と、明白なポートだけを対象に書いたフィルタが転送後の経路を完全に見落としうる理由を説明しています。
クラスタ制御はバージョンが問題になる二つ目の箇所です。3.0 以降は 943 を共有し、それより古いクラスタ設定は 945 を使っていました。バージョンを確認せずにどちらかを開けたり閉じたりすると、整って見えるのに誤った一覧になります。
つまり外から見える面は 三つの和集合です。待ち受けているソケット、それらを再公開する転送規則、ホストの手前にあるネットワーク制御です。最初のものだけを記録した一覧は不完全であり、最初のものだけを考える変更は経路を開けたままにするかサービスを切断します。
変更後には必ず検証する
リスナーの設定はサポートされた設定の所有者を通して変更し、作業中は復旧用コンソールを開いたままにします。遠隔ホストの Web UI への管理アクセスを失うと、たった今無効にした VPN では復旧できません。
続いて、配備に通常必要な 四点を検証します。VPN クライアントが接続できること、クライアントポータルが読み込まれること、管理アクセスが機能すること、複数ノードを運用している場合はクラスタ通信が機能し続けることです。VPN だけのテストはポータルが壊れていても平然と通ります。
最後に、各サービスで許可される経路を書き留めます。どのソケット、どのバインド、どの転送規則、どのネットワーク制御か。その文書が有益なセキュリティ成果物です。ソケット数の最小化ではありませんし、誰も特定を終えていないリスナーを一括で閉じることも成果物ではありません。