Mengapa akses jarak jauh Plex gagal di balik VPN dan cara memperbaikinya

Akses jarak jauh berubah menjadi tidak tersedia saat VPN mengambil alih rute default, sementara server yang sama terus melakukan streaming ke LAN tanpa keluhan. Tidak ada apa pun di log Plex yang menjelaskan perubahan itu, karena Plex bukan bagian yang rusak: ia menerbitkan alamat yang tidak lagi dituju lalu lintas. Penyedia yang membagi satu alamat publik di antara pelanggan meneruskan sebuah port ke alamat tunnel Anda, dan sesuatu di mesin Anda sendiri masih harus memindahkan port itu ke pendengar Plex. Ketiga mata rantai harus sepakat pada satu port eksternal sebelum uji keterjangkauan berubah hijau.

Rantai itu punya tiga mata rantai, dan Plex hanya melihat yang terakhir

Penyedia memiliki alamat publik dan memetakan salah satu portnya ke alamat tunnel Anda. Mesin Anda mengambil apa pun yang tiba di port itu dan mengalihkannya ke pendengar Plex, yang biasanya berada di port loopback 32400. Plex lalu diberi tahu nomor port eksternal agar probe-nya sendiri cocok dengan yang didail dunia luar.

Putuskan satu mata rantai saja dan antarmuka web melaporkan akses jarak jauh sebagai tidak tersedia, tanpa petunjuk mata rantai mana yang gagal. Kesunyian itulah sebabnya orang menyalakan ulang server, memasang ulang aplikasi, dan membalik pengaturan berulang kali tanpa menggerakkan jarum. Ketiga mata rantai gagal secara independen: penerusan yang diarahkan ke alamat tunnel usang, pengalihan yang hanya mencakup antarmuka Ethernet, dan bidang Plex yang masih menyimpan 32400 semuanya menghasilkan teks merah yang sama. Bekerjalah dari pendengar ke luar alih-alih menebak, dan mata rantai yang bermasalah biasanya menyebut namanya sendiri dalam satu menit.

Mata rantai satu: teruskan port di penyedia VPN

Buka halaman penerusan port penyedia dan tambahkan pemetaan. Sebagian besar implementasi memberi Anda port eksternal acak dan membiarkan Anda memilih yang internal, jadi terima penetapan itu dan arahkan ke alamat tunnel yang dipegang klien Anda saat ini. Catat nomor itu, karena setiap langkah berikutnya mengulanginya persis.

Penyedia yang merotasi pemetaan saat menyambung ulang adalah alasan biasa mengapa pengaturan ini bertahan satu malam lalu mati. Sebagian membiarkan Anda meminta port stabil, yang lain menetapkan ulang satu port pada setiap jabat tangan, jadi baca halaman pemetaan saat ini sebelum menyentuh hal lain.

Mata rantai dua: alihkan port dengan anchor pf

Di macOS pengalihan berada di anchor pf, satu aturan per antarmuka yang dapat membawa paket. Tulis aturan tunnel lebih dulu dan aturan Ethernet setelahnya, dengan port eksternal yang sama pada keduanya, jika tidak lalu lintas yang tiba lewat Wi-Fi selama failover tidak mendarat di mana pun.

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

File anchor saja tidak melakukan apa pun; konfigurasi utama harus merujuknya dan memuatnya. Letakkan dua baris ini di /etc/pf.conf sebelum aturan pengalihan yang ada, lalu muat ulang dan baca kembali apa yang benar-benar diterima kernel.

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

Keluhan sintaksis tentang port yang tidak dikenal berarti ada placeholder yang bertahan dari suntingan Anda. Tabel nat yang kosong berarti anchor tidak pernah dimuat, dan karena pf tidak diaktifkan secara default di macOS saat ini, sudo pfctl -E termasuk dalam perbaikan, bukan dalam tambahan opsional. Muat ulang anchor setelah setiap reboot dan setelah setiap perubahan pemetaan. Simpan file anchor di kontrol versi agar perubahan port penyedia menjadi suntingan satu baris, bukan latihan penemuan ulang.

Mata rantai tiga: pin port yang sama di dalam Plex

Di Plex, buka Pengaturan, lalu Server, lalu Akses Jarak Jauh, dan centang kotak yang memungkinkan Anda menentukan port secara manual. Masukkan port eksternal penyedia alih-alih 32400, lalu biarkan uji keterjangkauan berjalan. Build yang lebih baru memindahkan kontrol ini dari halaman Connect lama, jadi lihat di bawah Akses Jarak Jauh jika bidangnya tidak ada di tempat yang diklaim panduan.

Menguji dari LAN tidak membuktikan apa pun. Laptop di Wi-Fi yang sama mencapai server secara langsung, jadi probe berhasil bahkan saat jalur publik mati. Gunakan ponsel dengan data seluler, atau host mana pun di luar jaringan Anda, dan dail alamat publik serta port eksternal dari sana.

Konfirmasi setiap mata rantai sebelum menyalahkan Plex

Mulai dari pendengar dan bekerja ke luar. Jika Plex hanya terikat ke alamat LAN, ia akan mengabaikan pengalihan yang diarahkan ke loopback, jadi perintah pertama adalah yang membuktikan di mana ia mendengarkan.

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

Berikutnya, buktikan bahwa pengalihan itu ada dan cocok dengan port yang Anda berikan ke penyedia. Tabel nat seharusnya menunjukkan port eksternal yang sama pada kedua antarmuka.

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

Jalankan perintah terakhir itu dari luar jaringan, bukan dari Mac. Jika koneksi TCP selesai dari data seluler sementara Plex masih menampilkan tidak tersedia, port sampai ke pendengar dan tersangka yang tersisa adalah nomor yang diketik di bidang Plex. Jika tidak ada yang menjawab sama sekali, putusannya di hulu: pemetaan penyedia, alamat tunnel, atau pf yang tidak diaktifkan.