নেস্টেড VPN: বাইরের সংযোগ কোন সুড়ঙ্গ বহন করে?

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

নেস্টিং তিনটি শর্ত নির্ধারণ করে

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

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

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

প্রথম শর্ত: কোন শেষ বিন্দুর কোন পথ দরকার

ip route get 203.0.113.10 সেই প্রশ্নের সরাসরি উত্তর দেয়: এটি রুট, উৎস ঠিকানা এবং কার্নেল এখন ওই গন্তব্যের জন্য যে ইন্টারফেস ব্যবহার করবে তা ছাপে।

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

দ্বিতীয় শর্ত: প্রতিটি স্তরে পথ পরীক্ষা করুন

আধুনিক ক্লায়েন্টে রুট নির্বাচন মূল টেবিলের চেয়ে বেশি কিছু। নীতি নিয়ম চিহ্নিত প্যাকেট অন্য টেবিলে পাঠাতে পারে, ক্লায়েন্ট তার সকেট কোন ইন্টারফেসে বাঁধতে পারে, এবং কনটেইনার বা নেমস্পেসের নিজের টেবিল থাকে। ip rule এবং ip route show table all এই ব্যবস্থাগুলোর মধ্যে কোনটি চালু আছে তা জানার উপায়।

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

তৃতীয় শর্ত: বাইরের সুড়ঙ্গ পড়ে গেলে কী হয়

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

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

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

শৃঙ্খল আপনাকে যা দেয় না

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

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