Hvorfor Plex-fjerntilgang svikter bak en VPN, og hvordan du fikser det

Fjerntilgang slår over til utilgjengelig i det øyeblikket en VPN tar over standardruten, mens den samme serveren fortsetter å strømme til LAN uten klager. Ingenting i Plex-loggene forklarer endringen, fordi Plex ikke er delen som gikk i stykker: den publiserer en adresse der trafikken ikke lenger lander. En leverandør som deler én offentlig adresse mellom kunder, videresender en port til tunneladressen din, og noe på din egen maskin må fortsatt flytte den porten til Plex-lytteren. Alle tre leddene må bli enige om én ekstern port før tilgjengelighetstesten blir grønn.

Kjeden har tre ledd, og Plex ser bare det siste

Leverandøren eier en offentlig adresse og mapper en av portene sine til tunneladressen din. Maskinen din tar alt som kommer inn på den porten og omdirigerer det til Plex-lytteren, som vanligvis sitter på loopback-port 32400. Deretter får Plex vite nummeret på den eksterne porten, slik at dens egen sjekk samsvarer med det omverdenen ringer.

Bryt ett enkelt ledd, og nettgrensesnittet rapporterer fjerntilgang som utilgjengelig, uten antydning om hvilket ledd som feilet. Den stillheten er grunnen til at folk starter serveren på nytt, reinstallerer appen og slår innstillingen av og på igjen og igjen uten å flytte nålen. De tre leddene feiler uavhengig: en videresending rettet mot en utdatert tunneladresse, en omdirigering som bare dekker Ethernet-grensesnittet, og et Plex-felt som fortsatt holder 32400 gir alle den samme røde teksten. Arbeid utover fra lytteren i stedet for å gjette, og det feilende leddet navngir seg vanligvis innen et minutt.

Første ledd: videresend en port hos VPN-leverandøren

Åpne portvideresendingssiden til leverandøren og legg til en mapping. De fleste implementasjoner gir deg en tilfeldig ekstern port og lar deg velge den interne, så godta tildelingen og pek den mot tunneladressen klienten din har akkurat nå. Skriv ned det nummeret, fordi hvert senere trinn gjentar det nøyaktig.

Leverandører som roterer mappingen ved gjenoppkobling er den vanlige grunnen til at dette oppsettet overlever en kveld og deretter dør. Noen lar deg be om en stabil port, andre tildeler en ny ved hver håndtrykk, så les den gjeldende mapping-siden før du rører noe annet.

Andre ledd: omdiriger porten med et pf-anker

På macOS hører omdirigeringen til et pf-anker, én regel per grensesnitt som kan bære pakken. Skriv tunnelregelen først og Ethernet-regelen deretter, med den samme eksterne porten på begge, ellers lander trafikk som kommer over Wi-Fi under en 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 gjør ingenting; hovedkonfigurasjonen må referere til den og laste den. Sett disse to linjene i /etc/pf.conf før alle eksisterende omdirigeringsregler, last deretter inn på nytt og les tilbake hva kjernen faktisk godtok.

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 ukjent port betyr at en plassholder overlevde redigeringen din. En tom nat-tabell betyr at ankeret aldri ble lastet, og siden pf ikke er aktivert som standard på nåværende macOS, hører sudo pfctl -E til i fiksen og ikke i de valgfrie ekstra. Last ankeret på nytt etter hver omstart og etter hver mapping-endring. Hold ankerfilen under versjonskontroll slik at en leverandørportendring blir en redigering på én linje i stedet for en ny oppdagelse.

Tredje ledd: fest den samme porten inne i Plex

I Plex åpner du Innstillinger, deretter Server, deretter Fjerntilgang, og krysser av i boksen som lar deg angi en port manuelt. Skriv inn leverandørens eksterne port i stedet for 32400, og la deretter tilgjengelighetstesten kjøre. Nyere versjoner har flyttet denne kontrollen bort fra den eldre Connect-siden, så se under Fjerntilgang hvis feltet ikke er der en veiledning påstår.

Testing fra LAN beviser overhodet ingenting. En bærbar PC på samme Wi-Fi når serveren direkte, så sjekken lykkes selv mens den offentlige veien er død. Bruk en telefon på mobildata, eller en hvilken som helst vert utenfor nettverket ditt, og ring den offentlige adressen og den eksterne porten derfra.

Bekreft hvert ledd før du gir Plex skylden

Start ved lytteren og arbeid utover. Hvis Plex bare er bundet til LAN-adressen, vil den ignorere en omdirigering rettet mot loopback, så den første kommandoen er den som beviser hvor den lytter.

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

Deretter beviser du at omdirigeringen finnes og samsvarer med porten du ga leverandøren. nat-tabellen skal vise den samme eksterne porten på begge grensesnittene.

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

Kjør den siste kommandoen fra utenfor nettverket, ikke fra Macen. Hvis TCP-tilkoblingen fullføres fra mobildata mens Plex fortsatt viser utilgjengelig, når porten lytteren, og den gjenværende mistenkte er nummeret som er skrevet i Plex-feltet. Hvis ingenting svarer i det hele tatt, er bruddet lenger oppe: leverandørens mapping, tunneladressen eller pf som ikke er aktivert.