VPN の背後で Plex のリモートアクセスが失敗する理由とその修正方法

VPN がデフォルトルートを引き継いだ瞬間にリモートアクセスは利用不可に切り替わりますが、同じサーバーは LAN への配信を何事もなく続けます。Plex のログに変更を説明する記述がないのは、壊れたのが Plex ではなく、Plex がトラフィックの届かなくなったアドレスを公開しているだけだからです。顧客間で一つのパブリックアドレスを共有するプロバイダーは、一つのポートをあなたのトンネルアドレスへ転送し、あなた自身のマシン上の何かがそのポートを Plex のリスナーへ運ぶ必要があります。到達性テストが緑になる前に、三つの環すべてが一つの外部ポートで一致していなければなりません。

連鎖には三つの環があり、Plex は最後の環しか見ていない

プロバイダーはパブリックアドレスを所有し、そのポートの一つをあなたのトンネルアドレスにマッピングし、あなたのマシンはそのポートに届いたものを受け取って Plex のリスナーへリダイレクトします。リスナーは通常、ループバックポート 32400 に座っています。次に Plex へ外部ポート番号を伝え、Plex 自身の検査が外の世界がダイヤルする内容と一致するようにします。

どれか一つの環が切れると、Web インターフェースはリモートアクセスを利用不可と報告し、どの環が失敗したのかは一切示しません。この沈黙のせいで、人はサーバーを再起動し、アプリを再インストールし、設定を何度も切り替えても針が動きません。三つの環は独立して失敗し、古いトンネルアドレスを狙った転送、Ethernet インターフェースだけを覆うリダイレクト、そして 32400 を保持したままの Plex のフィールドは、どれも同じ赤いテキストを生みます。推測するのではなくリスナーから外へ作業すれば、失敗した環はたいてい一分以内に名乗り出ます。

第一の環：VPN プロバイダーでポートを転送する

プロバイダーのポート転送ページを開き、マッピングを追加します。ほとんどの実装はランダムな外部ポートを渡して内部ポートを選ばせるので、割り当てを受け入れて、クライアントが現在保持しているトンネルアドレスへ向けます。以降のすべての手順がそれを正確に繰り返すので、その番号は必ず書き留めてください。

再接続時にマッピングをローテーションするプロバイダーが、この構成が一晩もってから死ぬ通常の原因です。安定したポートを要求できるところもあれば、ハンドシェイクごとに新しいポートを割り当てるところもあるので、他の何かに触れる前に現在のマッピングページを読んでください。

第二の環：pf アンカーでポートをリダイレクトする

macOS ではリダイレクトは pf アンカーに入り、パケットを運べるインターフェースごとに一つのルールです。まずトンネルのルール、次に Ethernet のルールを書き、両方に同じ外部ポートを置かないと、フェイルオーバー中に Wi-Fi で届いたトラフィックはどこにも着地しません。

# /etc/pf.anchors/plex.forward
rdr pass on tun0 inet proto tcp from any to any port 41893 -> 127.0.0.1 port 32400
rdr pass on en0 inet proto tcp from any to any port 41893 -> 127.0.0.1 port 32400

アンカーファイルはそれだけでは何もせず、メイン設定がそれを参照して読み込む必要があります。この二行を /etc/pf.conf に、既存のリダイレクトルールより前に置き、再読み込みしてカーネルが実際に何を受け入れたかを読み返してください。

rdr-anchor "plex"
load anchor "plex" from "/etc/pf.anchors/plex.forward"

sudo pfctl -vnf /etc/pf.anchors/plex.forward
sudo pfctl -f /etc/pf.conf
sudo pfctl -s nat

未知のポートに関する構文エラーは、編集からプレースホルダーが残ったという意味です。nat テーブルが空ならアンカーは一度も読み込まれておらず、現在の macOS では pf が標準で有効ではないため、sudo pfctl -E が修正の一部であり、任意の追加機能ではありません。再起動のたびに、またマッピングを変更するたびにアンカーを再読み込みしてください。アンカーファイルをバージョン管理下に置けば、プロバイダーのポート変更は再発見の作業ではなく一行の編集になります。

第三の環：Plex の中で同じポートを固定する

Plex で設定を開き、次にサーバー、次にリモートアクセスを開き、ポートを手動で指定できるボックスにチェックを入れます。32400 ではなくプロバイダーの外部ポートを入力し、到達性テストを実行させます。新しいビルドではこのコントロールが古い Connect ページから移されているので、フィールドがガイドの言う場所にない場合はリモートアクセスの下を探してください。

LAN からのテストは何も証明しません。同じ Wi-Fi 上のノートパソコンはサーバーへ直接届くので、公開経路が死んでいても検査は成功します。モバイルデータのスマートフォンか、ネットワーク外の任意のホストを使い、そこからパブリックアドレスと外部ポートをダイヤルしてください。

Plex を責める前に各環を確認する

リスナーから始めて外へ進みます。Plex が LAN アドレスだけにバインドされている場合、ループバック向けのリダイレクトを無視するので、最初のコマンドはどこで待ち受けているかを証明するものです。

sudo lsof -nP -iTCP:32400 -sTCP:LISTEN

次に、リダイレクトが存在し、プロバイダーに渡したポートと一致することを証明します。nat テーブルは両方のインターフェースで同じ外部ポートを示すはずです。

sudo pfctl -s nat | grep 41893
nc -vz 203.0.113.42 41893

最後のコマンドは Mac からではなく、ネットワークの外から実行してください。モバイルデータで TCP 接続が完了するのに Plex が利用不可を示すなら、ポートはリスナーに届いており、残る容疑者は Plex のフィールドに入力した番号です。何も応答しないなら、断絶は上流、つまりプロバイダーのマッピング、トンネルアドレス、または pf が有効でないことにあります。