ifconfig-noexec আপনার SSH সেশন বাঁচাবে না: এটি কী করে
এটি OpenVPN-এর নিজস্ব ইন্টারফেস ঠিকানার সেটআপ বন্ধ করে। এটি কোনো SSH উত্তর-রুট সংরক্ষণ করে না, সব রুট পরিবর্তন নিষ্ক্রিয় করে না, এবং অনুপস্থিত ঠিকানাটি সরবরাহ করে না।
কোনো ফোরাম থ্রেডে, ifconfig-noexec কে এমন সমাধান হিসেবে প্রস্তাব করা হয় যা টানেল উঠলে একটি SSH সেশন জীবিত রাখে। যুক্তিটি বিশ্বাসযোগ্য মনে হয় যতক্ষণ না আপনি দেখেন অপশনটি কোথায় হাত দেয়। এটি OpenVPN-কে টানেল ইন্টারফেসের ঠিকানা কনফিগার করা থেকে বিরত রাখে এবং সেই মানগুলো পরিবর্তে স্ক্রিপ্টে দিয়ে দেয়; আপনার ম্যানেজমেন্ট সংযোগের উত্তর কোথায় যায় সে বিষয়ে এটি কিছুই বলে না। অন্যথায় বিশ্বাস করলে আপনি ব্যবহারযোগ্য ঠিকানাহীন একটি টানেল এবং এখনও মারা যাওয়া একটি SSH সেশন পান।
অপশনটি আসলে কী ডেলিগেট করে
ডিফল্টভাবে, ক্লায়েন্ট টানেল ডিভাইসটি তোলে এবং সার্ভার যে লোকাল ও রিমোট ঠিকানা দিয়েছে তা নির্ধারণ করে। ifconfig-noexec সেট থাকলে সেই ধাপটি এড়িয়ে যাওয়া হয় এবং আলোচিত মানগুলো স্ক্রিপ্ট এনভায়রনমেন্টে রপ্তানি হয় যাতে অন্য কিছু সেগুলো প্রয়োগ করতে পারে।
মালিকানা সরে যায়। তার জায়গায় কিছু উদ্ভাবন করা হয় না।
তাই অপশনটি যে প্রশ্নের উত্তর দেয় তা হলো কে ইন্টারফেস কনফিগার করে, আর যে প্রশ্নের উত্তর এটি দেয় না তা হলো প্যাকেটগুলো কীভাবে আপনার কাছে ফিরে আসে। এগুলো আলাদা রাখুন, নইলে ঠিকানাহীন ইন্টারফেসের ক্ষতিপূরণে রুট সম্পাদনা করে একটি সন্ধ্যা কাটাবেন।
ভিন্ন কাজের তিনটি অনুরূপ অপশন
পরিবারটিকে গুলিয়ে ফেলা সহজ, কারণ নামগুলো এক শব্দে আলাদা এবং উপসর্গগুলো ওভারল্যাপ করে। যেকোনো একটি বেছে নেওয়ার আগে প্রতিটি কী বন্ধ করে তা পড়ুন।
| অপশন | কী ঘটানো বন্ধ হয় |
|---|---|
ifconfig-noexec | OpenVPN-এর নিজস্ব টানেল-ঠিকানা কনফিগারেশন; মানগুলো পরিবর্তে স্ক্রিপ্টে যায় |
route-noexec | স্বয়ংক্রিয়ভাবে রুট যোগ ও অপসারণ; রুটের বিবরণ একটি স্ক্রিপ্টে যায় |
route-nopull | সার্ভার-পুশ করা রুট এবং DNS-এর মতো সংশ্লিষ্ট অপশন প্রত্যাখ্যাত হয় |
এগুলো আলাদাভাবে বুঝতে হবে এমন বিকল্প, একসাথে পেস্ট করার সেট নয়। ঠিকানা কনফিগারেশন বন্ধ করলে রুট পরিবর্তন, ফায়ারওয়াল নিয়ম বা DNS বহনকারী পুশ করা অপশন বন্ধ হয় না। ডেলিগেট করা স্ক্রিপ্টও রুট পরিবর্তন করতে স্বাধীন, এবং এটি এমন সিদ্ধান্ত যা আপনি এড়ানোর বদলে হস্তান্তর করেন।
যদি কোনো ভেন্ডর ক্লায়েন্ট ইঞ্জিনটিকে মোড়ক করে, তবে প্রোফাইলে একটি নিম্ন-স্তরের নির্দেশ ফেলে মোড়কটি তা মানবে বলে আশা করার বদলে তার সমর্থিত ইন্টিগ্রেশন ব্যবহার করুন। মোড়কগুলো প্রায়ই সংযোগের সময় প্রোফাইল পুনরায় তৈরি করে, তাই হাতে করা সম্পাদনা কোনো ত্রুটি ছাড়াই হারিয়ে যায়। ফাইলে একটি সন্ধ্যা ব্যয় করার আগে ক্লায়েন্ট তার সেটিংস কোথায় রাখে দেখুন। এটি টেবিলের প্রতিটি সারিতে প্রযোজ্য, শুধু যেটির জন্য আপনি এসেছেন সেটিতে নয়।
যে SSH সেশনটি আপনি রক্ষা করতে চেয়েছিলেন
একটি SSH সংযোগের একটি উৎস ঠিকানা, একটি গন্তব্য ঠিকানা এবং একটি উত্তর-পথ থাকে। যে সার্ভার এইমাত্র ফুল-টানেল ডিফল্ট ইনস্টল করেছে, সেখানে আপনার পাবলিক ঠিকানার উত্তর টানেলের সাথে মিলে যায় এবং VPN গেটওয়ে সেটি ফেলে দেয়।
টানেল ইন্টারফেসের ঠিকানা কনফিগারেশনে কিছুই তা বদলায় না।
যা এটি ঠিক করে তা হলো প্রি-টানেল গেটওয়ে দিয়ে আপনার ম্যানেজমেন্ট ঠিকানার জন্য আরও নির্দিষ্ট একটি রুট, বা সেই ট্রাফিককে পরিচালনা করে এমন একটি পলিসি নিয়ম, সাথে আপনার হোস্ট যে ফিল্টার সেটিংস প্রয়োগ করে। দুটি সমস্যা মাঝে মাঝে একসাথে দেখা দেয়, আর এভাবেই একটিকে অন্যটির প্রতিকার ভাবা হয়। এগুলো আলাদাভাবে পরীক্ষা করুন: অপশন ছাড়া টানেল তুলুন, ইন্টারফেস ঠিকানা ও উত্তর-পথ দেখুন, তারপর দুটির মধ্যে কোনটি সত্যিই নষ্ট তা নির্ধারণ করুন।
ডেলিগেট করা স্ক্রিপ্টকে কী দায়িত্ব নিতে হবে
যদি আপনি সত্যিই চান অন্য মালিক ইন্টারফেস কনফিগার করুক, কাজটি গণনা করুন: লোকাল ও রিমোট ঠিকানা প্রয়োগ করুন, ডিভাইসটি তুলুন, টিয়ারডাউনে ঠিকানাকরণ পুনরুদ্ধার বা সরান, এবং পুনরায় সংযোগের পর আবার একই কাজ করুন। একটি সফল সেশনের মান হার্ড-কোড করা যাবে না, কারণ সার্ভার পরের বার ভিন্ন জোড়া দিতে পারে।
ক্লায়েন্ট যে এনভায়রনমেন্ট ভেরিয়েবলগুলো রপ্তানি করে সেগুলোই সেই কাজের একমাত্র সমর্থিত ইনপুট।
env | grep -E '^ifconfig_|^route_'route-up স্ক্রিপ্টের ভেতরে সেই ভেরিয়েবলগুলো পাওয়া যায়; কোনো cron কাজ বা হাতে চালানো shell থেকে পাওয়া যায় না। আপনার সংস্করণ কোন লাইফসাইকল হুক ব্যবহার করে তা নিশ্চিত করুন, এবং হুকটি ইন্টারফেস বদলানোর মতো যথেষ্ট বিশেষাধিকার নিয়ে চলে কিনা তাও নিশ্চিত করুন, কারণ ক্লায়েন্ট হয়তো ইতিমধ্যে একটি অসুবিধাভোগী ব্যবহারকারীতে নেমে গেছে।
সম্পূর্ণ লাইফসাইকল পরীক্ষা করুন, একটি সেশন নয়
টানেল তুলুন, ডিভাইসে ঠিকানা দেখুন, তারপর পুনরায় সংযোগ করুন এবং আবার দেখুন। যে কনফিগারেশন একবার কাজ করে দ্বিতীয় প্রচেষ্টায় ব্যর্থ হয়, সাধারণত এর অর্থ ডেলিগেট করা ধাপটি কেবল প্রথম সংযোগেই চলে।
তারপর দুটি গ্রহণযোগ্যতার মাপকাঠি একসাথে পরীক্ষা করুন: উদ্দিষ্ট ম্যানেজমেন্ট পথ দিয়ে একটি নতুন SSH সংযোগ কাজ করে, এবং অনুমোদিত একটি অ্যাপ্লিকেশন টানেলটি সঠিকভাবে ব্যবহার করে।
টানেলের ঠিকানা না থাকা অবস্থায় টিকে যাওয়া একটি পুরোনো SSH সেশন সফলতা নয়, এবং কেউ কাজটি না নিলে এই অপশনটি ঠিক সেই অবস্থাটিই তৈরি করে। আগে ইন্টারফেস ঠিকানা দেখুন, তারপর ম্যানেজমেন্ট উত্তর-পথ, তারপর অ্যাপ্লিকেশন। তিনটির মধ্যে দুটি ভুল হলে অপশনটি কাজ সরিয়েছে কিন্তু তার মালিক দেয়নি।