VPN দিয়ে Wake-on-LAN কাজ করছে না? ব্রডকাস্ট কখনোই পার হয় না

টানেল চালু এবং শেয়ারগুলো উত্তর দিচ্ছে, তবুও মেশিন ঘুমিয়ে থাকে। magic packet লক্ষ্যের নিজের সেগমেন্টেই পাঠাতে হয়, তাই সেখানে একজন সহায়ক রাখুন।

আপনি অফিসের মেশিন ঘুম পাড়ান, বাড়ি থেকে VPN সংযোগ দেন, আর সেটি বন্ধই থাকে। টানেল চালু, ফাইল শেয়ার উত্তর দিচ্ছে, এবং রাউটারের wake-on-LAN পাতা জানাচ্ছে যে সে অনুরোধ পাঠিয়েছে। প্রতিটি দৃশ্যমান সংকেত বলে নেটওয়ার্ক ঠিক আছে, আর ঠিক এজন্যই এই ঘটনাটি বিভ্রান্তিকর: যে ফ্রেমটি মেশিনকে জাগাবে সেটি কখনোই সেই সেগমেন্টে পৌঁছায় না যেখানে মেশিনটি আছে।

উপসর্গগুলো সাবনেটের দিকে ইশারা করে, টানেলের দিকে নয়

ঘুমন্ত হোস্টে পিং ব্যর্থ হয়, আর ওই অংশটি স্বাভাবিক। স্ট্যান্ডবাইয়ের মেশিনে চালু IP স্ট্যাক থাকে না, তাই সে ARP বা ICMP-তে উত্তর দিতে পারে না, এবং কোনো টানেল কনফিগারেশন তা বদলায় না। উপকারী পরীক্ষা হলো একই LAN-এর দ্বিতীয় মেশিন জাগে কি না, এবং রাউটারের নিজের জাগানোর পাতা তার সাথে যুক্ত হোস্টের জন্য কাজ করে কি না।

একই সেগমেন্টে পরীক্ষা পাস হলে ত্রুটি পরিধিতে। আপনি যে প্রেরক ব্যবহার করছেন সে VPN ইন্টারফেসে থাকে, আর সে যে প্যাকেট বানায় তা স্থানীয় লিংকের জন্য ব্রডকাস্ট, তাই সেটি ভুল ইন্টারফেস দিয়ে বেরোয় বা একেবারেই বেরোয় না। টানেল খারাপ নয়; এটি ভুল ধরনের ট্রাফিক বহন করছে। রাউটারের একটি সেটিংও বদলানোর আগে জেনে নিন প্রেরক কোন ইন্টারফেস বেছে নেয়।

magic packet একটি ফ্রেম, সেবা নয়

পেলোড ছয় বাইটের স্থির হেডার 0xFF দিয়ে শুরু হয়, তারপর লক্ষ্য কার্ডের হার্ডওয়্যার ঠিকানা ষোলোবার পুনরাবৃত্ত হয়, তারপর আসে চার বাইটের ঐচ্ছিক SecureOn পাসওয়ার্ড। প্রেরকেরা এটি সাধারণত UDP-তে মুড়ে পোর্ট 7 বা পোর্ট 9-এ পাঠায়, কিন্তু পোর্ট নম্বর প্রেরক ও কার্ডের মধ্যে একটি রীতি, শোনা-সেবা নয় যাতে সংযোগ করা যায়। কিছুই শোনে না, আর কিছুই উত্তর দেয় না।

মেশিনকে জাগায় নেটওয়ার্ক ইন্টারফেস, যা স্ট্যান্ডবাই রেল থেকে অল্প সার্কিট্রিতে বিদ্যুৎ দিয়ে রাখে যখন বাকি সিস্টেম বন্ধ থাকে। তাই সেটিংকে পুরো বিদ্যুৎ চলে যাওয়া এবং ঘুম দুটোই সহ্য করতে হয়: বন্ধ হওয়ার সময় স্ট্যান্ডবাই বিদ্যুৎ কেটে দেওয়া বোর্ডের কাছে আর কিছু নেওয়ার কার্ড থাকে না।

রাউটেড টানেল এটি কেন পৌঁছাতে পারে না

রাউটেড VPN ইন্টারফেস দুই টানেল ঠিকানার মধ্যে বিন্দু-থেকে-বিন্দু IP লিংক। এটি পিয়ারকে সম্বোধন করা প্যাকেট বহনের জন্য আছে, তাই পিং, SSH ও ফাইল শেয়ার এর মধ্য দিয়ে স্বাভাবিকভাবে চলে। ব্রডকাস্ট ফ্রেম সেই পিয়ারকে সম্বোধন করা নয়, এবং সীমিত ব্রডকাস্ট ঠিকানা রাউটার কখনোই নিজে থেকে এগিয়ে পাঠায় না।

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

কার্ড পর্যন্ত সত্যিই পৌঁছায় এমন তিনটি স্থান

