Waarom Plex-afstandtoegang agter 'n VPN misluk en hoe om dit reg te maak

Afstandtoegang skakel na onbeskikbaar die oomblik wanneer 'n VPN die verstekroete oorneem, terwyl dieselfde bediener sonder klagte aan die LAN bly stroom. Niks in die Plex-logs verduidelik die verandering nie, want Plex is nie die deel wat gebreek het nie: dit publiseer 'n adres waarheen verkeer nie meer beland nie. 'n Verskaffer wat een openbare adres tussen kliënte deel, stuur 'n poort na jou tonneladres, en iets op jou eie masjien moet steeds daardie poort na die Plex-luisteraar skuif. Al drie skakels moet oor een eksterne poort ooreenstem voordat die bereikbaarheidstoets groen word.

Die ketting het drie skakels, en Plex sien net die laaste een

Die verskaffer besit 'n openbare adres en karteer een van sy poorte na jou tonneladres. Jou masjien neem alles wat op daardie poort aankom en herlei dit na die Plex-luisteraar, wat gewoonlik op luspoort 32400 sit. Plex kry dan die eksterne poortnommer te hoor sodat sy eie toets ooreenstem met wat die buitewêreld skakel.

Breek enige enkele skakel en die webkoppelvlak rapporteer afstandtoegang as onbeskikbaar, sonder enige aanduiding watter skakel gefaal het. Daardie stilte is hoekom mense die bediener herbegin, die app herinstalleer en die instelling oor en oor wissel sonder om die naald te verskuif. Die drie skakels faal onafhanklik: 'n forward wat op 'n verouderde tonneladres gemik is, 'n herleiding wat net die Ethernet-koppelvlak dek, en 'n Plex-veld wat steeds 32400 hou, lewer almal dieselfde rooi teks. Werk van die luisteraar uitwaarts eerder as om te raai, en die foutiewe skakel noem homself gewoonlik binne 'n minuut.

Skakel een: stuur 'n poort by die VPN-verskaffer

Maak die verskaffer se port forwarding-blad oop en voeg 'n kartering by. Meeste implementerings gee jou 'n ewekansige eksterne poort en laat jou die interne een kies, so aanvaar die toewysing en rig dit op die tonneladres wat jou kliënt tans hou. Skryf daardie nommer neer, want elke latere stap herhaal dit presies.

Verskaffers wat die kartering by herverbinding roteer, is die gewone rede waarom hierdie opstelling 'n aand oorleef en dan sterf. Sommiges laat jou 'n stabiele poort aanvra, ander ken een by elke handdruk opnuut toe, so lees die huidige karteringsblad voordat jy iets anders aanraak.

Skakel twee: herlei die poort met 'n pf-anker

Op macOS hoort die herleiding in 'n pf-anker, een reël per koppelvlak wat die pakket kan dra. Skryf die tonnelreël eerste en die Ethernet-reël tweede, met dieselfde eksterne poort op albei, anders beland verkeer wat tydens 'n failover oor Wi-Fi aankom, nêrens.

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

Die ankerlêer op sy eie doen niks; die hoofkonfigurasie moet dit verwys en laai. Sit hierdie twee reëls in /etc/pf.conf voor enige bestaande herleidingsreëls, herlaai dan en lees terug wat die kernel werklik aanvaar het.

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

'n Sintaksisklag oor 'n onbekende poort beteken dat 'n plekhouer jou wysiging oorleef het. 'n Leë nat-tabel beteken die anker het nooit gelaai nie, en aangesien pf nie by verstek op huidige macOS geaktiveer is nie, sudo pfctl -E hoort by die oplossing eerder as by die opsionele ekstras. Herlaai die anker ná elke herbegin en ná elke karteringsverandering. Hou die ankerlêer in weergawebeheer sodat 'n verskafferpoortverandering 'n eenreël-wysiging word eerder as 'n herontdekkingsproses.

Skakel drie: stel dieselfde poort binne Plex in

In Plex, maak Instellings oop, dan Server, dan Afstandtoegang, en merk die blokkie wat jou toelaat om 'n poort met die hand te spesifiseer. Voer die verskaffer se eksterne poort in eerder as 32400, en laat die bereikbaarheidstoets dan loop. Nuwer weergawes het hierdie beheer van die ouer Connect-blad weggeskuif, so kyk onder Afstandtoegang as die veld nie is waar 'n gids beweer nie.

Om vanaf die LAN te toets bewys heeltemal niks. 'n Skootrekenaar op dieselfde Wi-Fi bereik die bediener direk, so die toets slaag selfs terwyl die openbare pad dood is. Gebruik 'n selfoon op selfoondata, of enige gasheer buite jou netwerk, en skakel die openbare adres en eksterne poort van daar af.

Bevestig elke skakel voordat jy Plex blameer

Begin by die luisteraar en werk uitwaarts. As Plex net aan die LAN-adres gebind is, sal dit 'n herleiding na lus ignoreer, so die eerste opdrag is die een wat bewys waar dit luister.

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

Bewys volgende dat die herleiding bestaan en ooreenstem met die poort wat jy aan die verskaffer gegee het. Die nat-tabel behoort dieselfde eksterne poort op albei koppelvlakke te wys.

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

Voer daardie laaste opdrag van buite die netwerk uit, nie van die Mac nie. As die TCP-verbinding van selfoondata voltooi word terwyl Plex steeds onbeskikbaar wys, bereik die poort die luisteraar en die oorblywende verdagte is die nommer wat in die Plex-veld getik is. As niks hoegenaamd antwoord nie, is die breek stroomop: die verskafferkartering, die tonneladres, of pf wat nie geaktiveer is nie.