Pi-তে বদলে যাওয়া MAC ঠিকানা: কোন ইন্টারফেস বদলাল?

একটি Pi-তে VPN সেটআপ বসার পর কয়েকটি ইন্টারফেস পরিচয় সরে গেছে বলে মনে হতে পারে। গতকালের Ethernet ঠিকানা আজকের তালিকার সঙ্গে আর মেলে না, আর সিদ্ধান্ত নিজেই লিখে ফেলে: VPN-ই MAC বদলেছে। সাধারণত বদলায়নি। একটি ফিজিক্যাল আপলিংককে ব্রিজ বা ভার্চুয়াল অ্যাডাপ্টারের সঙ্গে তুলনা করা তুলনা নয়, আর প্রথম কাজ হলো আপনি আসলে কোন বস্তুর দিকে তাকিয়ে আছেন তা ঠিক করা।

ইন্টারফেস ও পর্যবেক্ষককে নাম দিন

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

সংযোগ ঘটনার আগে ও পরে একই ইন্টারফেসের জন্য এটি করুন। একটি বস্তুর দুইটি পর্যবেক্ষণ প্রমাণ; দুইটি বস্তুর একটিমাত্র পর্যবেক্ষণ গল্প জোড়া কোনও কাকতালীয় ঘটনা। পার্থক্যটাই গোটা তদন্ত। বস্তু ভুল করলে পরের প্রতিটি মাপ নষ্ট।

সমস্যার অংশ যদি DHCP রিজার্ভেশন হয়, তবে বরাদ্দকারী আসলে কোন ক্লায়েন্ট পরিচয় পেয়েছে তা টুকে রাখুন। ডেস্কটপের তালিকা, ব্রিজের পরিচয় আর পুরনো লিজের এন্ট্রি তিনটি আলাদা রেকর্ড, আর রাউটার যা দেখেছে তা এদের একটিই।

TUN, TAP আর আপলিংক আলাদা বস্তু

কার্নেল দুই ভার্চুয়াল ধরনের মধ্যে কঠোর সীমা টানে। TUN IP প্যাকেট বহন করে এবং এর কোনও Ethernet পরিচয় নেই। TAP Ethernet ফ্রেম বহন করে, তাই এর পরিচয় আছে।

এর অর্থ TAP-পাশের ঠিকানা ফিজিক্যাল আপলিংকের ঠিকানা নয়, আর রাউট করা TUN ঠিকানা Wi-Fi MAC-এর বিকল্প নয়। এগুলো একই মেশিনের আলাদা স্তর।

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

সত্যিকারের পরিবর্তনের মালিক আসলে কে

একই ফিজিক্যাল ইন্টারফেস সত্যিই ঠিকানা বদলালে কারণ নির্ধারণের আগে সক্রিয় সংযোগ প্রোফাইল দেখুন। গোপনীয়তার সেটিং, ক্লোনিং সেটিং এবং পুনরায় তৈরি ভার্চুয়াল ডিভাইস — সবই VPN ছাড়াই সেই লক্ষণ তৈরি করে।

সময়ে নৈকট্য কারণ নয়। টানেল শুরু হওয়া আর প্রোফাইল আবার প্রয়োগ হওয়া প্রায়ই একই সেকেন্ডে ঘটে, কারণ একটি অন্যটিকে চালু করেছে, আর ঠিকানা পরিবর্তন প্রোফাইলেরই। টানেল লগ পড়ার আগে প্রোফাইল পড়ুন।

পুনরায় তৈরি ইন্টারফেসকে বিদ্যমান ডিভাইস থেকেও আলাদা করুন। স্থায়ী কনফিগারেশন আর রানটাইম ইন্টারফেস সম্পর্কিত বস্তু, আর কোনওটিই স্থায়ী হার্ডওয়্যার পরিচয় নয়।

ম্যানেজারের ক্লোনিং মানগুলোর অর্থ কী

NetworkManager-এর Ethernet সেটিংসের রেফারেন্স স্পষ্টভাবে নির্ধারিত ঠিকানাকে preserve, permanent, random ও stable-এর মতো বিশেষ মান থেকে আলাদা করে, কমান্ড লাইন আর D-Bus ইন্টারফেসে বানান আলাদা।

ওই মানগুলো একটি ম্যানেজারের সমর্থিত ক্ষমতা। এগুলো প্রমাণ নয় যে এই ইমেজ ওই ম্যানেজার চালায়, যে এই প্রোফাইল র্যান্ডমাইজেশন ব্যবহার করেছে, বা যে কোনও VPN প্রসেস NIC পুনর্লিখন করেছে। এই হোস্টের সক্রিয় কনফিগারেশনই তার উত্তর দেয়।

সেটিংটি চালু করতে দ্বিতীয় ম্যানেজার ইনস্টল না করে সেটিংয়ের মালিককে যাচাই করুন। একটি ইন্টারফেস নিয়ে দুই ম্যানেজারের লড়াই ঠিক সেই অস্থিরতাই তৈরি করে যা পরে মানুষ টানেলের ঘাড়ে চাপায়।

প্রদর্শন নয়, পরিচয়ের শর্ত ঠিক করুন

যেখানে স্থানীয় রিজার্ভেশন দরকার, বরাদ্দকারীর নিজস্ব ক্লায়েন্ট-পরিচয় ব্যবস্থা অনুসরণ করুন এবং ইন্টারফেস যেভাবে কনফিগার করা তা তার সঙ্গে মিলিয়ে নিন। তালিকা স্থিতিশীল দেখাতে অসম্পর্কিত ব্রিজ বা টানেল ঠিকানা পিন করা কিছুই সমাধান করে না। এটি এমন দ্বিতীয় পরিচয়ও তৈরি করে যা কেউ নথিভুক্ত করেনি।

দূরবর্তী রাউটেড VPN নিজের পিয়ার প্রমাণ করে এবং নিজের মডেলে ঠিকানা বরাদ্দ করে। একটি LAN ঠিকানা জমা রাখা সেই পিয়ারকে নথিভুক্ত করে না এবং স্থির টানেল বরাদ্দ তৈরি করে না।

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

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