Защо отдалеченият достъп до Plex не работи зад VPN и как да го поправим

Отдалеченият достъп става недостъпен в момента, в който 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.