সেটআপ স্ক্রিপ্ট চালানোর পরে কেউ VPN সার্ভারের মালিক হতে হবে

দুটি আলাদা কাজ একটির মতো বিক্রি হয়: একটি মেশিনকে VPN সার্ভারে পরিণত করা এবং অন্য কারও গেটওয়েতে যোগ দিতে হবে এমন ল্যাপটপে VPN ক্লায়েন্ট যোগ করা। সেটআপ স্ক্রিপ্ট প্রথমটির উত্তর দেয় এবং দ্বিতীয়টির উত্তর দিতে পারে না, তার README যা-ই বলুক। setup-ipsec-vpn প্রকল্প একটি বাস্তব উদাহরণ হিসেবে নিন: এটি সমর্থিত Linux হোস্টে Libreswan এবং xl2tpd ব্যবহার করে IPsec/L2TP, Cisco IPsec বা IKEv2 সার্ভার তৈরি করে। এটি একটি সার্ভারের জন্য ডিপ্লয়মেন্ট চুক্তি, যেকোনো মেশিনের জন্য সাধারণ রেসিপি নয়। স্ক্রিপ্ট চালানোর আগে আপনার কোন কাজটি তা নির্ধারণ করুন, কারণ এর পরে সবকিছু সার্ভার নিয়ে।

হোস্ট সম্পর্কে সৎ থাকুন

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

পরিষেবা চালু করা তার পথ খুলে দেয় না। IPsec-এর জন্য হোস্টের সামনের নেটওয়ার্ককে UDP 500 এবং 4500 অনুমোদন করতে হবে এবং ডিপ্লয়মেন্টের উপর নির্ভর করে ESP প্রোটোকল নিজেই। যে স্ক্রিপ্ট প্রোটোকল 50 বাদ দেওয়া সিকিউরিটি গ্রুপের পিছনে সফলভাবে শেষ হয়, সেটি এমন সার্ভার তৈরি করেছে যেখানে কেউ পৌঁছাতে পারবে না, এবং ইনস্টলারের আউটপুটে কিছুই তা বলবে না।

ইনস্টলার আসলে কী দায়িত্ব নেয়

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

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

স্ক্রিপ্ট আপনাকে কী দিতে পারে না

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

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

প্রথম ক্লায়েন্টই গ্রহণ পরীক্ষা

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

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

হ্যান্ডঅফ পৃষ্ঠা লিখুন

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

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