ルーターを交換すると、通常はリモートアクセスが機能しなくなります。新しいルーターによってローカルアドレス、NATルール、WANの動作、またはDNSの更新内容が変わるためです。
ホームサーバーはローカルでは引き続き動作していても、外部からの経路がすべて失敗することがあります。交換したルーターが別のDHCPサブネットを開始したり、NASに新しいアドレスを割り当てたり、手動のポート転送を失ったり、別のファイアウォールプロファイルを有効にしたり、古いモデムのNAT配下に入ったり、DDNSを誤ったエンドポイントで更新したりするためです。最も安全な復旧方法は、サーバーから外側に向かって経路を再構築し、各段階の後に本当に外部のネットワークからテストすることです。
古いルーターと新しいルーターの間で変わった内容を記録する
古いLANサブネット、サーバーのアドレス、DHCP予約、転送ポート、WANモード、DDNSプロバイダー、IPv6の状態、VPN設定、ルーターの前段にあるモデムやISPゲートウェイの情報を書き留めます。これらの値を交換後の機器と比較してください。
Synologyコミュニティの事例では、ルーターのアップグレード後にNASへのリモートアクセスが停止し、既存のポート転送でも応答が返らなくなりました。この事例は、ルーター固有の転送状態は自動的に移行されると考えず、再構築する必要があることを示しています。
古い設定をすべて無条件にインポートしないでください。現在も必要な公開サービスを特定し、そのための最小限のルール、予約、証明書、DNSエントリだけを再作成します。
ホームサーバーの現在のLANアドレスを予約する
新しいLAN上で、サーバーの実際のIPv4およびIPv6アドレス、デフォルトゲートウェイ、サブネットマスクを確認します。次に、そのプライベートアドレスを各ポート転送またはVPNルールに保存されている転送先と比較します。
ポート転送に関するガイダンスでは、転送先の機器には安定したローカルアドレスが必要だと説明されています。DHCPの変更によって、サーバーがLAN上の別の場所では見えていても、ルールが誤った内部機器を指す可能性があるためです。
サーバーの現在のMACアドレスを使ってDHCP予約を作成し、一度再接続します。新しいルーターのDHCPプールと競合する固定アドレスや、以前のサブネットの古いゲートウェイを引き継ぐ設定は避けてください。
手動のポート転送とローカルファイアウォールルールを再作成する
まずサービスがローカルで待ち受けていることを確認し、外部ポート、内部アドレス、内部ポート、TCPまたはUDPプロトコルを正確に再作成します。サービスごとに、モバイルデータ通信からテストしてください。
Plexのリモートアクセスに関するトラブルシューティングでは、ルーターによって変更または別の形で再作成される可能性があるUPnPマッピングに依存するより、手動転送のほうが安定する場合が多いと説明されています。有効なのは、予約済みのサーバーアドレスに対する固定の手動ポート転送です。
ルーターのファイアウォールとサーバーのファイアウォールを別々に確認します。新しいルーターがWANからの入力をブロックしている場合、サーバーが古いサブネットだけを信頼している場合、またはアプリケーションが別のインターフェースで待ち受けている場合、転送されたパケットは引き続き失敗します。
新しいルーターのWANアドレスと公開アドレスを比較する
交換後のルーターに表示されるWANアドレスを確認し、外部の公開IPアドレス確認結果と比較します。一致しない場合は、古いISPゲートウェイが引き続きルーティングしている、新しいルーターが二重NAT配下にある、またはISPが接続をCGNAT配下に移行した可能性があります。
現在のホームラボ向けリモートアクセスガイドでは、CGNATや動的IPアドレスの変更が通常のポート転送エラーに見えることがあるため、WANアドレスと公開アドレスを比較するよう推奨しています。この比較により、新しいルーターが公開エンドポイントを保持しているかを特定できます。
古いモデムがまだルーティングしている場合は、ブリッジモードまたはパススルーモードを使用するか、両方の層を通して転送します。ISPが上流のNATを管理している場合は、より広範なローカルルールを開放するのではなく、公開アドレス、IPv6、アウトバウンドトンネル、またはリレーを選択してください。
DDNS、IPv6、VPNの設定を意図的に再構築する
ルーターのDDNSクライアントが、意図したホスト名、アカウント、インターフェース、アドレスファミリーを使用しているか確認します。公開されているAレコードとAAAAレコードを、新しいルーターから到達可能な公開経路と比較してください。
WDコミュニティの復旧事例では、ルーター上で明示的な手動マッピングを設定し、自動UPnPの動作を置き換えることでリモートアクセスが復旧しました。
VPNのキーとルートは必要な場合にのみ再インポートします。ルーターの交換によって、VPNサブネット、DNSサーバー、ファイアウォールゾーン、公開されるLANルートが変わる可能性があります。新しいIPv6経路の準備ができていない場合は、古いAAAAレコードを削除してください。
外部から検証し、一時的な公開設定を削除する
モバイルデータ通信から公開ホスト名に接続し、DNS、TCP接続、TLS証明書、アプリケーションへのログイン、実際のリモート操作を記録します。NATループバックを通したローカルテストでは、インターネットからの到達性を証明できません。
リモートアクセスが古いアドレスの状態に従う理由に関するZimaSpaceのガイドでは、ルーターは動作しているのにクライアントが古いエンドポイントを参照し続ける場合の次の対処層について説明しています。
予約済みのサーバーアドレス、最小限のルーターのルール、公開DNS、ファイアウォール、アプリケーションのすべてが一致した時点で、復旧は完了です。管理されたテストが成功したら、一時的なDMZ、広範な許可ルール、重複するUPnPマッピングを無効にしてください。
サポートとヒント
もっと読む

Plexは別のDockerコンテナとGPUを共有できますか?
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。

Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。

Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。

