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 থেকে দূরে ঘুরিয়ে দেয় তা এই বিনিময়গুলো লুকাতে পারে, আর অ্যাপ স্তরের স্থানীয়-নেটওয়ার্ক অনুমতি রুট থাকলেও সেগুলো আটকে দিতে পারে। ক্লায়েন্ট আইসোলেশনসহ গেস্ট Wi-Fi কোনো VPN ছাড়াই একই খালি তালিকা তৈরি করে। টানেলকে দোষ দেওয়ার আগে প্রমাণ করুন যে দুটি ডিভাইস একই সেগমেন্ট ভাগ করে।
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRপ্রথম কমান্ডটি দেখায় সহায়ক মেশিনের সেগমেন্টে কে নিজের ঘোষণা দিচ্ছে, আর দ্বিতীয়টি সরাসরি মাল্টিকাস্ট DNS গ্রুপকে জিজ্ঞাসা করে। দুটোতেই অনুপস্থিত রিসিভার ফোনের অ্যাপেও দেখা যাবে না, ফোনের টানেল অবস্থা যা-ই হোক। রিসিভার যদি এমন ডিভাইস থেকে দেখা যায় যার টানেল বন্ধ এবং এমন ডিভাইস থেকে না দেখা যায় যার টানেল চালু, তবে আপনি ধাপ ও কারণ একসঙ্গে খুঁজে পেয়েছেন।
LAN ব্যতিক্রম টানেল চালু রাখে
অনেক ক্লায়েন্ট স্থানীয়-নেটওয়ার্ক ব্যতিক্রম দেয় যা স্থানীয় ঠিকানা অনুমোদন করেও টানেল সক্রিয় রাখে। কিল সুইচ বা পুরো ফায়ারওয়াল বন্ধ করার বদলে সেই নথিভুক্ত সেটিং ব্যবহার করুন, কারণ সেগুলো কাস্টিংয়ের প্রয়োজনের চেয়ে অনেক বেশি কিছু বদলে দেয়। নেটওয়ার্ক যদি ইচ্ছাকৃতভাবে স্মার্ট ডিভাইস আলাদা করে, তবে সমতল অ্যাক্সেস না চেয়ে মালিকের কাছে নির্দিষ্ট ডিসকভারি, কন্ট্রোল ও রিটার্ন ট্রাফিক চান।
nc -vz 192.168.1.50 8009রিসিভারের বিরুদ্ধে একটি কন্ট্রোল পরীক্ষা অনুমতিকে পৌঁছানোর ক্ষমতা থেকে আলাদা করে: যে পোর্ট উত্তর দেয় তার মানে পথটি আছে, আর প্রত্যাখ্যান মানে ফোনকে ডিভাইসটি ডিসকভার করার অনুমতি দেওয়া হয়েছিল এবং তবুও সে এর সঙ্গে কথা বলতে পারছে না। 8008 ও 8009 পোর্ট সাধারণত কাস্টের পোর্ট, আর কোনো অ্যাপ অন্য পোর্টও ব্যবহার করতে পারে, তাই একটিমাত্র প্রত্যাখ্যাত পোর্টকে রায় নয়, ইঙ্গিত হিসেবে নিন। ব্যতিক্রম ও অ্যাপ অনুমতি স্বতন্ত্র থাকে, কারণ স্থানীয় অ্যাক্সেস দেওয়া রুট তৈরি করে না এবং রুট যোগ করা অনুমতি দেয় না। কিল সুইচ পুনরায় সংযোগের পর স্থানীয় ট্রাফিকও ফেলে দিতে পারে, তাই টানেল ফিরে এলে ডিসকভারি আবার পরীক্ষা করতে হবে।
প্লেব্যাক ফোনের সংযোগ ব্যবহার না-ও করতে পারে
অ্যাপ-নির্দেশিত সেশনে ফোন রিসিভারকে একটি মিডিয়া ঠিকানা দেয় এবং রিসিভার তা নিজের সংযোগ দিয়ে নামায়, তাই ফোনের পাবলিক ঠিকানা বদলালে স্ট্রিমের কিছুই হয় না। অ্যাকাউন্ট-সীমাবদ্ধ শিরোনাম নিজের কারণেই ব্যর্থ হতে পারে, আর Google-এর কাস্টিংয়ের প্রয়োজনীয়তা অ্যাপ ও ডিভাইসের সামঞ্জস্য নিয়ে, নেটওয়ার্ক পথ নিয়ে নয়। টেলিভিশনটিকেই টানেলের মধ্য দিয়ে চালানো একটি আলাদা কনফিগারেশন, যার নিজস্ব নীতি-প্রশ্ন আছে।
দুটি সূত্র এই মোড দুটিকে আলাদা করে। যে কাস্ট ফোনের স্ক্রিন লক করলেও টিকে থাকে তা অ্যাপ-নির্দেশিত, কারণ রিসিভার নিজেই নামাচ্ছে; আর যে মিরর প্রেরকের স্ক্রিন লক হলে থেমে যায় তা ফোন থেকে আসা অবিরাম স্ট্রিম। ডিসকভারি ও কন্ট্রোল সফল হয়ে প্লেব্যাক আটকে গেলে বরং রিসিভারের 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'পরে তিনটি ধাপ আলাদাভাবে যাচাই করুন, কারণ একটিতে পাস হলেও অন্য দুটি সম্পর্কে কিছু বলা যায় না। তারপর দেখুন ফোনের অসংশ্লিষ্ট অ্যাপগুলো এখনও অভীষ্ট পথে চলছে কি না, কারণ চুপচাপ সম্পূর্ণ বাইপাসে পরিণত হওয়া স্থানীয় ব্যতিক্রম একটি অতিরিক্ত ট্যাপ দরকার হওয়া কাস্টের চেয়ে খারাপ ফল।