توقف البث عند استخدام 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 |
دوّن المرحلة قبل تغيير أي شيء. الإصلاح المطبّق على المرحلة الخطأ يجعل الاختبار التالي غير مقروء، ومعظم الحكايات الشائعة عن البث تنبع من هذا الالتباس تحديدًا.
الاكتشاف حركة محلية، والنفق يخفيها
تعلن المستقبِلات عن نفسها عبر إعلانات محلية، ويعثر عليها الهاتف باستعلامات على الرابط نفسه، لذا فأي شيء يزيل الهاتف من ذلك الرابط يزيل المستقبِل من القائمة. والنفق الذي يوجّه كل الحركة بعيدًا عن الشبكة المحلية يمكن أن يخفي تلك التبادلات، كما أن إذن الشبكة المحلية على مستوى التطبيق يمكن أن يحجبها حتى عندما يكون المسار موجودًا. وشبكة Wi-Fi للضيوف مع عزل العملاء تنتج القائمة الفارغة نفسها دون أي VPN إطلاقًا. أثبت أن الجهازين يتشاركان مقطعًا واحدًا قبل لوم النفق.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRيسرد الأمر الأول ما يعلن عن نفسه في مقطع الجهاز المساعد، ويسأل الثاني مجموعة DNS المتعددة الإرسال مباشرة. والمستقبِل الغائب عن كليهما لن يظهر في تطبيق الهاتف أيضًا، مهما كانت حالة النفق على الهاتف. وإذا كان المستقبِل مرئيًا من جهاز نفقُه مغلق وغير مرئي من جهاز نفقُه مفتوح، فقد وجدت المرحلة والسبب معًا.
استثناء الشبكة المحلية يُبقي النفق قائمًا
توفّر عملاء كثيرة استثناءً للشبكة المحلية يُبقي النفق نشطًا مع السماح بالعناوين المحلية. استخدم ذلك الإعداد الموثق بدلًا من تعطيل مفتاح الإيقاف أو جدار الحماية كله، لأن تلك تغيّر أكثر بكثير مما يحتاجه البث. وإذا كانت الشبكة تفصل الأجهزة الذكية عن عمد، فاطلب من المالك حركة الاكتشاف والتحكم والعودة المحددة بدلًا من طلب وصول مفتوح.
nc -vz 192.168.1.50 8009يفصل اختبار تحكم تجاه المستقبِل بين الإذن والقابلية للوصول: فنفاذ المنفذ يعني أن المسار قائم، بينما يعني الرفض أن الهاتف سُمح له باكتشاف الجهاز ومع ذلك لا يستطيع مخاطبته. والمنفذان 8008 و8009 هما منفذا البث المعتادان، وقد يستخدم تطبيق منافذ أخرى، لذا تعامل مع منفذ واحد مرفوض كتلميح لا كحكم. ويبقى الاستثناء وإذن التطبيق مستقلين، لأن منح الوصول المحلي لا ينشئ مسارًا وإضافة مسار لا تمنح إذنًا. كما أن مفتاح الإيقاف قد يُسقط الحركة المحلية بعد إعادة الاتصال، ولهذا يجب إعادة اختبار الاكتشاف بمجرد عودة النفق.
قد لا يستخدم البث اتصال الهاتف
في الجلسة التي يوجّهها التطبيق يمنح الهاتف المستقبِل عنوان وسائط، ثم يجلبه المستقبِل عبر اتصاله الخاص، لذا فإن تغيير العنوان العام للهاتف لا يفعل شيئًا للبث. وقد يفشل عنوان مقيّد بحساب لأسبابه الخاصة، وتغطي متطلبات البث لدى Google توافق التطبيق والجهاز لا مسار الشبكة. أما توجيه التلفاز نفسه عبر نفق فهو إعداد منفصل بأسئلة سياسة خاصة به.
يفرّق دليلان بين الوضعين. فالبث الذي يستمر عند قفل شاشة الهاتف يوجّهه التطبيق، لأن المستقبِل يجلب بنفسه؛ أما النسخ المتطابق الذي يتوقف عند قفل شاشة المرسل فهو بث متواصل من الهاتف. وعندما ينجح الاكتشاف والتحكم ويتعثر البث، فانظر بدلًا من ذلك إلى وصلة Wi-Fi للمستقبِل ومساره إلى الإنترنت، لأن اختبار السرعة على الهاتف يصف الهاتف لا التلفاز.
ألغِ الاستثناء وأعد الاختبار
كل تغيير مؤقت يحتاج طريقًا للعودة، والترتيب مهم. أزل استثناء الشبكة المحلية، وأعد توصيل النفق ليعيد العميل تطبيق سياسته، ثم كرّر خطوة الاكتشاف ولاحظ هل يختفي المستقبِل مرة أخرى. ذلك التسلسل يخبرك هل كان الاستثناء هو الذي يقوم بالعمل أم أن شيئًا آخر تغيّر في الأثناء.
# 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'تحقّق من المراحل الثلاث منفصلة بعد ذلك، لأن نجاح واحدة لا يقول شيئًا عن الأخريين. ثم تحقّق من أن تطبيقات الهاتف غير ذات الصلة ما زالت تتبع المسار المقصود، لأن استثناءً محليًا صار بصمت تجاوزًا كاملًا نتيجة أسوأ من بث يحتاج نقرة إضافية واحدة.