Prečo vzdialený prístup Plexu nefunguje za VPN a ako to opraviť
Vzdialený prístup Plexu za VPN potrebuje tri články: presmerovanie portu u poskytovateľa, lokálne presmerovanie pf a rovnaký externý port zadaný v Plexe.
Vzdialený prístup sa prepne na nedostupný v okamihu, keď VPN prevezme predvolenú trasu, zatiaľ čo ten istý server ďalej streamuje do LAN bez sťažností. Nič v protokoloch Plexu zmenu nevysvetľuje, pretože Plex nie je časť, ktorá sa pokazila: publikuje adresu, kam premávka už nedorazí. Poskytovateľ, ktorý zdieľa jednu verejnú adresu medzi zákazníkmi, presmeruje port na adresu vášho tunela a niečo na vašom vlastnom stroji ešte musí ten port presunúť k poslucháčovi Plexu. Všetky tri články sa musia zhodnúť na jednom externom porte, kým test dostupnosti zozeleňuje.
Reťaz má tri články a Plex vidí iba ten posledný
Poskytovateľ vlastní verejnú adresu a mapuje jeden zo svojich portov na adresu vášho tunela. Váš stroj vezme všetko, čo na ten port dorazí, a presmeruje to k poslucháčovi Plexu, ktorý zvyčajne sedí na loopback porte 32400. Potom sa Plexu povie číslo externého portu, aby jeho vlastná sonda zodpovedala tomu, čo vytočí vonkajší svet.
Prerušte ktorýkoľvek jeden článok a webové rozhranie hlási vzdialený prístup ako nedostupný, bez akéhokoľvek náznaku, ktorý článok zlyhal. To ticho je dôvod, prečo ľudia reštartujú server, preinštalujú aplikáciu a znova a znova prepínajú nastavenie, no ručička sa nepohne. Tri články zlyhávajú nezávisle: presmerovanie namierené na zastaranú adresu tunela, presmerovanie pokrývajúce iba rozhranie Ethernet a pole Plexu, ktoré stále drží 32400, dávajú rovnaký červený text. Pracujte od poslucháča smerom von namiesto hádania, a chybný článok sa zvyčajne do minúty pomenuje sám.
Prvý článok: presmerujte port u poskytovateľa VPN
Otvorte stránku presmerovania portov poskytovateľa a pridajte mapovanie. Väčšina implementácií vám dá náhodný externý port a nechá vás vybrať vnútorný, takže priradenie prijmite a namierte ho na adresu tunela, ktorú váš klient práve drží. Zapíšte si to číslo, pretože každý ďalší krok ho presne opakuje.
Poskytovatelia, ktorí mapovanie pri opätovnom pripojení otáčajú, sú obvyklým dôvodom, prečo toto nastavenie vydrží večer a potom zomrie. Niektorí vám dovolia požiadať o stabilný port, iní priraďujú nový pri každom podaní ruky, takže si prečítajte aktuálnu stránku mapovania, kým sa dotknete čohokoľvek iného.
Druhý článok: presmerujte port pomocou kotvy pf
V macOS presmerovanie patrí do kotvy pf, jedno pravidlo pre každé rozhranie, ktoré môže niesť paket. Napíšte pravidlo tunela prvé a pravidlo Ethernet druhé, s rovnakým externým portom na oboch, inak premávka prichádzajúca cez Wi-Fi počas prepnutia 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
Súbor kotvy sám o sebe nič nerobí; hlavná konfigurácia naň musí odkazovať a načítať ho. Tieto dva riadky vložte do /etc/pf.conf pred všetky existujúce pravidlá presmerovania, potom znova načítajte a prečítajte si, čo jadro skutočne prijalo.
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
Sťažnosť na syntax pre neznámy port znamená, že vašu úpravu prežil zástupný symbol. Prázdna tabuľka nat znamená, že kotva sa nikdy nenačítala, a keďže pf nie je v aktuálnom macOS predvolene zapnutý, sudo pfctl -E patrí k oprave, nie k voliteľným doplnkom. Kotvu znova načítavajte po každom reštarte a po každej zmene mapovania. Držte súbor kotvy pod kontrolou verzií, aby sa zmena portu u poskytovateľa stala úpravou jedného riadku namiesto nového objavovania.
Tretí článok: pripnite ten istý port vnútri Plexu
V Plexe otvorte Nastavenia, potom Server, potom Vzdialený prístup a zaškrtnite políčko, ktoré vám umožní zadať port ručne. Zadajte externý port poskytovateľa namiesto 32400 a nechajte test dostupnosti bežať. Novšie zostavy presunuli tento prvok zo staršej stránky Connect, takže sa pozrite pod Vzdialený prístup, ak pole nie je tam, kde tvrdí návod.
Testovanie z LAN nedokazuje vôbec nič. Notebook na tej istej Wi-Fi sa k serveru dostane priamo, takže sonda uspeje, aj keď je verejná cesta mŕtva. Použite telefón s mobilnými dátami alebo akýkoľvek hostiteľ mimo vašej siete a odtiaľ vytočte verejnú adresu a externý port.
Potvrďte každý článok, kým obviníte Plex
Začnite pri poslucháčovi a postupujte smerom von. Ak je Plex viazaný iba na adresu LAN, bude ignorovať presmerovanie namierené na loopback, takže prvým príkazom je ten, ktorý dokazuje, kde načúva.
sudo lsof -nP -iTCP:32400 -sTCP:LISTEN
Potom dokážte, že presmerovanie existuje a zodpovedá portu, ktorý ste dali poskytovateľovi. Tabuľka nat by mala ukazovať rovnaký externý port na oboch rozhraniach.
sudo pfctl -s nat | grep 41893
nc -vz 203.0.113.42 41893
Spustite ten posledný príkaz zvonku siete, nie z Macu. Ak sa TCP spojenie dokončí z mobilných dát, zatiaľ čo Plex stále ukazuje nedostupnosť, port sa k poslucháčovi dostáva a zostávajúcim podozrivým je číslo zadané do poľa Plexu. Ak nič vôbec neodpovedá, prerušenie je vyššie: mapovanie u poskytovateľa, adresa tunela alebo nezapnutý pf.