چرا پس از فعال کردن VPN روتر، پخش روی تلویزیون متوقف می‌شود
کشف دستگاه از طریق چندپخشی محلی انجام می‌شود، در حالی که تلویزیون خودش رسانه را دریافت می‌کند. یک سیاست پیش‌فرض می‌تواند درخواست شبکه محلی را بگیرد و به تونل بفرستد.
پخش پیش از فعال شدن VPN روتر کار می‌کرد و بلافاصله بعد از آن از کار می‌افتد، در حالی که مرور عادی روی گوشی همچنان کار می‌کند. این دو واقعیت با هم سازگارند، چون پخش یک اتصال واحد نیست. گوشی گیرنده را از طریق شبکه محلی پیدا و کنترل می‌کند و سپس گیرنده رسانه را از طریق اتصال خودش دریافت می‌کند.
دو مسیر که به شکل‌های متفاوت خراب می‌شوند
مسیر کنترل محلی است. گوشی با پرسیدن از شبکه محلی گیرنده را پیدا می‌کند و سپس یک اتصال کنترل به نشانی‌ای که یاد گرفته باز می‌کند. اگر گیرنده هرگز در فهرست ظاهر نشود، مرحله کشف پیش از درخواست هر رسانه‌ای شکست خورده است.
مسیر رسانه لزوماً محلی نیست. بسیاری از گیرنده‌ها خودشان جریان را دریافت می‌کنند، از طریق اتصال خودشان و با اعتبارنامه‌های خودشان، بنابراین مسیر گوشی مسیر گیرنده را توصیف نمی‌کند. گوشی‌ای که به نظر می‌رسد از یک خروجی استفاده می‌کند، هیچ چیزی درباره مقصد ترافیک تلویزیون نمی‌گوید.
همین شکاف باعث می‌شود خرابی عجیب به نظر برسد. تونل جدول مسیریابی گوشی را تغییر داد و جدول تلویزیون را تغییر نداد، بنابراین نشانه‌ای که در یک طرف این جفت ظاهر می‌شود باید در همان طرف ردیابی شود. ردیابی دستگاه اشتباه دلیل معمول این است که یک راه‌حل به نظر می‌رسد هیچ کاری نمی‌کند.
چرا کشف اول از همه می‌شکند
کشف معمولاً از طریق چندپخشی پیوند محلی انجام می‌شود. mDNS به 224.0.0.251 روی درگاه UDP شماره 5353 می‌فرستد و SSDP به 239.255.255.250 روی درگاه UDP شماره 1900. هر دو بر اساس طراحی به یک پیوند محدود هستند، و به همین دلیل روتر آن‌ها را بدون کمک یک تکرارکننده یا پروکسی بین بخش‌ها ارسال نمی‌کند. VPN مسیریابی‌شده یک گروه چندپخشی را گسترش نمی‌دهد و مسیر سیاست نمی‌تواند گروهی را که هرگز از پیوند خارج نشده در پیوند دیگری ظاهر کند.
پس اولین خرابی هیچ ارتباطی با رمزگذاری ندارد. بسته‌های چندپخشی گوشی از رابطی که روی آن فرستاده شده خارج می‌شوند، گیرنده در بخشی است که هرگز آن را نمی‌بیند و فهرست دستگاه‌ها خالی برمی‌گردد. فهرست خالی مدرکی بر از دست رفتن دسترسی تلویزیون به اینترنت نیست.
جداسازی بدون هیچ VPN همان نشانه را تولید می‌کند. شبکه‌های مهمان و جداسازی مشتری در نقاط دسترسی عمداً جلوی گفت‌وگوی دستگاه‌ها با یکدیگر را می‌گیرند و فعال کردن VPN روتر روی یک بخش جداشده چیزی را در این باره تغییر نمی‌دهد. تنظیم جداسازی را پیش از تونل بررسی کنید. این پاسخ ارزان‌تر و رایج‌تر است.
چیدمان بخش‌ها نیمه دیگر ماجراست. یک روتر دوم، یک گره مش در حالت متفاوت یا یک بخش سیمی پشت NAT دیگر، همه گیرنده را جایی قرار می‌دهند که ترافیک کشف گوشی به آن نمی‌رسد.
چرا یک سیاست پیش‌فرض می‌تواند یک درخواست محلی را ببلعد
روتری که همه ترافیک را به تونل هدایت می‌کند، یک مسیر پیش‌فرض روی رابط تونل نصب می‌کند. اگر پیشوند شبکه محلی از آن سیاست مستثنا نشود، بسته‌ای که به دستگاهی دو متر آن‌طرف‌تر نشانی شده اکنون با پیش‌فرض مطابقت می‌کند و روتر درخواست کنترل را به جای سوئیچ به تونل می‌فرستد.
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
ترتیب قواعد نتیجه را تعیین می‌کند. مسیریابی سیاستی قواعد را به ترتیب اولویت ارزیابی می‌کند، بنابراین استثنای پیشوند محلی باید پیش از قاعده‌ای بیاید که جدول تونل را انتخاب می‌کند. افزودن استثنا بعد از قاعده تونل هیچ اثری ندارد، و به همین دلیل پیکربندی‌ای که درست به نظر می‌رسد می‌تواند باز هم ترافیک شبکه محلی را به یک خروجی دور بفرستد.
اصلاح باریک است: مقصدهای محلی مشخصی را که جریان پخش لازم دارد مجاز کنید و بقیه جداسازی را به حال خود بگذارید. برداشتن جداسازی مشتری به‌عنوان گام نخست نشانه را برطرف می‌کند، اما کنترلی را دور می‌ریزد که شبکه برای داشتنش طراحی شده بود.
یک جستجوی سریع روی گوشی روشن می‌کند کدام یک از دو خرابی را دارید. اگر مسیر تا گیرنده به تونل اشاره کند، سیاست مشکل است. اگر به شبکه محلی اشاره کند و کشف همچنان شکست بخورد، چندپخشی یا جداسازی مشکل است و هیچ تغییر مسیری کمک نمی‌کند.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpمرحله‌ای را که تغییر کرده آزمایش کنید، نه کشور را
مشاهدات ثبت‌شده از آزمایش‌های تکراری بهترند. یادداشت کنید که گیرنده در فهرست دستگاه‌ها ظاهر می‌شود یا نه، درخواست کنترل به آن می‌رسد یا نه، و پخش پس از انتخاب جریان آغاز می‌شود یا نه. هر پاسخ یک مرحله را از ظن خارج می‌کند.
سپس هر مرحله را مستقیم آزمایش کنید، نه با عوض کردن محل خروجی. تغییر کشور VPN مسیر رسانه را آزمایش می‌کند و مراحل کشف و کنترل را دست‌نخورده می‌گذارد، پس می‌تواند تصادفاً کمک‌کننده به نظر برسد بدون آنکه چیزی به شما بیاموزد.
در سمت گیرنده، مسیر خودش و وضعیت حساب خودش را بررسی کنید. تلویزیونی که رسانه را از خروجی‌ای متفاوت از گوشی دریافت می‌کند طراحی طبیعی است و خرابی در آنجا پرسشی درباره سیاست شبکه گیرنده است، نه درباره تونل گوشی.
نتیجه را در یک جمله بنویسید: کدام مرحله شکست و چه چیزی آن را تغییر داد. آن جمله از یک هفته عوض کردن کشور ارزشمندتر است و از به‌روزرسانی بعدی میان‌افزار جان سالم به در می‌برد.
پخش نمونه آزمایش خوبی برای یک قاعده کلی درباره تونل‌هاست. وقتی تونلی به شبکه‌ای افزوده می‌شود، پرسش نخست این است که کدام مقصدها هرگز نباید به آن وارد می‌شدند. پرسش دوم این است که سیاست کدام‌یک از آن‌ها را با این حال بی‌صدا پذیرفت.