VPN ইনভেন্টরি: অভিপ্রেত অ্যাক্সেস, উৎপন্ন কনফিগারেশন, চলমান সেশন

প্রতিটি টানেলের নাম ইনভেন্টরির একটি সারির মতো দেখায়, যতক্ষণ না আপনি জিজ্ঞেস করেন এটি কার। একটি নাম আপনাকে বলে যে এখন কিছু সংযুক্ত আছে; এটি বলতে পারে না সেবাটি কার, তারা কী পর্যন্ত পৌঁছাতে পারে, বা যে কনফিগারেশন টানেলটি তৈরি করেছে সেটি আপনার অনুমোদিতটিই কি না। ফ্লিটের মাপে ওই তিনটি প্রশ্নই ইনভেন্টরি, আর টানেল কেবল সর্বশেষ পর্যবেক্ষণ।

এক সেবা, তিনটি রেকর্ড

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

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

ভাড়াটে লিখুন, ইন্টারফেস নয়

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

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

উৎপন্ন কনফিগারেশনের একটি মালিক ও একটি সংস্করণ থাকে

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

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

সেশন প্রমাণ, অনুমোদন নয়

যেখানে মোতায়েন RADIUS অ্যাকাউন্টিং ব্যবহার করে, সেখানে RFC 2866 কাজ করার জন্য নির্দিষ্ট ফিল্ড দেয়। Acct-Status-Type শুরুকে থামা থেকে আলাদা করে, আর একই সেশনের রেকর্ডগুলো একটি Acct-Session-Id ভাগ করে। এই ফিল্ডগুলো ড্যাশবোর্ডের সারাংশে ভরসা না করে একটি সেশন কখন শুরু ও শেষ হয়েছে তা পুনর্গঠন করতে দেয়।

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

অবসরেও একই সংযোগ ব্যবহার হয়

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

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