ポート インベントリにより、非表示のリスナーの競合が防止されます。解放は回復アクションであり、日常的なクリーンアップではありません。最初に所有リソースを特定して停止します。
開始前の準備
管理者アクセス。
検証済みの、ポートがライブ リソースに属している可能性があるかどうかのメンテナンス ウィンドウを確認しました。
設定の説明
運用者に必要なコントロールだけを説明し、内部フィールド名や実装イベントは表示しません。
ポート在庫
アクションを実行する前に所有権を読み取ります。
- ポート
割り当てられたネットワーク ポート。
- トランスポート
TCP または割り当てに関連付けられた UDP コンテキスト。
- O担当モジュール
ポートを予約したリソース。
- オープンオーナー
割り当てを担当するモジュールに移動します。
- Rリリース
古いポート割り当てを削除します。
まず停止して所有者を確認してください。ライブ リスナーを解放すると、サービスが中断される可能性があります。
安全な初回ワークフロー
- 01
競合するポートを見つけて、そのトランスポートと担当モジュールを読み取ります。
- 02
所有者を開いて、アクティブであるか、まだ必要であるかを確認します。
- 03
独自のモジュールを通じて古いリソースを停止または削除します。
- 04
R所有者が非アクティブで、ポートが古いままの場合にのみ割り当てを解放します。
- 05
目的のリスナーを作成または再起動し、ポートがそのリスナーに属していることを確認します。
ワークフロー例
SRT リスナーの競合を解決する
新しい SRT サーバーは、要求された UDP ポートにバインドできません。
構築手順
- 1
アクティブ ポートで UDP ポートを見つけて、その所有者を開きます。
- 2
リソースがライブであるか、古いか、または構成が間違っているかを確認します。
- 3
古い所有者を停止/削除し、残った割り当てのみを解放します。
- 4
目的の SRT サーバーを起動し、実際のクライアントに接続します。
ライブ ポート インベントリからファイアウォールの変更を準備します
セルフホスト展開では、セキュリティ グループまたはファイアウォールが機能する前に、アクティブな TCP リスナーと UDP リスナーのリストを確認する必要があります。
構築手順
- 1
必要な各ポート、トランスポート、および担当モジュールを解放せずにエクスポートまたは記録します。
- 2
外部から到達可能なすべてのリスナーについて、予想されるパブリッシャ、レシーバ、またはブラウザ クライアントを確認します。
- 3
制御されたウィンドウ中に承認された最小のファイアウォール ルール セットを適用します。
- 4
各実際のクライアント パスをテストし、アクティブ ポートの所有権を変更前のインベントリと比較します。
結果を確認
- すべての重要なリスナーには、認識可能な担当モジュールがあります。
- がリリースした古い割り当てが在庫から消えます。
- 対象のリソースは実際の接続をバインドして受け入れることができます。
トラブルシューティング
解放されたポートはすぐに戻ります
確認項目- 所有するリソースがまだアクティブであるか、再起動しているかを確認します。
- モジュールのライフサイクル状態を検査します。
実際の所有者を停止または再構成します。繰り返しリリースしても、アクティブなリスナーをオーバーライドすることはできません。