ডোমেইন-ভিত্তিক VPN রাউটিং বনাম IP রুট: কোনটি উপযুক্ত?
স্প্লিট-টানেল বক্সে হোস্টনেম কোনো রুট নয়। রিফ্রেশ, সাবডোমেইন পরিধি এবং DNS বদলালে কী হয় তা নিয়ে ডোমেইন নিয়ম ও স্পষ্ট প্রিফিক্স তুলনা করুন।
একটি IP রুট একটি অ্যাড্রেস প্রিফিক্সের সঙ্গে মেলে, এবং কার্নেল আর কোনো প্রশ্ন না করেই তা প্রয়োগ করে। ডোমেইন-ভিত্তিক VPN নিয়ম একটি নামের সঙ্গে মেলে, যার অর্থ স্ট্যাকের ভেতরে কিছু একটা ঠিক করতে হবে যে নামটি এই মুহূর্তে কোন অ্যাড্রেস বোঝায় এবং সেই সিদ্ধান্ত হালনাগাদ রাখতে হবে। এগুলো ভিন্ন ভিন্ন ব্যর্থতার ধরনযুক্ত ভিন্ন প্রক্রিয়া, আর বিক্রেতারা দুটির জন্যই একই শব্দ ব্যবহার করেন। ফিচার তালিকায় এদের তুলনা করলে মূল বিষয়টাই মিস হয়; উত্তর বদলালে কী হয় তা দিয়ে এদের তুলনা করুন।
উপকারী বিভাজনটি হলো এমন নিয়মের মধ্যে যা রিজলভ করে আর এমন নিয়মের মধ্যে যা করে না।
প্রতিটি নিয়ম আসলে কীসের সঙ্গে মেলে
প্রিফিক্স নিয়ম রাউটিং টেবিলের গন্তব্য অ্যাড্রেসের সঙ্গে মেলে। কিছুই রিজলভ হয় না, কিছুই মেয়াদোত্তীর্ণ হয় না, আর প্রতিটি প্যাকেটের জন্য মিলটি নিখুঁত। ডোমেইন নিয়ম একটি অ্যাপ্লিকেশনের নামের অনুরোধের সঙ্গে মেলে, যাকে RFC 1034 অ্যাড্রেস নয় বরং লেবেলের একটি গাছ হিসেবে সংজ্ঞায়িত করে। কিছু পণ্য নামটি একবার রিজলভ করে ফলাফল অ্যাড্রেসগুলো রুট হিসেবে বসিয়ে দেয়, যা নিয়মটিকে রিফ্রেশ টাইমারযুক্ত একটি IP নিয়মে পরিণত করে।
ডিবাগ করার আগে জেনে নিন আপনার কাছে এদের কোনটি আছে, কারণ প্রতিটি ক্ষেত্রেই ব্যর্থতা সম্পূর্ণ আলাদা দেখায়।
স্ট্যাকের কোথায় থাকে ডোমেইন নিয়ম
পণ্যটি যদি স্থানীয় প্রক্সির মাধ্যমে ডোমেইন নিয়ম বাস্তবায়ন করে, তবে ট্রাফিককে সেই প্রক্সিতে পৌঁছাতেই হবে, আর সিস্টেম প্রক্সি উপেক্ষা করা অ্যাপ্লিকেশনগুলো নিয়মটি সম্পূর্ণ এড়িয়ে যায়। যদি নাম রিজলভ করে রুট যোগ করার মাধ্যমে তা বাস্তবায়ন করে, তবে অ্যাড্রেসগুলো শেষ রিফ্রেশের মতোই তাজা। যদি এটি রিজলভারকে হুক করে, তবে DNS আচরণ রাউটিং নীতির অংশ হয়ে যায়, এবং একটি ফলব্যাক রিজলভার চুপচাপ তা বাতিল করে দিতে পারে।
সেটিংসের লেবেল নয়, বিক্রেতার মডেল পড়ুন। Split Tunnel নামের বক্সযুক্ত দুটি ক্লায়েন্ট তিনটি ভিন্ন কাজ করতে পারে।
কী ভাঙে তা তুলনা করুন
তিনটি জিনিস ভিন্নভাবে ভাঙে। অ্যাড্রেস পরিবর্তন: একটি CDN হোস্টনেম কয়েক মিনিটের মধ্যেই ভিন্ন অ্যাড্রেস সেটে রিজলভ হতে পারে, তাই কপি করা তালিকা দ্রুত পুরোনো হয়ে যায়। সাবডোমেইন পরিধি: example.com-এর জন্য একটি নিয়ম api.example.com কভার করতে পারে বা নাও পারে, আর ডকুমেন্টেশন সাধারণত কোনটি তা স্পষ্ট করে বলে। রিজলিউশন ব্যর্থতা: রিজলভার ব্যর্থ হলে, রিজলভকারী ক্লায়েন্ট ট্রাফিক টানেলিংয়ে ফিরে যেতে পারে, বা সরাসরি পাঠাতে পারে।
শুধু দ্বিতীয়টিই কনফিগারেশনের প্রশ্ন। বাকি দুটি নকশার প্রশ্ন—পণ্যটি কতটা অনুমান করতে রাজি।
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
কখন প্রিফিক্সই উত্তম উত্তর
স্থিতিশীল প্রাইভেট সাবনেটের জন্য স্পষ্ট প্রিফিক্স বেশি স্পষ্ট, দ্রুততর এবং নিরীক্ষা করা সহজ। এটি রিজলভার বিভ্রাটও টিকে যায়, কারণ কিছুই রিজলভ করতে হয় না। ডোমেইন নিয়ম ব্যবহার করুন যখন সেবাটি হোস্টেড, যখন অ্যাড্রেস ঘুরতে থাকে, বা যখন আপনি সত্যিই গন্তব্য সেটটি গণনা করতে পারেন না। শুধু এই কারণে এটি ব্যবহার করবেন না যে হোস্টনেমটিই আপনি দৈবক্রমে জানেন।
অনুমানভিত্তিক স্ট্যাটিক তালিকা দুইয়েরই সবচেয়ে খারাপ: দেখতে রক্ষণাবেক্ষণকৃত লাগে, আর যেদিন প্রদানকারী একটি হোস্ট যোগ করেন সেদিন চুপচাপ ট্রাফিক মিস করে।
একটি নতুন অনুরোধ দিয়ে যাচাই করুন
স্বাভাবিক পুনঃসংযোগের পরে কোল্ড অনুরোধ দিয়ে পরীক্ষা করুন, কারণ ক্যাশ করা পৃষ্ঠা হয়তো নিয়মটি কখনোই স্পর্শ করবে না। নামটি রিজলভ করুন, তারপর দেখুন সংযোগটি আসলে কোথায় গেছে। dig +short app.example.com বর্তমান অ্যাড্রেস সেট দেয়, আর ক্লায়েন্টের সংযোগ তালিকা আপনাকে বলে কোন ইন্টারফেস প্রবাহটি বহন করেছে।
পণ্যটি যে রিফ্রেশ ব্যবধান নথিভুক্ত করে তার পরে পুনরাবৃত্তি করুন। যদি অ্যাড্রেস সেট সরে যায় এবং নিয়মটি অনুসরণ না করে, তবে আপনি আসল আচরণ খুঁজে পেয়েছেন।
রিজলভার নীতি আলাদাও রাখুন। ডোমেইন নিয়মের সঠিক নাম-তথ্য দরকার, কিন্তু কোন রিজলভার প্রশ্নের উত্তর দেবে তা এটি নিজে থেকে নির্ধারণ করে না।