Hvorfor Plex-fjerntilgang svigter bag en VPN, og hvordan du retter det

Fjerntilgang skifter til utilgængelig i det øjeblik, en VPN overtager standardruten, mens den samme server fortsætter med at streame til LAN uden klager. Intet i Plex-loggene forklarer skiftet, fordi Plex ikke er den del, der gik i stykker: den offentliggør en adresse, hvor trafikken ikke længere lander. En udbyder, der deler én offentlig adresse mellem kunder, videresender en port til din tunneladresse, og noget på din egen maskine skal stadig flytte den port til Plex-lytteren. Alle tre led skal være enige om én ekstern port, før tilgængelighedstesten bliver grøn.

Kæden har tre led, og Plex ser kun det sidste

Udbyderen ejer en offentlig adresse og mapper en af sine porte til din tunneladresse. Din maskine tager alt, hvad der ankommer på den port, og omdirigerer det til Plex-lytteren, som normalt sidder på loopback-port 32400. Derefter får Plex at vide, hvad den eksterne port hedder, så dens egen sonde matcher det, omverdenen ringer til.

Bryd et enkelt led, og webgrænsefladen rapporterer fjerntilgang som utilgængelig, uden antydning af hvilket led der fejlede. Den tavshed er grunden til, at folk genstarter serveren, geninstallerer appen og slår indstillingen til og fra igen og igen uden at flytte nålen. De tre led fejler uafhængigt: en videresendelse rettet mod en forældet tunneladresse, en omdirigering, der kun dækker Ethernet-grænsefladen, og et Plex-felt, der stadig holder 32400, giver alle den samme røde tekst. Arbejd udad fra lytteren i stedet for at gætte, og det fejlende led navngiver sig normalt inden for et minut.

Led et: videresend en port hos VPN-udbyderen

Åbn udbyderens side for portforwarding, og tilføj en mapping. De fleste implementeringer giver dig en tilfældig ekstern port og lader dig vælge den interne, så accepter tildelingen, og peg den mod den tunneladresse, din klient har i øjeblikket. Skriv det tal ned, fordi hvert senere trin gentager det præcist.

Udbydere, der roterer mappingen ved genopkobling, er den sædvanlige grund til, at dette setup overlever en aften og derefter dør. Nogle lader dig anmode om en stabil port, andre tildeler en ny ved hvert håndtryk, så læs den aktuelle mapping-side, før du rører ved noget andet.

Led to: omdiriger porten med et pf-anker

På macOS hører omdirigeringen i et pf-anker, én regel pr. grænseflade, der kan bære pakken. Skriv tunnelreglen først og Ethernet-reglen derefter, med den samme eksterne port på begge, ellers lander trafik, der ankommer over Wi-Fi under et failover, ingen steder.

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

Ankerfilen alene gør ingenting; hovedkonfigurationen skal referere til den og indlæse den. Sæt disse to linjer i /etc/pf.conf før eventuelle eksisterende omdirigeringsregler, genindlæs derefter, og læs tilbage, hvad kernen faktisk accepterede.

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

En syntaksklage over en ukendt port betyder, at en pladsholder overlevede din redigering. En tom nat-tabel betyder, at ankeret aldrig blev indlæst, og da pf ikke er aktiveret som standard på nuværende macOS, hører sudo pfctl -E til i rettelsen snarere end i de valgfrie ekstra. Genindlæs ankeret efter hver genstart og efter hver ændring af mappingen. Hold ankerfilen under versionskontrol, så en ændring af udbyderens port bliver en redigering på én linje i stedet for en nyopdagelse.

Led tre: fastgør den samme port inde i Plex

I Plex åbner du Indstillinger, derefter Server, derefter Fjerntilgang, og sætter flueben i feltet, der lader dig angive en port manuelt. Indtast udbyderens eksterne port i stedet for 32400, og lad derefter tilgængelighedstesten køre. Nyere versioner har flyttet denne kontrol væk fra den ældre Connect-side, så kig under Fjerntilgang, hvis feltet ikke er, hvor en vejledning påstår.

Test fra LAN beviser overhovedet intet. En bærbar på samme Wi-Fi når serveren direkte, så sonden lykkes, selv mens den offentlige vej er død. Brug en telefon på mobildata, eller enhver vært uden for dit netværk, og ring til den offentlige adresse og eksterne port derfra.

Bekræft hvert led, før du giver Plex skylden

Begynd ved lytteren og arbejd udad. Hvis Plex kun er bundet til LAN-adressen, ignorerer den en omdirigering rettet mod loopback, så den første kommando er den, der beviser, hvor den lytter.

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

Bevis derefter, at omdirigeringen findes og matcher den port, du gav udbyderen. nat-tabellen bør vise den samme eksterne port på begge grænseflader.

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

Kør den sidste kommando udefra netværket, ikke fra Mac'en. Hvis TCP-forbindelsen fuldføres fra mobildata, mens Plex stadig viser utilgængelig, når porten lytteren, og den resterende mistænkte er tallet, der er skrevet i Plex-feltet. Hvis intet svarer overhovedet, er bruddet længere oppe: udbyderens mapping, tunneladressen eller pf, der ikke er aktiveret.