ファイアウォールまたはNATルールがホームサーバーへの着信接続をブロックしているかどうかを確認する方法
家庭内ネットワークの外からテストを開始し、パケットが消えるまで接続を内側にたどってください。
セルフホストされたアプリへの着信接続が失敗する原因は、サービスがリッスンしていない、ホストのファイアウォールが拒否している、ルーターが誤ったポートやアドレスに転送している、WANがCGNATやダブルNATの背後にある、または返信が誤ったゲートウェイから出ている場合などがあります。最も安全な診断方法は、公開範囲を狭く保ち、TCPまたはUDPサービスを一度に一つずつ検証し、リスナーの出力、ルーターのカウンター、ファイアウォールのログ、パケットキャプチャを使用して最初に欠落している段階を特定することです。
サービスが期待されるインターフェースでリッスンしていることを確認する
まずはホームサーバー自体で確認します。プロセスが実行中であること、意図したTCPまたはUDPポートが開いていること、リスナーが127.0.0.1やコンテナ専用ネットワークだけでなく、LANアドレスまたは必要なすべてのインターフェースにバインドされていることを検証してください。
Baeldungのポートテストガイドでは、LISTENモードのソケットは接続を受け入れる準備ができていると説明していますが、バインドアドレスがどのインターフェースからアクセス可能かを決定します。
別のLANデバイスからサーバーのプライベートIPと正確なポートを使ってサービスをテストしてください。失敗した場合はサーバーまたはローカルVLANの経路で止まります。NATルールはルーター側のLANから到達できないサービスにトラフィックを正常に転送できません。
同じLANからのテストではなく外部クライアントを使用する
スマートフォンのWi-Fiを切断するか、別のインターネット接続のシステムを使用してください。ターゲットサービスがアクティブにリッスンしている間に、パブリックIPまたはドメイン、外部ポート、正しいプロトコルをテストします。
Lifewireのポートフォワーディングガイドでは、ルーターのルールとコンピュータのファイアウォールの両方が接続を許可する必要があることを指摘し、ローカルブラウザに頼らずネットワーク外から開いているポートを確認することを推奨しています。ローカルブラウザはNATループバックの挙動に遭遇する可能性があります。
クライアントがタイムアウト、即時拒否、TLSエラー、またはアプリケーションの応答を受け取るかを記録してください。拒否は到達可能なホストにその経路で受け入れサービスがないことを示すことが多く、無応答のタイムアウトはフィルタリング、転送の欠落、上流NAT、または到達不能な宛先と一致します。
ルーターのWANアドレスとパブリックアドレスを比較する
ホームルーターに表示されるWANアドレスを読み取り、外部サービスが報告するパブリックアドレスと比較してください。通常のIPv4ポートフォワーディングでは、上流ルーターが最初のNATを行わない限り一致するはずです。
ルーターのWANアドレスがプライベート、共有、またはパブリックアドレスと異なる場合、転送ルールはダブルNATまたはキャリアグレードNATの背後にある可能性があります。この場合、パケットはローカルファイアウォールを何度変更してもルーターのルールに到達しません。
上流ゲートウェイを管理している場合は同じポートを転送し、ISPに使用可能なパブリックアドレスを要求するか、インバウンド転送が利用できない場合はVPN、アウトバウンドトンネル、リレーを選択してください。ホームルーターに到達しないパケットのためにサーバーファイアウォールを弱めてはいけません。
テスト中にNATカウンターとファイアウォールログを監視する
関連するルーターのカウンターをクリアまたは記録し、狭いテストルールでログを有効にしてから、外部からの接続試行を一度送信します。重要なポイントは、WANパケットがNATルールに一致するか、変換後のパケットが許可ルールに一致するかです。
MikroTikのトラブルシューティング事例では、NATルールとファイアウォールルールの両方が必要であることがよくあると説明しています。変換は宛先を変更しますが、ファイアウォールが転送フローを許可することを保証しません。
どちらのカウンターも変化しない場合は、パブリックアドレス、外部ポート、インターフェース、上流NATを調査してください。NATは増加するが許可ルールが増加しない場合は、ルールの順序と変換後の宛先を確認します。両方が増加する場合は、サーバーでキャプチャしてパケットが到達しているか確認してください。
内部ターゲット、プロトコル、戻り経路を確認する
NATルールがサーバーの現在の予約済みアドレスと正しい内部ポートを指していることを確認してください。アプリケーションがTCP、UDP、または両方を期待しているかを確認してください。TCPのテストが成功してもUDP専用サービスについては何も示しません。
PortForwardのトラブルシューティングガイドでは、よくある2つのミスとして、誤ったコンピュータへの転送とルーターのルール作成後にソフトウェアファイアウォールがアプリをブロックしていることを挙げています。
パケットがサーバーに到達しても返信が返らない場合は、サーバーのゲートウェイ、ポリシールーティング、コンテナネットワーク、非対称マルチNIC経路を調査してください。サービスは着信パケットによって作成されたファイアウォールとNATの状態を保持する経路を通じて返信を返す必要があります。
公開を維持する必要がない場合はテストルールを削除する
問題のある層が特定できたら、最小限の修正を適用し、同じ外側から内側へのテストを繰り返してください。何かが変わるかどうかを見るためにポート範囲を開放したり、ファイアウォール全体を無効にしたりしないでください。
ZimaSpaceのホームサーバーの公開状況確認ガイドは、転送ルールが機能し始めた後の次のセキュリティチェックを提供します。
サービスが意図的にインターネット向けで、認証済み、パッチ適用済み、ログ記録され、管理インターフェースから分離されている場合のみ公開ルールを維持してください。プライベートなダッシュボード、SSH、SMB、個人ファイルには、VPNや認証済みトンネルの方が恒久的な転送ポートよりも明確な境界となることが多いです。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
