Chromecast ও DLNA ডিসকভারি কখনোই রাউটেড VPN পার হয় না

কাস্ট বোতাম কিছুই দেখায় না, VLC DLNA খালি থাকে, আর অপর প্রান্তের মেশিন কোনো অভিযোগ ছাড়াই ping-এর উত্তর দেয়। এই সমন্বয়টি ব্যান্ডউইথের সমস্যা নয়, ফায়ারওয়ালের রহস্যও নয়। এই প্রোটোকলগুলিতে ডিসকভারি হলো লোকাল সেগমেন্টে একটি গ্রুপ বিনিময়, এবং রাউটেড টানেল গ্রুপ-ঠিকানার ট্রাফিক বহন করে না. যে সেশনটি আপনি শুরু করতে চাইছেন তা কখনোই প্রস্তাবিত হয় না।

পৌঁছানো ঠিকই আছে। ডিসকভারি অনুপস্থিত।

কিংবদন্তি: টানেলের একটি সেটিং বা বেশি ক্যাপাসিটি দরকার

সাধারণ পরামর্শ হলো পিয়ার-টু-পিয়ার ট্রাফিক চালু করা, MTU বাড়ানো বা টানেল ডিভাইসের ধরন বদলানো। এর কোনোটিই ব্রডকাস্ট ডোমেইন যোগ করে না। মাল্টিকাস্ট সুইচ ও লোকাল নেটওয়ার্ক স্ট্যাক সরবরাহ করে, আর পয়েন্ট-টু-পয়েন্ট TUN ইন্টারফেসের প্লাবিত করার মতো কোনো গ্রুপ ঠিকানা নেই।

সেটিংস বদলালে ব্যর্থতা আরও জোরে শোনাতে পারে। কিন্তু প্রোটোকল যেখানে কখনো ঘোষণা পাঠায়নি, সেখানে এটি ঘোষণা হাজির করতে পারে না।

ডিসকভারি বিনিময়টি আসলে কী

তিনটি ধরন আপনার দেখা প্রায় সবকিছুই কভার করে। mDNS 224.0.0.251-এ UDP 5353 দিয়ে পাঠায়, SSDP 239.255.255.250-এ UDP 1900 দিয়ে পাঠায়, আর পুরোনো SMB ব্রাউজ তালিকা সাবনেট ব্রডকাস্ট ঠিকানায় যেত। প্রত্যেকটি হোস্টের বদলে একটি গ্রুপকে সম্বোধন করে, এবং প্রত্যেকটি একই সেগমেন্টে শ্রোতা আশা করে। রাউটেড টানেলের ওপারে থাকা গ্রহীতা সেই সেগমেন্টে নেই, তাই কিছুই পৌঁছায় না।

এমনকি রিলে করা ঘোষণাও একটি পেলোড বহন করে: সাধারণত প্রেরকের LAN ঠিকানা ও পোর্ট, যেখানে দূরবর্তী দর্শককে তখন পৌঁছাতে হয়।

টানেল বদলানোর আগে একটি ক্যাপচার পড়ুন

অ্যাপ স্ক্যান করার সময় টানেল ইন্টারফেসে ক্যাপচার করুন। খালি ক্যাপচার মানে ঘোষণাটি কখনোই সীমা পার হয়নি, আর টানেলের যতই টিউনিং করুন তা বদলায় না। অ্যাপ তখনো কিছু না দেখালেও যে প্যাকেটগুলো আসে, সাধারণত বোঝায় বিজ্ঞাপিত ঠিকানাটি দর্শকের কাছে পৌঁছানো যায় না — এটি ডিসকভারির পোশাক পরা একটি রাউটিং সমস্যা।

দুই মিনিটের ক্যাপচার পোর্ট নিয়ে এক ঘণ্টার অনুমানের বিকল্প: tcpdump -ni tun0 udp port 5353 or udp port 1900।

তিনটি সমাধান, সবচেয়ে সস্তাটি আগে

ক্লায়েন্টকে সরাসরি পরিষেবার ঠিকানায় নির্দেশ করুন। DLNA, SMB ও সাধারণ মিডিয়া সার্ভারের জন্য এটি ডিসকভারি সম্পূর্ণ এড়িয়ে যায় এবং পেলোড পথটি কাজ করে তা প্রমাণ করে, ফলে এটি সেরা প্রথম পরীক্ষা এবং ব্যবহারযোগ্য একটি সমাধানও। Chromecast ব্যতিক্রম, কারণ গ্রহীতা সম্বোধিত হওয়ার বদলে খুঁজে পাওয়ার প্রত্যাশা করে।

গেটওয়েতে প্রোটোকলটি রিলে করুন। একটি mDNS রিফ্লেক্টর টানেল ও LAN-এর মধ্যে ঘোষণা পুনরাবৃত্তি করে, আর Avahi একটি রিফ্লেক্টর অংশ দেয় যা স্পষ্ট ইন্টারফেস তালিকা নেয়। রিলে সংকীর্ণ রাখুন, এবং নিশ্চিত করুন বিজ্ঞাপিত ঠিকানাটি দুই দিক থেকেই পৌঁছানো যায়, নইলে উত্তরটি তখনো এমন সাবনেটের দিকে দেখায় যেখানে দর্শক রাউট করতে পারে না।

রাউটিংয়ের বদলে ব্রিজ করুন। সার্ভার tap ডিভাইসটিকে LAN-এ ব্রিজ করা একটি TAP সেগমেন্ট দুই প্রান্তকে এক ব্রডকাস্ট ডোমেইনে রাখে, তাই ঘোষণাগুলি অপরিবর্তিতভাবে পার হয়। এটি সবচেয়ে ব্যয়বহুল বিকল্পও, কারণ এক সাবনেট মানে এক ব্যর্থতার ডোমেইন এবং LAN-এর প্রতিটি মাল্টিকাস্ট পরিষেবা এখন প্রতিটি পিয়ারে পৌঁছায়।

যা কাজে লাগে না, যতবারই প্রস্তাব করা হোক

ব্রিজ ছাড়া dev tun-কে dev tap দিয়ে বদলালে একটি TAP ডিভাইস থেকে যায় যা তখনো রাউটেড, তাই আচরণ বদলায় না। client-to-client পিয়ার-টু-পিয়ার ইউনিকাস্টের অনুমতি দেয় এবং ব্রডকাস্ট প্লাবিত করে না। একটি ডিসকভারি পোর্ট এক হোস্টে ফরওয়ার্ড করলে গ্রুপ-ঠিকানার ট্রাফিক পৌঁছায় না। একটি ঠিকানায় বাঁধা মিডিয়া সার্ভার তার নিজের কনফিগারেশন VPN ইন্টারফেস তালিকাভুক্ত না করা পর্যন্ত সেই ঠিকানাতেই উত্তর দিতে থাকে।

একটি সরাসরি ইউনিকাস্ট অনুরোধ পরীক্ষা করুন, তারপর একটি ঘোষিত অনুরোধ। যদি প্রথমটি কাজ করে আর দ্বিতীয়টি না করে, টানেল সুস্থ এবং ডিসকভারিই পুরো সমস্যা।