قطع شدن پخش با VPN: کشف، کنترل یا جریان؟
گیرندهٔ غایب، نشست ردشده و جریانی که متوقف می‌شود در جاهای مختلف شکست می‌خورند. پیش از تغییر سیاست VPN گوشی یا شبکه، مرحله را نام‌گذاری کنید.
پخش از سه جا می‌شکند که از روی مبل یکسان به نظر می‌رسند. ممکن است گوشی هرگز گیرنده را نبیند، گیرنده ظاهر شود و بعد نشست را رد کند، یا نشست آغاز شود و یک دقیقه بعد متوقف شود. تونل روی گوشی هر یک از این مسیرها را متفاوت تغییر می‌دهد و برای یکی از آن‌ها هیچ چیز را تغییر نمی‌دهد. نخست مرحلهٔ ناکام را نام‌گذاری کنید و سپس تصمیم بگیرید آیا تغییر سیاست حتی اهرم درست است.
پیش از تغییر سیاست، مرحلهٔ ناکام را نام‌گذاری کنید
ببینید گوشی بلافاصله پس از زدن نماد پخش چه می‌کند. فهرست خالی نتیجهٔ کشف است، ضربه‌ای که شکست را گزارش می‌کند نتیجهٔ کنترل است، و نشستی که پیش از توقف آغاز می‌شود نتیجهٔ پخش است. این سه صاحبان متفاوتی دارند و معمولاً فقط دو مورد نخست به تنظیمات تونل گوشی مربوط می‌شوند.
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
پیش از تغییر هر چیز، مرحله را بنویسید. اصلاحی که روی مرحلهٔ نادرست اعمال شود آزمون بعدی را ناخوانا می‌کند و بیشتر باورهای رایج دربارهٔ پخش دقیقاً از همین سردرگمی می‌آید.
کشف ترافیک محلی است و تونل آن را پنهان می‌کند
گیرنده‌ها خود را با اعلام‌های محلی معرفی می‌کنند و گوشی آن‌ها را با پرس‌وجوهای روی همان پیوند پیدا می‌کند، پس هر چیزی که گوشی را از آن پیوند حذف کند گیرنده را هم از فهرست حذف می‌کند. تونلی که همهٔ ترافیک را از LAN دور می‌کند می‌تواند آن تبادل‌ها را پنهان کند و اجازهٔ شبکهٔ محلی در سطح برنامه می‌تواند آن‌ها را حتی وقتی مسیر وجود دارد مسدود کند. وای‌فای مهمان با جداسازی کلاینت همان فهرست خالی را بدون هیچ VPN تولید می‌کند. پیش از متهم کردن تونل ثابت کنید دو دستگاه یک بخش را به اشتراک می‌گذارند.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRفرمان نخست فهرست می‌کند چه چیزی در بخش دستگاه کمکی خود را اعلام می‌کند و دومی مستقیماً از گروه DNS چندپخشی می‌پرسد. گیرنده‌ای که در هر دو غایب است در برنامهٔ گوشی هم ظاهر نمی‌شود، هر چه وضعیت تونل گوشی باشد. اگر گیرنده از دستگاهی با تونل خاموش دیده شود و از دستگاهی با تونل روشن دیده نشود، مرحله و علت را با هم یافته‌اید.
استثنای LAN تونل را روشن نگه می‌دارد
بسیاری از کلاینت‌ها استثنای شبکهٔ محلی را پیشنهاد می‌کنند که تونل را فعال نگه می‌دارد و در همان حال نشانی‌های محلی را مجاز می‌کند. از همان تنظیم مستند استفاده کنید نه از خاموش کردن kill switch یا کل دیوار آتش، چون آن‌ها بسیار بیشتر از نیاز پخش را تغییر می‌دهند. اگر شبکه دستگاه‌های هوشمند را عمداً جدا می‌کند، از مالک همان ترافیک مشخص کشف، کنترل و بازگشت را بخواهید نه دسترسی یکنواخت.
nc -vz 192.168.1.50 8009آزمون کنترل به سوی گیرنده اجازه را از دسترس‌پذیری جدا می‌کند: پورتی که پاسخ می‌دهد یعنی مسیر وجود دارد، در حالی که رد شدن یعنی به گوشی اجازه داده شد دستگاه را کشف کند و باز هم نمی‌تواند با آن حرف بزند. پورت‌های 8008 و 8009 پورت‌های معمول پخش هستند و یک برنامه ممکن است از پورت‌های دیگر استفاده کند، پس یک پورت ردشده را نشانه بگیرید نه حکم. استثنا و اجازهٔ برنامه مستقل می‌مانند، چون دسترسی محلی مسیر نمی‌سازد و افزودن مسیر اجازه نمی‌دهد. kill switch هم می‌تواند پس از اتصال دوباره ترافیک محلی را بیندازد، از این رو کشف باید به‌محض بازگشت تونل دوباره آزموده شود.
ممکن است پخش از اتصال گوشی استفاده نکند
در نشستی که برنامه هدایت می‌کند، گوشی نشانی رسانه را به گیرنده می‌دهد و گیرنده آن را از اتصال خودش می‌گیرد، پس تغییر نشانی عمومی گوشی برای جریان هیچ کاری نمی‌کند. عنوانی که به حساب محدود است ممکن است به دلایل خودش شکست بخورد و الزامات پخش گوگل سازگاری برنامه و دستگاه را پوشش می‌دهد نه مسیر شبکه را. عبور دادن خود تلویزیون از تونل پیکربندی جداگانه‌ای است با پرسش‌های سیاستی خودش.
دو نشانه این حالت‌ها را از هم جدا می‌کند. پخشی که با قفل شدن صفحهٔ گوشی دوام می‌آورد برنامه‌محور است، چون گیرنده خودش دریافت می‌کند؛ بازتابی که با قفل شدن صفحهٔ فرستنده می‌ایستد جریانی پیوسته از گوشی است. وقتی کشف و کنترل موفق می‌شوند اما پخش متوقف می‌شود، به‌جای آن به پیوند Wi-Fi گیرنده و مسیر اینترنتش نگاه کنید، چون آزمون سرعت روی گوشی گوشی را توصیف می‌کند نه تلویزیون را.
استثنا را برگردانید و دوباره بیازمایید
هر تغییر موقت راه بازگشت می‌خواهد و ترتیب مهم است. استثنای LAN را بردارید، تونل را دوباره وصل کنید تا کلاینت سیاستش را دوباره اعمال کند، سپس گام کشف را تکرار کنید و یادداشت کنید آیا گیرنده دوباره ناپدید می‌شود. همین توالی می‌گوید کار را استثنا انجام می‌داد یا چیز دیگری در این میان تغییر کرده است.
# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'بعد سه مرحله را جداگانه بررسی کنید، چون موفقیت در یکی دربارهٔ دیگران چیزی نمی‌گوید. سپس بررسی کنید برنامه‌های نامرتبط گوشی هنوز مسیر موردنظر را می‌روند، چون استثنای محلی که بی‌صدا به دور زدن کامل تبدیل شده نتیجه‌ای بدتر از پخشی است که یک ضربهٔ اضافه می‌خواهد.