macOS-এ VPN রুট যাচাই: কিছু না বদলে route get
ডিফল্ট রুটের স্ক্রিনশট আরও নির্দিষ্ট পথ মিস করতে পারে। ব্যর্থ গন্তব্যটি route get দিয়ে জিজ্ঞাসা করুন, ইন্টারফেস ও গেটওয়ে পড়ুন, আর কিছুই বদলাবেন না।
একজন ব্যবহারকারী অফিস নেটওয়ার্কে ইন্ট্রানেটে পৌঁছান, টানেলের মধ্য দিয়ে নয়, অথচ সেটিংস তখনও দেখায় VPN সংযুক্ত। ওই মুহূর্তে রুট টেবিল সম্পাদনা করলে রোগনির্ণয়ে ব্যবহৃত আপনার রিমোট সেশনটি কেটে যাওয়ার ঝুঁকি থাকে। বরং কার্নেলকে জিজ্ঞাসা করুন ব্যর্থ হোস্টের জন্য সে কোন পথ বেছে নেবে। macOS-এর route ইউটিলিটিতে একটি get অপারেশন আছে যা ঠিক সেই উত্তর দেয়, একটি গন্তব্যের জন্য, কিছু না বদলে।
ব্যর্থ হোস্টকে জিজ্ঞাসা করুন, ডিফল্টকে নয়
আধুনিক Mac-এ ডিফল্ট রুটের স্ক্রিনশট খুব কমই বলে, কারণ আরও নির্দিষ্ট গন্তব্য বা সীমিত নীতি ডিফল্ট যা বলে মনে হয় তা ছাড়িয়ে যেতে পারে। টানেল চালু থাকতে পারে, ডিফল্ট সঠিক দেখাতে পারে, তবু আপনার প্রয়োজনীয় একমাত্র হোস্ট অন্যত্র রুট হতে পারে। ব্যর্থ ঠিকানাটি জিজ্ঞাসা করুন এবং কার্নেল তার বেছে নেওয়া পথের নাম বলবে।
রূপটি হলো route -n get তারপর ঠিকানা: route -n get 203.0.113.10, যেখানে ডকুমেন্টেশনের ঠিকানাটি আপনার লক্ষ্যের প্রতিনিধিত্ব করে। অনুমোদিত গন্তব্য ও মিলে যাওয়া ঠিকানা-পরিবার ব্যবহার করুন, কারণ IPv4 উত্তর IPv6-কেবল সম্পদের বিষয়ে কিছুই বলে না। route ইউটিলিটির ডকুমেন্টেশন get অপারেশন ও এটি যে ক্ষেত্রগুলি ছাপে তা বর্ণনা করে।
ইন্টারফেস ও গেটওয়ে প্রমাণ হিসেবে পড়ুন
VPN সংযোগের আগে কোয়েরিটি চালান, তারপর আবার পরে, এবং ইন্টারফেস ও গেটওয়ে লাইন দুটি তুলনা করুন। এই দুটি উত্তরের মধ্যে পার্থক্যই টানেল আসলে যা বদলেছে, এবং তা পুরো টেবিল ডাম্পের চেয়ে অনেক বেশি কাজে লাগে। যদি দুই বারেই ইন্টারফেস একই থাকে, তবে রুট কখনও সমস্যা ছিল না এবং আপনি রাউটিং দেখা বন্ধ করতে পারেন।
সিদ্ধান্তে পৌঁছানোর আগে গন্তব্য, ইন্টারফেস, গেটওয়ে ও কোয়েরির সময় লিখে রাখুন। আউটপুট প্রমাণ, রোগনির্ণয় নয়: স্প্লিট টানেল জড়িত থাকলে একই ইন্টারফেস একটি হোস্টের জন্য সঠিক ও আরেকটির জন্য ভুল হতে পারে।
সঠিক রুট মানে কার্যকর অনুরোধ নয়
রুট বলে দেয় কার্নেল কোন ইন্টারফেস ব্যবহার করবে, তার বেশি কিছু নয়। DNS, হোস্ট ফায়ারওয়াল ও অ্যাপ্লিকেশন অনুমোদন সবই সেই সিদ্ধান্তের উপরে থাকে, এবং রাউটিং সফল হওয়ার পরেও অনুরোধ ব্যর্থ হতে পারে। এগিয়ে যাওয়ার আগে সঠিক লক্ষণটি সংরক্ষণ করুন, কারণ "সংযোগ করা যায় না" আর "সংযোগ হয় কিন্তু ত্রুটি ফেরায়" ভিন্ন তদন্ত ও ভিন্ন পরবর্তী পদক্ষেপ। রিজলভার দৃশ্য ও ইন্টারফেস দৃশ্য গন্তব্য-কোয়েরিকে প্রতিস্থাপন নয়, পরিপূরক করে।
রাউটিং-টেবিল তালিকার এখনও জায়গা আছে: এভাবেই আপনি অপ্রত্যাশিত ডিফল্ট লক্ষ্য করেন। একটি অবশিষ্ট সাধারণ ডিফল্ট প্রমাণ করে না VPN অব্যবহৃত, কারণ বেশি নির্দিষ্ট এন্ট্রি তার উপরে জেতে।
এন্ডপয়েন্ট ও সম্পদ আলাদা রাখুন
দুটি অনুসন্ধান জড়িত এবং তারা ভিন্ন প্রশ্নের উত্তর দেয়। এন্ডপয়েন্টে পৌঁছানো ভৌত নেটওয়ার্ক জুড়ে একটি বাইরের যাত্রা। অ্যাপ্লিকেশনে পৌঁছানো ঘটে টানেলের ভিতরে, এমন ঠিকানায় যা কেবল প্রাইভেট দিকে বিদ্যমান। দুটিকে গুলিয়ে ফেললে চিরাচরিত মিথ্যা লুপ তৈরি হয়, যেখানে এন্ডপয়েন্ট মনে হয় যে টানেলের মধ্য দিয়ে যায় যা সে সমাপ্ত করে। দুটি ঠিকানা আলাদাভাবে জিজ্ঞাসা করুন, প্রতিটি ফলাফল লেবেল করুন, আর বিভ্রান্তি মিলিয়ে যাবে।
প্রিফিক্স ওভারল্যাপ জানার মতো অন্য ঘটনা। যখন লোকাল ও রিমোট রেঞ্জ ওভারল্যাপ করে, দীর্ঘতম-প্রিফিক্স মিল সিদ্ধান্ত নেয়, তাই একটি ওভারল্যাপিং লোকাল সাবনেট আপনার প্রত্যাশিত রিমোট ঠিকানাকে ছায়া করতে পারে। তখন প্রাইভেট গন্তব্যটি লোকাল গন্তব্যের মতোই দেখায়, এবং সমাধান রুট টেবিলে নয়, ঠিকানা পরিকল্পনায়। get কোয়েরি দেখায় কোন ইন্টারফেস জিতেছে, আর কিছু বদলানোর আগে এই তথ্যটিই আপনার দরকার।
আগে পড়ুন, পরে বদলান
প্রথম ধাপের বাইরে রাখুন route add ও route delete। যে Mac আপনি দূর থেকে পরিচালনা করেন, সেখানে একটি অসতর্ক টেবিল সম্পাদনা মেশিনে ফেরার পথটাই কেড়ে নিতে পারে, ফলে রোগনির্ণয় শেষ করার মতো কেউ থাকবে না। সঠিক রুট কী তা ঠিক করুন, পরিবর্তন কীভাবে ফেরাবেন তা লিখে রাখুন, তারপরই তা চালান। পরিদর্শনের এমন লেজ নেই।
প্রথম পদক্ষেপ হিসেবে ক্যাশ ফ্লাশ করা ও নেটওয়ার্ক সেবা পুনরায় চালু করার ক্ষেত্রেও একই সতর্কতা প্রযোজ্য, কারণ দুটোই আপনি যে প্রমাণ পড়তে যাচ্ছিলেন তা নষ্ট করে। কেবল-পঠন যাচাই সস্তা, পুনরাবৃত্তিযোগ্য এবং যেকোনো ক্রমে নিরাপদ। এগুলোকেই ডিফল্ট ধাপ করুন, আর প্রমাণ নির্দেশ করলেই কেবল পরিবর্তনের দিকে হাত বাড়ান।