কেন একটি VPN সংযুক্ত দেখাতে পারে অথচ কিছুই কাজ করে না

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

সংযুক্ত নামে তিনটি ভিন্ন জিনিস

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

তাই সবুজ আইকন আর মৃত টানেল পরস্পরবিরোধী নয়, বরং সামঞ্জস্যপূর্ণ; তারা ভিন্ন বস্তু সম্পর্কে জানায়। এই ব্যর্থতাটিকে বারবার ক্লায়েন্টের বাগ হিসেবে ভুল নির্ণয় করার পুরো কারণ এটিই।

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

কোন কাউন্টার প্রমাণ করে প্যাকেটগুলো সরেছে

IPsec-এ IKE অ্যাসোসিয়েশন ও CHILD অ্যাসোসিয়েশন আলাদা বস্তু, এবং কেবল child-ই সেই কাউন্টার বহন করে যা এই প্রশ্নের উত্তর দেয়। child তালিকাভুক্ত করুন, দেখুন দুই দিকেই প্যাকেট বাড়ছে কি না, এবং তা অ্যাপ্লিকেশন যা করতে চাইছে তার সঙ্গে মিলিয়ে দেখুন। শূন্যে বসানো অ্যাসোসিয়েশন আর অ্যাপ্লিকেশন ব্যর্থ হওয়া সত্ত্বেও বাড়তে থাকা অ্যাসোসিয়েশন ভিন্ন সিদ্ধান্ত; প্রথমটির অর্থ ট্র্যাফিক নির্বাচিত হচ্ছে না, দ্বিতীয়টির অর্থ তা সরছে এবং ত্রুটি আরও দূরে। কাউন্টার দুবার পড়ুন, কয়েক সেকেন্ড ব্যবধানে, কারণ একটি নমুনা প্রবণতা দেখাতে পারে না।

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

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

কাউন্টার সরার পর ত্রুটি কোথায় বসে

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

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

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

ট্রিগার লিখে রাখুন, তারপর একটি জিনিস বদলান

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

তারপর একটি সমর্থিত সংশোধন করুন এবং মূল অনুরোধটি ব্যর্থতা ঘটানো ট্রিগারের সঙ্গে পুনরাবৃত্তি করুন। নিষ্ক্রিয়তা পুনরুৎপাদন করা সবচেয়ে সহজ ট্রিগার, তাই এটি সবচেয়ে দ্রুত নিশ্চিত করে যে সংশোধনটি উপসর্গ নয়, প্রক্রিয়াটিকেই সম্বোধন করেছে।

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