Зошто далечинскиот пристап на Plex не работи зад VPN и како да го поправите
Далечинскиот пристап на Plex зад VPN бара три алки: пренасочување на порта кај провајдерот, локално pf пренасочување и истата надворешна порта внесена во Plex.
Далечинскиот пристап преминува во недостапен во моментот кога VPN ја презема стандардната рута, додека истиот сервер продолжува да стримува кон LAN без оплаквање. Ништо во дневниците на Plex не ја објаснува промената, бидејќи Plex не е делот што се расипа: тој објавува адреса каде сообраќајот повеќе не пристигнува. Провајдерот што дели една јавна адреса меѓу клиентите пренасочува порта кон адресата на вашиот тунел, а нешто на вашата сопствена машина се уште треба да ја премести таа порта до слушателот на Plex. Сите три алки мора да се согласат за една надворешна порта пред тестот за достапност да стане зелен.
Синџирот има три алки, а Plex ја гледа само последната
Провајдерот поседува јавна адреса и мапира една од своите порти на адресата на вашиот тунел. Вашата машина го зема сето што пристигнува на таа порта и го пренасочува до слушателот на Plex, кој обично седи на loopback портата 32400. Потоа на Plex му се кажува бројот на надворешната порта за да се совпадне неговата проверка со она што го бира надворешниот свет.
Прекинете која било поединечна алка и веб-интерфејсот го пријавува далечинскиот пристап како недостапен, без никаков навестување која алка откажала. Таа тишина е причината зошто луѓето го рестартираат серверот, ја реинсталираат апликацијата и ја префрлаат поставката одново и одново без да ја поместат иглата. Трите алки откажуваат независно: пренасочување насочено кон застарена адреса на тунел, пренасочување што ја покрива само Ethernet-интерфејсот и поле во Plex што се уште држи 32400 даваат ист црвен текст. Работете од слушателот кон надвор наместо да гаѓате, и неисправната алка обично се именува сама во рок од една минута.
Прва алка: пренасочете порта кај VPN провајдерот
Отворете ја страницата за пренасочување порти на провајдерот и додајте мапирање. Повеќето имплементации ви даваат случајна надворешна порта и ви дозволуваат да ја изберете внатрешната, затоа прифатете ја распределбата и насочете ја кон адресата на тунелот што вашиот клиент моментално ја има. Запишете го тој број, бидејќи секој следен чекор точно го повторува.
Провајдерите што го ротираат мапирањето при повторно поврзување се вообичаената причина зошто оваа поставка издржува една вечер и потоа умира. Некои дозволуваат да побарате стабилна порта, други доделуваат нова при секое ракување, затоа прочитајте ја тековната страница за мапирање пред да допрете нешто друго.
Втора алка: пренасочете ја портата со pf сидро
На macOS пренасочувањето припаѓа во pf сидро, едно правило по интерфејс што може да го носи пакетот. Прво напишете го правилото за тунелот, а потоа правилото за Ethernet, со истата надворешна порта на двете, инаку сообраќајот што пристигнува преку Wi-Fi за време на префрлање не слетува никаде.
# /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
Датотеката на сидрото сама по себе не прави ништо; главната конфигурација мора да се повика на неа и да ја вчита. Ставете ги овие два реда во /etc/pf.conf пред сите постоечки правила за пренасочување, потоа вчитајте повторно и прочитајте што јадрото навистина прифати.
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
Синтаксна жалба за непозната порта значи дека резервирано место го преживеало вашето уредување. Празна nat табела значи дека сидрото никогаш не било вчитано, и бидејќи pf не е овозможен стандардно на тековниот macOS, sudo pfctl -E припаѓа на поправката, а не на опционалните дополнитоци. Вчитајте го сидрото повторно по секое рестартирање и по секоја промена на мапирањето. Држете ја датотеката на сидрото под контрола на верзии, за да стане промената на портата кај провајдерот уредување на еден ред наместо ново откривање.
Трета алка: прицврстете ја истата порта внатре во Plex
Во Plex отворете Поставки, потоа Сервер, потоа Далечински пристап и штиклирајте го полето што ви дозволува рачно да одредите порта. Внесете ја надворешната порта на провајдерот наместо 32400, потоа пуштете го тестот за достапност. Поновите верзии го преместија ова управување од постарата страница Connect, затоа погледнете под Далечински пристап ако полето не е таму каде што тврди водич.
Тестирањето од LAN не докажува ништо. Лаптоп на истиот Wi-Fi стигнува до серверот директно, па проверката успева дури и кога јавната патека е мртва. Користете телефон со мобилни податоци или кој било домаќин надвор од вашата мрежа и од таму бирајте ја јавната адреса и надворешната порта.
Потврдете ја секоја алка пред да го обвините Plex
Започнете од слушателот и работете кон надвор. Ако Plex е врзан само за адресата на LAN, ќе го игнорира пренасочувањето кон loopback, затоа првата команда е онаа што докажува каде слуша.
sudo lsof -nP -iTCP:32400 -sTCP:LISTEN
Потоа докажете дека пренасочувањето постои и се совпаѓа со портата што му ја дадовте на провајдерот. nat табелата треба да ја покажува истата надворешна порта на двата интерфејса.
sudo pfctl -s nat | grep 41893
nc -vz 203.0.113.42 41893
Извршете ја таа последна команда од надвор од мрежата, не од Mac. Ако TCP врската се оствари од мобилни податоци додека Plex се уште покажува недостапност, портата стигнува до слушателот и преостанатиот осомничен е бројот внесен во полето на Plex. Ако ништо воопшто не одговори, прекинот е погоре: мапирањето кај провајдерот, адресата на тунелот или неовозможениот pf.