হোস্টনেম অ্যাক্সেস নিয়ম প্রতিটি নেটওয়ার্ক স্তরে কী বোঝাতে পারে
একটি সেবার নাম DNS, ব্রাউজার, প্রক্সি বা ফায়ারওয়াল স্তরে প্রয়োগ করা যায়। যে স্তরটি আপনি নিয়ন্ত্রণ করতে চান সেই পরিচয়টি দেখে, সেটি বেছে নিন।
তিনজন মানুষ একই কথায় একই জিনিস চান: একটি সেবার নামে প্রবেশ বন্ধ করা। একজন বোঝাতে চান ব্রাউজার যেন সাইটটি না খোলে, আরেকজন বোঝাতে চান ডেস্কটপ ভয়েস ক্লায়েন্ট যেন তার সার্ভারে না পৌঁছায়, আর তৃতীয়জন বোঝাতে চান একদল ঠিকাদার যেন একটি নির্দিষ্ট অভ্যন্তরীণ অ্যাপ্লিকেশন ব্যবহার না করে। বাক্যটি একই, আর প্রয়োগের কৌশলগুলোর মধ্যে প্রায় কিছুই মিল নেই।
স্তরটি বেছে নিন তার প্রকৃতপক্ষে যে শনাক্তকারী দেখতে পায় তা দিয়ে, তারপর যে ক্লায়েন্টদের এটি কভার করে তা দিয়ে। আপনি ইতিমধ্যে জানা একটি ফায়ারওয়াল কমান্ড থেকে শুরু করাই সেই পথ যেখানে নিয়মগুলো শেষে কিছুই ব্লক করে না, বা বেশি ব্লক করে।
একটি নাম এমন পরিচয় নয় যা প্রতিটি স্তর যাচাই করতে পারে
Netfilter এবং অনুরূপ প্যাকেট ফিল্টার ঠিকানা, প্রোটোকল ও পোর্ট দেখে। তারা হোস্টনেম দেখে না, এবং প্যাকেট তাদের কাছে পৌঁছানোর সময় নামটি ইতিমধ্যে রিজলভ হয়ে যায়। ঠিকানার বিরুদ্ধে লেখা নিয়ম সেই ঠিকানা সম্পর্কে একটি নিয়ম, ব্যবহারকারী সেখানে পৌঁছাতে যে নামই টাইপ করুক।
DNS নীতি পথের আগে বসে এবং কোয়েরিটি দেখে, যা পরবর্তী সংযোগ থেকে ভিন্ন একটি বস্তু। এটি নিয়ন্ত্রিত রিজলভার যে উত্তর দেয় তা নিয়ন্ত্রণ করে, আগে থেকে খোলা সংযোগ নয়, এবং সেই রিজলভার এড়াতে কনফিগার করা ক্লায়েন্টও নয়। রিজলভ হওয়া ঠিকানা নীতির পর্যালোচনা ও পরবর্তী অনুরোধের মধ্যে বদলাতেও পারে, তাই DNS উত্তর কোনো স্থায়ী অনুমোদন বিবৃতি নয়।
উচ্চতর স্তরগুলো বেশি প্রসঙ্গ দেখে এবং কম ক্লায়েন্ট কভার করে। এই বিনিময়ই পুরো বিষয়, এবং এটি ব্যাখ্যা করে কেন টেবিলের কোনো একটি সারি কখনোই সঠিক উত্তর নয়। যে সারিটি আপনার নীতি আসলে যে শনাক্তকারী নিয়ে তা দেখে, সেটি বেছে নিন। তারপর সেই সারি যে কভারেজ বোঝায় তা মেনে নিন।
প্রতিটি স্তর কী শনাক্ত করতে পারে
টেবিলটি মাঝের কলাম থেকে বাইরের দিকে পড়ুন: একটি স্তর যে শনাক্তকারী দেখতে পায় তা ঠিক করে দেয় সে সততার সঙ্গে কোন নীতি প্রয়োগ করতে পারে।
| Layer | Identifier it sees | What it cannot see |
|---|---|---|
| Packet filter | address, protocol, port | the name, or which other services share that address |
| DNS policy | the queried name and the answer handed back | connections made by clients that ignore the resolver |
| Managed browser | supported URL patterns on managed profiles | non-browser clients, or unmanaged devices |
| CONNECT proxy | host and port for tunnelled requests | the path inside an encrypted request |
একটি স্তর নীতিতে পড়ে কেবল তখনই যখন সে যে শনাক্তকারী দেখে তা আপনার নিয়ন্ত্রণাধীন শনাক্তকারীর সঙ্গে মেলে। টেবিলটি এটিও ব্যাখ্যা করে কেন এক স্তরে লেখা নিয়ম খুব কমই অন্য স্তরে স্থানান্তরিত হয়, আবার না ঠিক করে যে এটি কী রক্ষা করে।
যেখানে স্পষ্ট নিয়মটি ব্যর্থ হয়
একটি ঠিকানার নিয়ম ঠিকভাবে সঠিক এমন সেবার জন্য যার নিজস্ব নিয়ন্ত্রিত ঠিকানা আছে, এবং সেই মালিকানা নীতিতে লেখা উচিত। এটি ঠিকভাবে ভুল এমন সব কিছুর জন্য যা একটি শেয়ার করা কনটেন্ট ডেলিভারি ঠিকানার পিছনে, যেখানে একই নিয়ম সম্পর্কহীন সেবাগুলোকে স্পর্শ করে এবং নবায়ন করা DNS উত্তর নিয়মটিকে হোস্টনেম অনুমোদনে পরিণত করে না।
একটি ব্যবস্থাপিত ব্রাউজার নীতি কপি করা ঠিকানার তালিকার চেয়ে ওয়েব নিষেধাজ্ঞা আরও সরাসরি প্রকাশ করে, তবে এটি ব্যবস্থাপনা ব্যবস্থা যে ব্রাউজার ও প্রোফাইল নিয়ন্ত্রণ করে সেগুলোতে প্রযোজ্য।
সেই ব্রাউজার নিয়ম ভিন্ন হোস্টে UDP পাঠানো ভয়েস ক্লায়েন্টের বিষয়ে কিছুই করে না, আর এর প্যাটার্নগুলো নির্ধারিত হয় সেই পণ্য দ্বারা, অন্য কোথাও ধার করা ওয়াইল্ডকার্ড রীতিতে নয়। CONNECT প্রক্সিও টানেল করা অনুরোধের জন্য হোস্ট ও পোর্ট পায়, এবং এনক্রিপ্ট করা সেশনের ভেতরের পথ পড়তে পারে না। নিয়মটি প্রোটোকল যা প্রকাশ করে তার চারপাশে নকশা করুন। তারপর লিখে রাখুন এটি কী অকভার রেখে দেয়, কারণ সেই ফাঁকই পরবর্তী অনুরোধের উৎস হবে।
কমান্ড দিয়ে নয়, ক্লায়েন্ট দিয়ে বেছে নিন
জিজ্ঞাসা করুন নীতিকে কোন ক্লায়েন্ট কভার করতে হবে এবং কোনগুলো বাদ পড়তে পারে। একটি ব্যবস্থাপিত ব্রাউজার নীতি যা ব্যবস্থাপনা ব্যবস্থা পৌঁছায় তা কভার করে এবং ব্রাউজারের সীমানায় থেমে যায়। রিজলভার নীতি আপনার রিজলভার ব্যবহার করা সবকিছু কভার করে, যা আরও বড় একটি সেট, এবং যারা ব্যবহার করে না তাদের জন্য এটি খোলা অবস্থায় ব্যর্থ হয়।
আপনি যে সেবা পরিচালনা করেন তার জন্য অ্যাপ্লিকেশনে অনুমোদন যেকোনো নেটওয়ার্ক সীমানার চেয়ে শক্তিশালী, কারণ এটি পথ নয়, অ্যাকাউন্ট অনুসরণ করে। একটি VPN রুট কেবল পৌঁছানোর সামর্থ্য, আর কিছু নয়: কোনো সেবায় প্যাকেট পাঠাতে পারা তার ব্যবহারের অনুমতি নয়। যেখানে গুরুত্বপূর্ণ শনাক্তকারী একজন ব্যবহারকারী বা একটি চ্যানেল অনুমতি, সেখানেই তা প্রয়োগ করুন এবং নেটওয়ার্ক নিয়মকে দ্বিতীয় স্তর হিসেবে দেখুন।
নিয়মটি সম্পদের পরিপ্রেক্ষিতে লিখুন
একটি যুক্তিযুক্ত নীতি সম্পদ, পরিচয়গুলো, আওতাভুক্ত অ্যাপ্লিকেশন এবং সেগুলো বহনকারী পথের নাম দেয়, ব্যবহারে থাকা উভয় ঠিকানা পরিবারসহ। এটি এটাও বলে যে নিয়মটি আনুষঙ্গিকভাবে যে শেয়ার করা অবকাঠামোকে প্রভাবিত করবে তার কী হবে।
এই ভাষ্যই এমন একটি সিদ্ধান্ত তৈরি করে যা কেউ পরে নিরীক্ষা করতে পারে। আজকের রিজলভ হওয়া ঠিকানা দিয়ে ন্যায্যতা দেওয়া নিয়ম ঠিকানাটি প্রথমবার বদলালেই একটি ঘটনা তৈরি করে, এবং কেন ব্লকটি কখনো সঠিক ছিল তা কেউ ব্যাখ্যা করতে পারবে না।