چرا دسترسی از راه دور 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.