ポート1194はすでに使用中：そのOpenVPNソケットの持ち主は誰か

同じサーバープロファイルを二回起動すると、二番目のプロセスはポート1194でアドレスがすでに使用中というエラーで終了します。よくあるのは診断用の起動が競合を作った場合で、元のインスタンスは今もクライアントに完全に正常にサービスを提供しています。この話はこうした報告の大きな割合を説明しており、何かを再起動する前に見分ける価値があります。これが最も安価な解決版でもあります。

このエラーはローカルバインドを説明するだけで、それ以上のものではありません。プロバイダーがポートをブロックしていること、クライアントが誤ったパスワードを送ったこと、証明書チェーンが壊れていることの証拠にはなりません。

正確なバインドエラーを読む

この種の二つのエラーは意味が異なり、混同すると間違った層に送られます。「アドレスはすでに使用中」は、別のソケットが要求したエンドポイントを保持していることを意味します。「アドレスは利用できません」は、要求したアドレスがこのホストにまだ存在しないことを意味し、これは重複ではなく準備の問題です。

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

何かを変更する前に、エラーが示すアドレスとポートを含めてエラーテキストをコピーしてください。インターフェースの出現を待つサービスは二番目のエラーを繰り返し記録し、アドレスが存在すると正常にバインドしますが、一番目のエラーを記録するサービスは、重複が解消されるまで決して成功しません。どちらを見たかを書き留めるのは無料で、無駄なインターフェース探しを省けます。

ポートではなくソケットを棚卸しする

ポート番号は不完全な棚卸しです。エンドポイントはトランスポート、アドレスファミリー、ローカルアドレス、ポートであり、 すべてが一つのネットワーク名前空間の内側にあります。同じ番号のUDPリスナーとTCPリスナーは別のソケットで、異なる名前空間にある同じ番号の二つのプロセスは決して出会いません。

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

まずプロファイルが実際に使うトランスポートを実行し、次に番号だけでなくローカルアドレスの列を見てください。ワイルドカードバインドはすべてのローカルアドレスを覆うため、特定のアドレスを要求する二番目のプロセスは、表示される文字列が違っても衝突することがあります。ソケット再利用のオプションとプラットフォームの規則が正確な結果を決めるので、これはすべての配備に当てはめる規則ではなく観察であるべきです。

どのプロセスが所有しているかを見つける

数値のエンドポイントとプロセス情報は、権限が許せば、必要なのはプログラム名ではなく所有者であることを特定します。二つのOpenVPNプロセスが異なるプロファイルを実行していることがあり、リスナーを保持しているのは最も疑っていないものかもしれません。

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

見つけたものを、サービス管理者、コンテナランタイム、または以前のテストから残ったターミナルプロセスと突き合わせます。プロセスの詳細がないことはソケットに所有者がいない証拠ではなく、通常はクエリが十分な権限なしで実行されたことを意味します。同様に、TCPだけの一覧はUDPの競合を消さないので、エラーで示されたトランスポートを調べてください。プロセス名だけでは、どのプロファイルが読み込まれたかは決して分からず、 プロファイルこそがエンドポイントを決めるのです。

一人の所有者か、二つの設計されたインスタンス

配備が一つのサーバーを意図しているなら、ライフサイクルの所有者を一つに保ち、二つ目のコピーを起動して監視する代わりに、そのインスタンスのジャーナルまたは設定されたログを読んでください。制御されたフォアグラウンド実行が本当に必要なときは、管理対象のインスタンスを意図的に停止し、その前にそれが提供しているクライアントを考慮してください。

二つのインスタンスを意図しているなら、別々のリスナーと、それ以外のすべて（アドレスプール、仮想インターフェース、ルーティングポリシー、設定の所有権）を別にしてください。ポートだけを変えてもソケット以外は何も分離されず、二つのサーバーは同じプールと同じルートを奪い合います。

三つの近道は、このエラーに関するあらゆるスレッドに現れるので、名指しする価値があります。犯人に見える任意のPIDを殺さないでください。メッセージを黙らせるためにソケット共有を有効にしないでください。サーバープロファイルをクライアント風の非バインド設定に切り替えるとバインドエラーは消えますが、サーバーは元の競合より診断が難しい形で到達不能になるので、それも避けてください。

ポートを変えることが正当な答えになるのは、新しいリスナーが承認された設計の一部であり、転送規則とクライアントのエンドポイントが含まれる場合だけです。それらが更新されていなければ、誰も見つけられない場所へ競合を移しただけです。

何よりも先にバインドを確認する

限定的な修正の後、意図したインスタンスが動作していること、そのリスナーが期待するトランスポートに現れていること、クライアントが接続できることを確認してください。バインドの成功はローカルソケットの段階を終えるだけで、認証やトンネル起動後のトラフィックについては何も証明しません。

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

ソケットが存在し、クライアントがまだ失敗するなら、残る問題は下流にあり、バインドエラーはもう過去です。この切り分けこそ、正確なメッセージを最初に読むことの意味であり、一つのエラー、一つの層、一人の所有者です。そのように読めば、次の症状は推測ではなく既知の状態から始まります。