Vzdálený přístup se přepne na nedostupný ve chvíli, kdy VPN převezme výchozí trasu, zatímco stejný server dál streamuje do LAN bez stížností. Nic v protokolech Plexu změnu nevysvětluje, protože Plex není ta část, která se rozbila: publikuje adresu, kam už provoz nedorazí. Poskytovatel, který sdílí jednu veřejnou adresu mezi zákazníky, přesměruje port na adresu vašeho tunelu a něco na vašem vlastním stroji ještě musí ten port přesunout k posluchači Plexu. Všechny tři články se musí shodnout na jednom externím portu, než test dostupnosti zezelená.

Řetěz má tři články a Plex vidí jen ten poslední

Poskytovatel vlastní veřejnou adresu a mapuje jeden ze svých portů na adresu vašeho tunelu. Váš stroj vezme, co na ten port dorazí, a přesměruje to k posluchači Plexu, který obvykle sedí na loopback portu 32400. Plexu se pak sdělí číslo externího portu, aby jeho vlastní sonda odpovídala tomu, co vytáčí vnější svět.

Přerušte kterýkoli jednotlivý článek a webové rozhraní hlásí vzdálený přístup jako nedostupný, bez náznaku, který článek selhal. To ticho je důvod, proč lidé restartují server, přeinstalovávají aplikaci a znovu a znovu přepínají nastavení, aniž by se hnuli z místa. Tři články selhávají nezávisle: přesměrování namířené na zastaralou adresu tunelu, přesměrování pokrývající jen rozhraní Ethernet a pole Plexu, které stále drží 32400, dávají stejný červený text. Pracujte od posluchače ven místo hádání a vadný článek se obvykle do minuty pojmenuje sám.

První článek: přesměrujte port u poskytovatele VPN

Otevřete stránku přesměrování portů poskytovatele a přidejte mapování. Většina implementací vám dá náhodný externí port a nechá vás zvolit vnitřní, takže přiřazení přijměte a namiřte ho na adresu tunelu, kterou váš klient právě drží. To číslo si zapište, protože každý další krok ho přesně opakuje.

Poskytovatelé, kteří mapování při opětovném připojení rotují, jsou obvyklým důvodem, proč tato konfigurace vydrží večer a pak zemře. Někteří vám dovolí požádat o stabilní port, jiní přiřadí nový při každém handshaku, takže si přečtěte aktuální stránku mapování, než se dotknete čehokoli jiného.

Druhý článek: přesměrujte port pomocí kotvy pf

V macOS patří přesměrování do kotvy pf, jedno pravidlo pro každé rozhraní, které může nést paket. Napište pravidlo tunelu první a pravidlo Ethernet druhé, se stejným externím portem na obou, jinak provoz přicházející přes Wi-Fi během přepnutí nikam nedorazí.

# /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

Soubor kotvy sám o sobě nic nedělá; hlavní konfigurace na něj musí odkazovat a načíst ho. Tyto dva řádky vložte do /etc/pf.conf před všechna stávající pravidla přesměrování, poté znovu načtěte a přečtěte si, co jádro skutečně přijalo.

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

Syntaktická stížnost na neznámý port znamená, že vaši úpravu přežil zástupný symbol. Prázdná tabulka nat znamená, že se kotva nikdy nenačetla, a protože pf není v aktuálním macOS ve výchozím nastavení zapnutý, sudo pfctl -E patří k opravě, ne k volitelným doplňkům. Kotvu znovu načítejte po každém restartu a po každé změně mapování. Držte soubor kotvy ve správě verzí, aby se změna portu u poskytovatele stala úpravou jednoho řádku místo nového objevování.

Třetí článek: připněte stejný port uvnitř Plexu

V Plexu otevřete Nastavení, potom Server, potom Vzdálený přístup, a zaškrtněte políčko, které vám umožní zadat port ručně. Zadejte externí port poskytovatele místo 32400 a nechte test dostupnosti běžet. Novější sestavení přesunula tento prvek pryč ze starší stránky Connect, takže se podívejte pod Vzdálený přístup, pokud pole není tam, kde tvrdí návod.

Testování z LAN nedokazuje vůbec nic. Notebook na stejné Wi-Fi se k serveru dostane přímo, takže sonda uspěje, i když je veřejná cesta mrtvá. Použijte telefon s mobilními daty nebo jakýkoli hostitel mimo vaši síť a vytáčejte veřejnou adresu a externí port odtamtud.

Potvrďte každý článek, než obviníte Plex

Začněte u posluchače a postupujte ven. Pokud je Plex vázán jen na adresu LAN, bude ignorovat přesměrování namířené na loopback, takže prvním příkazem je ten, který dokáže, kde naslouchá.

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

Dále dokažte, že přesměrování existuje a odpovídá portu, který jste dali poskytovateli. Tabulka nat by měla ukazovat stejný externí port na obou rozhraních.

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

Spusťte ten poslední příkaz zvenčí sítě, ne z Macu. Pokud se TCP spojení dokončí z mobilních dat, zatímco Plex stále ukazuje nedostupnost, port se k posluchači dostává a zbývajícím podezřelým je číslo zadané do pole Plexu. Pokud vůbec nic neodpovídá, přerušení je výš: mapování u poskytovatele, adresa tunelu nebo nezapnutý pf.

Související články