Почему удалённый доступ Plex не работает за VPN и как это исправить

Удалённый доступ становится недоступным в тот момент, когда VPN перехватывает маршрут по умолчанию, а тот же сервер продолжает без жалоб транслировать в LAN. Ничто в журналах Plex не объясняет изменение, потому что Plex не является сломавшейся частью: он публикует адрес, куда трафик больше не приходит. Провайдер, который делит один публичный адрес между клиентами, пробрасывает порт на адрес вашего туннеля, и что-то на вашей собственной машине всё ещё должно перенести этот порт к слушателю Plex. Все три звена должны договориться об одном внешнем порте, прежде чем тест доступности станет зелёным.

В цепочке три звена, и Plex видит только последнее

Провайдер владеет публичным адресом и сопоставляет один из своих портов с адресом вашего туннеля. Ваша машина берёт всё, что приходит на этот порт, и перенаправляет к слушателю Plex, который обычно сидит на петлевом порте 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, он проигнорирует перенаправление на петлю, поэтому первая команда — та, что доказывает, где он слушает.

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.