Kodėl Plex nuotolinė prieiga neveikia už VPN ir kaip tai sutvarkyti

Nuotolinė prieiga tampa nepasiekiama tą akimirką, kai VPN perima numatytąjį maršrutą, o tas pats serveris toliau be priekaištų transliuoja į LAN. Nieko Plex žurnaluose šio pokyčio nepaaiškina, nes Plex nėra sugedusi dalis: jis skelbia adresą, į kurį srautas nebeateina. Teikėjas, kuris vieną viešą adresą dalijasi tarp klientų, persiunčia prievadą į jūsų tunelio adresą, ir kažkas jūsų pačių kompiuteryje vis tiek turi perkelti tą prievadą į Plex klausytuvą. Visos trys grandys turi sutarti dėl vieno išorinio prievado, kol pasiekiamumo testas taps žalias.

Grandinėje yra trys grandys, o Plex mato tik paskutinę

Teikėjas turi viešą adresą ir vieną savo prievadų susieja su jūsų tunelio adresu. Jūsų kompiuteris paima viską, kas ateina į tą prievadą, ir peradresuoja į Plex klausytuvą, kuris paprastai sedi grįžtamosios kilpos prievade 32400. Tada Plex pasakomas išorinio prievado numeris, kad jo paties patikra atitiktų tai, ką renka išorinis pasaulis.

Nutraukite bet kurią vieną grandį ir žiniatinklio sąsaja praneša, kad nuotolinė prieiga nepasiekiama, visiškai neužsimindama, kuri grandis sugedo. Ši tyla yra priežastis, kodėl žmonės perkrauna serverį, iš naujo įdiegia programą ir vėl bei vėl perjungia nustatymą, bet rodyklė nejuda. Trys grandys genda nepriklausomai: persiuntimas į pasenusį tunelio adresą, peradresavimas, apimantis tik Ethernet sąsają, ir Plex laukas, kuriame vis dar įrašyta 32400, duoda tą patį raudoną tekstą. Dirbkite nuo klausytuvo į išorę, o ne spėliokite, ir sugedusi grandis paprastai pati save įvardija per minutę.

Pirmoji grandis: persiųskite prievadą VPN teikėjo svetainėje

Atidarykite teikėjo prievadų persiuntimo puslapį ir pridėkite susiejimą. Dauguma įgyvendinimų duoda atsitiktinį išorinį prievadą ir leidžia pasirinkti vidinį, todėl priimkite priskyrimą ir nukreipkite jį į tunelio adresą, kurį jūsų klientas šiuo metu turi. Užsirašykite tą numerį, nes kiekvienas vėlesnis žingsnis jį tiksliai kartoja.

Teikėjai, kurie susiejimą sukioja atkūrus ryšį, yra įprasta priežastis, kodėl ši sąranka išgyvena vieną vakarą ir tada miršta. Vieni leidžia paprašyti stabilaus prievado, kiti priskiria naują prie kiekvieno suspaudimo rankos, todėl prieš liedami ką nors kitą perskaitykite dabartinį susiejimo puslapį.

Antroji grandis: peradresuokite prievadą pf inkaru

macOS sistemoje peradresavimas priklauso pf inkarui, po vieną taisyklę kiekvienai sąsajai, kuri gali pernešti paketą. Pirmiausia parašykite tunelio taisyklę, paskui Ethernet taisyklę, abiejose nurodydami tą patį išorinį prievadą, antraip srautas, atėjęs per Wi-Fi perjungimo metu, niekur nenusileis.

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

Inkaro failas pats savaime nieko nedaro; pagrindinė konfigūracija turi į jį nurodyti ir jį įkelti. Įdėkite šias dvi eilutes į /etc/pf.conf prieš bet kokias esamas peradresavimo taisykles, tada įkelkite iš naujo ir perskaitykite, ką branduolys iš tikrųjų priėmė.

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

Sintaksės skundas dėl nežinomo prievado reiškia, kad jūsų pataisyme liko vietos žymeklis. Tuščia nat lentelė reiškia, kad inkaras niekada nebuvo įkeltas, o kadangi pf dabartinėje macOS nėra įjungtas pagal nutylėjimą, sudo pfctl -E priklauso taisymui, o ne pasirenkamiems priedams. Įkelkite inkarą iš naujo po kiekvieno perkrovimo ir po kiekvieno susiejimo pakeitimo. Laikykite inkaro failą versijų kontrolėje, kad teikėjo prievado pakeitimas taptų vienos eilutės pataisa, o ne nauju atradimu.

Trečioji grandis: prisekite tą patį prievadą Plex viduje

Plex atidarykite Nustatymus, tada Serverį, tada Nuotolinę prieigą ir pažymėkite langelį, leidžiantį nurodyti prievadą rankiniu būdu. Įveskite teikėjo išorinį prievadą vietoj 32400, tada leiskite pasiekiamumo testui pasileisti. Naujesnės versijos perkėlė šį valdiklį iš senesnio Connect puslapio, todėl ieškokite po Nuotoline prieiga, jei laukas ne ten, kur teigia vadovas.

Testavimas iš LAN nieko neįrodo. Nešiojamasis kompiuteris tame pačiame Wi-Fi pasiekia serverį tiesiogiai, todėl patikra pavyksta net tada, kai viešasis kelias miręs. Naudokite telefoną su mobiliaisiais duomenimis arba bet kurį prieglobos kompiuterį už jūsų tinklo ribų ir iš ten surinkite viešąjį adresą bei išorinį prievadą.

Patvirtinkite kiekvieną grandį, prieš kaltindami Plex

Pradėkite nuo klausytuvo ir eikite į išorę. Jei Plex susietas tik su LAN adresu, jis nepaisys peradresavimo į grįžtamąją kilpą, todėl pirmoji komanda yra ta, kuri įrodo, kur jis klausosi.

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

Toliau įrodykite, kad peradresavimas egzistuoja ir atitinka prievadą, kurį davėte teikėjui. nat lentelė turėtų rodyti tą patį išorinį prievadą abiejose sąsajose.

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

Paleiskite šią paskutinę komandą už tinklo ribų, o ne iš Mac. Jei TCP ryšys užsimezga iš mobiliųjų duomenų, o Plex vis dar rodo nepasiekiamumą, prievadas pasiekia klausytuvą, o likęs įtariamasis yra skaičius, įvestas į Plex lauką. Jei niekas visai neatsako, trūkis yra aukščiau: teikėjo susiejimas, tunelio adresas arba neįjungtas pf.