প্রতিটি কার্যকর বিন্যাস ফ্রেমকে লক্ষ্যের সেগমেন্টে রাখে, আর তারা আলাদা এই বিষয়ে যে নেটওয়ার্ককে কতটা বিরক্ত করে:

  1. লক্ষ্য সেগমেন্টে সবসময় চালু থাকা একটি ডিভাইস রাখুন। বিদ্যুতে থাকা রাউটার, NAS বা ছোট লিনাক্স বাক্স ফ্রেমটি স্থানীয়ভাবে পাঠাতে পারে, টানেল দিয়ে সেখানে পৌঁছানোমাত্র, আর VPN-এ কিছুই বদলায় না।
  2. রাউটারকে নিজেই ফ্রেম পাঠাতে দিন। অনেক ফার্মওয়্যার জাগানোর পাতা দেয় যা LAN ব্রিজ থেকে পাঠায়, আর এটি ততক্ষণ চলে যতক্ষণ লক্ষ্য ওই ব্রিজে থাকে, দ্বিতীয় রাউটারের পিছনে নয়।
  3. ব্রডকাস্ট সত্যিই পার হতে হলে স্থানগুলোকে TAP ধরনের টানেল দিয়ে সেতু করুন। এটি দুটি ব্রডকাস্ট ডোমেইন মেলায়, সাথে ব্রডকাস্ট ঝড়, একটাই ঠিকানা পরিকল্পনা এবং দুটি স্থান একসাথে দেখা প্রতিটি আবিষ্কার প্রোটোকল নিয়ে আসে।

প্রথম বিকল্পটি একটি মেশিনের জন্য পছন্দনীয়। তৃতীয়টি অব্যাহত খরচের নেটওয়ার্ক নকশা সিদ্ধান্ত, তাই সেটিকে তেমনই ভাবুন, একটি ডেস্কটপের জন্য দ্রুত সমাধান নয়।

কোন সহায়ক ফ্রেম পাঠায় এবং সে কোন ব্রিজ বা VLAN-এ আছে লিখে রাখুন। ভুল ইন্টারফেস থেকে পাঠানো সহায়ক পূর্ণ রেকর্ডিং আর কখনো না-জাগা মেশিন দেয়, আর এই জোড়া একটি দুপুর খেয়ে ফেলে।

ক্লায়েন্টকে দোষ দেওয়ার আগে পাঠানো যাচাই করুন

আগে লক্ষ্য কার্ড দেখুন, কারণ কোনো প্রেরকই প্রস্তুত নয় এমন কার্ড জাগাতে পারে না। নিচের নির্দেশটি সমর্থিত ও বর্তমান জাগানোর মোড পড়ে, যেখানে বর্তমান g মানের অর্থ magic packet চালু আছে:

ethtool enp3s0 | grep -A1 'Wake-on'
ip neigh show 192.168.1.50
tcpdump -ni br0 -e 'ether broadcast and udp dst port 9'
etherwake -i br0 3c:7c:3f:00:11:22

পাঠানোর সময় সহায়কে রেকর্ডিং চালান এবং সফলতা ধরে নেওয়ার বদলে সেটি পড়ুন। সঠিক ব্রিজ থেকে ব্রডকাস্ট লক্ষ্য MAC নিয়ে বেরোনো ফ্রেমই পাঠানো কাজ করেছে এর একমাত্র প্রমাণ; রেকর্ডিং খালি হলে প্রেরক অন্য ইন্টারফেস বেছেছে আর বাকি পরীক্ষা অর্থহীন। যে প্রেরক UDP ডেটাগ্রামের বদলে কাঁচা ফ্রেম বানায় সে ওই ফিল্টারে বসে না, তাই কিছুই পাঠানো হয়নি এমন সিদ্ধান্তে পৌঁছানোর আগে দেখুন আপনার যন্ত্র কোন আকৃতি ব্যবহার করে।

Windows-এ কার্ডের সমতুল্য পরীক্ষা powercfg /devicequery wake_armed, যা সিস্টেম জাগানোর অনুমতি পাওয়া ডিভাইসগুলো তালিকাভুক্ত করে। ওই তালিকা থেকে অনুপস্থিত নেটওয়ার্ক অ্যাডাপ্টার তার কাছে পাঠানো প্রতিটি প্যাকেট উপেক্ষা করবে, ফ্রেম তারে যতই সঠিক দেখাক।

তারপর জাগা এবং পরবর্তী কাজ নিশ্চিত করুন। যে মেশিন চালু হয় কিন্তু নামে অগম্য থাকে তার স্থির ঠিকানা ও DNS রেকর্ড দরকার, কারণ ব্রডকাস্টে নাম সমাধান এখনো টানেল পার হয় না। তারবিহীন জাগানো আলাদা এবং তারযুক্ত সংস্করণের চেয়ে অনেক কম নির্ভরযোগ্য ক্ষমতা, তাই VPN জড়ানোর আগেই একই সেগমেন্টে এটি পরীক্ষা করুন। টিকিটে ইন্টারফেসের নাম ও সহায়কের হোস্ট লিখুন, কারণ পরের ত্রুটি সাধারণত ওই দুই তথ্য নিয়েই।

সম্পর্কিত নিবন্ধ