VPN লগইন সতর্কতা: কোন ইভেন্টটি আসলে সেগুলো ট্রিগার করা উচিত?
প্রমাণীকরণের সাফল্য, প্রতিষ্ঠিত টানেল এবং RADIUS accounting Start তিনটি আলাদা দাবি। আপনার প্রাপক যে দাবি নিয়ে কাজ করতে পারেন সেটি বেছে নিন, তারপর সম্পর্ক মেলান।
প্রমাণীকরণের সাফল্য, প্রতিষ্ঠিত একটি টানেল এবং RADIUS accounting Start তিনটি আলাদা দাবি, আর লগইন ইমেইল কেবল তখনই অর্থ বহন করে যখন আপনি এদের একটি বেছে নেন। বেশিরভাগ VPN সতর্কতার নকশা তিনটিকেই মিশিয়ে ফেলে এবং এমন একটি ইনবক্স তৈরি করে যা কেউ বিশ্বাস করে না। সিদ্ধান্তটি নির্ভর করে কে সতর্কতাটি পড়বে এবং পরের পাঁচ মিনিটে সে কী করতে পারবে তার উপর। এটি ভুল করলে সতর্কতাটি কোলাহলে পরিণত হয় যা আপনার প্রয়োজনীয় একমাত্র ইভেন্টটিকে লুকিয়ে রাখে।
তিনটি প্রশ্ন ট্রিগার নির্ধারণ করে
জিজ্ঞাসা করুন কে এটি পাবে, তারা কী করবে এবং কাজটি কত দ্রুত ঘটতে হবে। প্রমাণপত্রের অপব্যবহার লক্ষ্য করা একটি নিরাপত্তা দল কয়েক মিনিটের মধ্যে একটি অ্যাকাউন্ট থেকে ব্যর্থ-তারপর-সফল ধরন চায়। ধারণক্ষমতা লক্ষ্য করা একটি পরিচালন দল সেশনকাল এবং সংযোগ বিচ্ছিন্নের কারণ চায়, লগইন নয়। একটি হেল্পডেস্ক সেশন পরিচয় চায় যাতে এটি একটি টিকিটের সাথে মিলিয়ে দেখতে পারে।
সেই উত্তরগুলো ভিন্ন ভিন্ন ইভেন্টের দিকে ইশারা করে, আর কোনো একক নিয়ম তিনটিকেই সন্তুষ্ট করে না। প্রাপকের কাজ যদি হয় «ব্যবহারকারীকে ফোন করুন», তবে প্রমাণীকরণই যথেষ্ট। কাজ যদি হয় «একটি লাইসেন্স মুক্ত করুন» বা «টানেলটি ট্রাফিক বহন করেছে কি না যাচাই করুন», তবে কেবল প্রতিষ্ঠা বা accounting Start কাজ করবে। কাজ যদি হয় «সময়টির বিল করুন», তবে আপনার লগইনের বদলে Stop রেকর্ড দরকার।
কিছু কনফিগার করার আগে উত্তরটি এক বাক্যে লিখুন। «এই ইমেইলটি অন-কল ইঞ্জিনিয়ারকে জানায় যে অ্যাকাউন্ট X সময় Z-এ নেটওয়ার্ক Y থেকে একটি টানেল খুলেছে, যাতে তিনি যাচাই করতে পারেন রক্ষণাবেক্ষণ উইন্ডোটি ব্যবহৃত হয়েছিল কি না।» যদি আপনি প্রতিটি ঘর পূরণ করতে না পারেন, তবে ট্রিগার এখনও বেছে নেওয়া হয়নি।
আপনি যে দাবি করছেন তার সাথে ইভেন্টটি মেলান
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
সারণিটি একটি নির্ভরতা লুকিয়ে রাখে: প্রতিটি সারি কেবল তখনই বিশ্বাসযোগ্য যখন গেটওয়ে এটি নির্ভরযোগ্যভাবে নির্গত করে এবং আপনার সংগ্রাহক আপনার প্রয়োজনীয় ক্ষেত্রটি রাখে। আপনি যে সঠিক সংস্করণ চালান তার জন্য ইভেন্ট সংজ্ঞাটি পড়ুন, কারণ «সেশন প্রতিষ্ঠিত» নামটি সংস্করণের মধ্যে বদলায় এবং অর্থ নামের চেয়ে বেশি বার বদলায়। সংজ্ঞা অস্পষ্ট হলে লেবেল থেকে অনুমান না করে একটি সেশন ক্যাপচার চান।
Access-Accept-কে তার পরে সমস্ত কিছুর সমাপ্তি হিসেবে ধরা সবচেয়ে সাধারণ ভুল। এটি একটি প্রমাণপত্রের রায়, সেশন নয়। বিপরীত ভুলটি হল একটি নীতি মিলকে অনুমোদনের প্রমাণ হিসেবে পড়া, যখন একটি নিয়ম মিলতে পারে এবং পরের ধাপটি তবুও ব্যর্থ হতে পারে।
এক সেশন, একটি বিজ্ঞপ্তি
এক অ্যাকাউন্ট, একাধিক ডিভাইস, পুনঃপ্রেরণ এবং পুনঃসংযোগ: প্রতি ইভেন্টে একটি ইমেইল দুই দিকেই ভুল হবে, একটি সেশন নকল করবে আর অন্যটিকে ভাগ করবে। বিজ্ঞপ্তির চাবি করুন গেটওয়ে প্লাস একটি সেশন শনাক্তকারীর উপর, এবং অ্যাকাউন্টের নামকে চাবি নয় বরং একটি বৈশিষ্ট্য হিসেবে দেখুন। ল্যাপটপ ও ফোন থাকা একজন ব্যবহারকারী একসাথে দুটি টানেল রাখতে পারেন, এবং দুটিই নিজের লাইনের যোগ্য।
পুনঃপ্রেরিত হিসাবরক্ষণ রেকর্ড স্বাভাবিক, তাই বার্তাটি তৈরি করার আগে সেশন আইডি ও টাইমস্ট্যাম্পে ডুপ্লিকেট সরান। একই ডিভাইস থেকে ধারাবাহিক সেশন আলাদা থাকা উচিত, এবং রক্ষণাবেক্ষণ উইন্ডোর সময় একটি পুনঃসংযোগ আগেরটিতে মিশে যাওয়ার বদলে দৃশ্যমান থাকা উচিত। আপনার সংগ্রাহক গ্রহণের সময় টাইমস্ট্যাম্প পুনর্লিখন করলে, সংরক্ষিত ক্ষেত্রের বদলে মূল রেকর্ডের ক্ষেত্রে ডুপ্লিকেট সরান।
অনুপস্থিত Stop রেকর্ড মানে অনিশ্চয়তা, স্থায়ী সেশন নয়। গেটওয়ে রিবুট, সংগ্রাহক বিভ্রাট এবং UDP ক্ষতি সবই ফাঁক রাখে, তাই সতর্কতার একটি পুনর্মিলন পথ দরকার যা কেউ টানেল এখনও চালু আছে বলে সিদ্ধান্তে আসার আগে লাইভ সেশন টেবিল জিজ্ঞাসা করে।
নিরীক্ষা ও বিজ্ঞপ্তি আলাদা রাখুন
নিরীক্ষা প্রবাহ ও সতর্কতা প্রবাহের কাজ আলাদা। কাঁচা রেকর্ড রাখুন, যার মধ্যে অ্যাকাউন্ট, গেটওয়ে, সেশন আইডি, টাইমস্ট্যাম্প ও সমাপ্তির কারণ রয়েছে, এমনকি যখন রুটিন ইমেইল দলবদ্ধ, দমন বা একটি ছোট অন-কল তালিকায় পাঠানো হয়। তীব্রতার সীমা একটি বিতরণ ফিল্টার, আপনি যে জীবনচক্রের ইভেন্ট ঘোষণা করতে চেয়েছিলেন তার নির্বাচন নয়।
প্রাপকের সুরক্ষিত রেকর্ডটি খুঁজে পেতে প্রয়োজনীয় ন্যূনতম প্রসঙ্গ পাঠান। অ্যাকাউন্টের নাম, অভ্যন্তরীণ ঠিকানা এবং সেশনের বিবরণ সংবেদনশীল, আর যে ইমেইল ভালোভাবে ফরোয়ার্ড হয় সেটিই ভালোভাবে ফাঁস হয়।
তারপর এটি শুরু থেকে শেষ পর্যন্ত প্রমাণ করুন। একটি সাধারণ লগইন ও লগআউট, একটি পুনঃসংযোগ, দুটি একযোগে সেশন এবং একটি জোরপূর্বক বিতরণ ব্যর্থতা চালান, এবং গেটওয়ে থেকে সংগ্রাহক হয়ে বিতরণকৃত বার্তা পর্যন্ত একটি ইভেন্ট ট্রেস করুন। সেশন আইডি ছাড়া ইমেইল এলে চুক্তিটি অসম্পূর্ণ। দুটি ইমেইল যদি এক সেশন বর্ণনা করে, সম্পর্কটি ভাঙা। মেইল বিতরণ কাজ করে—এটুকুই যদি একমাত্র পরীক্ষা হয়, তবে দুটি সমস্যার কোনোটিই ধরা পড়ে না।