ip link দিয়ে লিনাক্স VPN ইন্টারফেস স্তর ধরে ধরে পরীক্ষা করা

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

আইকন পড়ার আগে ইন্টারফেস পড়ুন

শুরু করুন ip -details link show dev tun0 দিয়ে, যেমনটি নথিভুক্ত আছে ip-link ম্যানুয়ালে — প্রথাগত নামের বদলে আপনার ক্লায়েন্টের প্রকৃত ইন্টারফেস বসান। ফ্ল্যাগ, ধরন, MTU ও ইন্টারফেস পরিচয় দরকারি পর্যবেক্ষণ। ভার্চুয়াল ইন্টারফেসের অবস্থার ভাষাকে ফিজিক্যাল কেবলের ক্যারিয়ার সংকেতের মতো আচরণ করতে হয় না, তাই UP-কে টানেল সম্পর্কে নয়, ইন্টারফেস সম্পর্কে বক্তব্য ধরুন।

এই পার্থক্যই সবচেয়ে বিভ্রান্তিকর ঘটনাটি ব্যাখ্যা করে: এমন ইন্টারফেস যা থেকে যায় যখন দূরবর্তী পক্ষ আবার সংযুক্ত হচ্ছে বা পৌঁছানো যাচ্ছে না।

স্থায়িত্বের সেটিংস লিংকটিকে ঠিক এই জন্য রাখতে পারে যাতে পুনঃসংযোগ এটি নতুন করে না বানায়, অর্থাৎ উপস্থিতি মানেই সুস্থতা নয়।

কাউন্টার যোগ করুন এবং এমন অনুরোধ যা সেগুলো ব্যবহার করা উচিত

সমর্থিত পরিসংখ্যান ভিউ ব্যবহার করুন ip -s link show dev tun0, এবং দুই দিকেই প্যাকেট ও বাইট গণনা লক্ষ্য করুন। তারপর এমন একটি নিরীহ অনুরোধ তৈরি করুন যা ইন্টারফেস পার হওয়া উচিত এবং সংশ্লিষ্ট দিকটি তুলনা করুন। যে অনুরোধ অন্য অ্যাপ্লিকেশনের সরাসরি রুট নিয়েছে সেটি এই কাউন্টার নড়াবে না, আর অনুশীলনের উদ্দেশ্যই সেটি।

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

একবার আগে ও একবার পরে, দুই বার পাঠ নিন, একক স্ন্যাপশটে ভরসা করবেন না।

ঠিকানা ও রুট আলাদা ধাপ

প্রিফিক্স, রিজলভার কনফিগারেশন বা অ্যাপ্লিকেশনের প্রয়োজনীয় রুট ছাড়াও লিংক থাকতে পারে। ঠিকানাটি দেখুন ip address show dev tun0, তারপর দেখুন গন্তব্য কোন রুট বেছে নেবে ip route get দিয়ে প্রকৃত লক্ষ্যের জন্য। এই তিনটি পর্যবেক্ষণ তিনটি আলাদা প্রশ্নের উত্তর দেয়, আর কেবল শেষটি ফরওয়ার্ডিং নিয়ে।

IPsec-এর ক্ষেত্রে নিরাপত্তা নীতি ও অ্যাসোসিয়েশন অবস্থাও গুরুত্বপূর্ণ হতে পারে, আর প্রতিটি IPsec নকশা সরল tun ইন্টারফেস হিসেবে দেখা যায় না। এমন tun ডিভাইস খোঁজা যা কখনো থাকার কথা ছিল না, ভুল সিদ্ধান্তে পৌঁছানোর দ্রুত পথ।

যে কোনো আউটপুট রাখলে তার সঙ্গে সঠিক নাম, নেমস্পেস ও সময় লিখে রাখুন, কারণ অন্য কন্টেইনারে বা পুনরুদ্ধার করা সেশনে একই দেখতে নাম সম্পূর্ণ ভিন্ন প্রসঙ্গ বোঝায়।

যা চিহ্নিত করেননি তা মুছবেন না

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

ইন্টারফেসটি যদি কন্টেইনার রানটাইম বা আপনার তৈরি না করা নেটওয়ার্ক নেমস্পেসের হয়, মালিক এক কমান্ড দূরত্বে এবং আগে খুঁজে নেওয়া মূল্যবান।

এই সতর্কতা ip link set down-এর ক্ষেত্রেও প্রযোজ্য, যা বিপরীতমুখী দেখায় এবং প্রায়ই তা নয়।

পরীক্ষা আপনাকে কী রেখে যাওয়া উচিত

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

এই চার তথ্য একটি চালু সেশনের একই চার তথ্যের সঙ্গে তুলনা করুন। নাম ও নেমস্পেস মিললেও কাউন্টার ডেল্টা শূন্য হলে অনুরোধ কখনো টানেলে পৌঁছায়নি। ডেল্টা সুস্থ আর রুট অন্য দিকে ইশারা করলে টানেল ঠিক আছে, রাউটিং নয়। এই তুলনাই আউটপুটের স্তূপকে সিদ্ধান্তে বদলায়।

টিকিটের সঙ্গে আউটপুট রাখুন, কারণ পরে তুলনা কেবল তখনই কাজে লাগে যখন দেখা যায় কী বদলেছে।

তারপর অ্যাপ্লিকেশন আবার পরীক্ষা করে চক্রটি বন্ধ করুন, কারণ ইন্টারফেস কখনোই ব্যবহারকারীর আসল চিন্তার বিষয় ছিল না।