Чому віддалений доступ Plex не працює за VPN і як це виправити

Віддаленому доступу Plex за VPN потрібні три ланки: перенаправлення порту в провайдера, локальне перенаправлення pf і той самий зовнішній порт, введений у Plex.

Віддалений доступ стає недоступним у ту мить, коли 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.

Схожі статті