CDN ঠিকানা বদলালে VPN ডোমেইন নিয়ম ভেঙে যায়
একটি DNS উত্তর একটি স্ন্যাপশট, ইনভেন্টরি নয়। তিনটি শর্ত ঠিক করে নামভিত্তিক নিয়ম নাকি স্পষ্ট প্রিফিক্স CDN-চালিত সেবার জন্য মানানসই।
একটি লুকআপ থেকে ঠিকানাটি আপনার রাউটিং নিয়মে কপি করেন, সাইটটি কাজ করে, আর এক সপ্তাহ পরে করে না। নিয়মে কিছুই বদলায়নি। সেবাটি অন্য একটি এজ ঠিকানায় সরে গেছে, ক্লায়েন্ট অন্য একটি হোস্টনেম রিজলভ করেছে, অথবা সেশনটি IPv6-এ চলে গেছে। আপনার সামনের সিদ্ধান্ত হলো নামভিত্তিক নিয়ম নাকি স্পষ্ট রেঞ্জ এই সেবার জন্য সঠিক হাতিয়ার, এবং তিনটি শর্তই তা ঠিক করে। এরপরের অংশটি নামকে ঠিকানা থেকে আলাদা করে, কারণ দুটির মধ্যে কেবল একটি স্থিতিশীল।
কেন একটি লুকআপ ইনভেন্টরি নয়
একটি কনটেন্ট-ডেলিভারি নেটওয়ার্ক রিজলভার, অঞ্চল ও মুহূর্তের জন্য বাছাই করা ঠিকানা দিয়ে উত্তর দেয়। ভিন্ন নেটওয়ার্ক থেকে দুবার জিজ্ঞাসা করুন, ভিন্ন উত্তর পেতে পারেন। একবার জিজ্ঞাসা করে উত্তরটিকে সেবার ঠিকানার তালিকা ধরে নিন, তাহলে আপনি যে নিয়ম লেখেন তা নিয়ম নয়, একটি স্ন্যাপশট। DNS উত্তরকে কনফিগারেশন হিসেবে দেখার পুরো সমস্যা এটাই।
দ্বিতীয় একটি ফাঁক আছে। একটি দৃশ্যমান হোস্টনেম খুব কমই পুরো অ্যাপ্লিকেশন ঢাকে, কারণ লগইন, মিডিয়া ও API ট্রাফিক প্রায়ই আলাদা নাম ব্যবহার করে। অ্যাড্রেস বারের হোস্টনেম থেকে গড়া নিয়ম পৃষ্ঠাটি ঢাকতে পারে কিন্তু ভিডিওটি মিস করতে পারে, যা রাউটিং ত্রুটি নয় বরং আংশিক ব্যর্থতা হিসেবে পড়া হয়।
তৃতীয় ফাঁকটি ঠিকানা পরিবার। শুধু v4-এর নিয়ম AAAA রেকর্ড সম্পর্কে কিছুই বলে না, যা ক্লায়েন্ট পছন্দ করতে পারে।
ডোমেইন নিয়ম নাকি রেঞ্জ, তা ঠিক করা তিনটি শর্ত
প্রথমত, সেবাটি কি এমন স্থিতিশীল প্রিফিক্সের সেট প্রকাশ করে যা আপনি মালিকানায় রাখতে ও নথিভুক্ত করতে পারেন? যদি করে, স্পষ্ট রেঞ্জ সৎ ও সস্তা। যদি না করে, ডোমেইন নিয়মই একমাত্র ব্যবস্থা যা সেবাটিকে অনুসরণ করতে পারে।
দ্বিতীয়ত, আপনার ক্লায়েন্টের ডোমেইন ব্যবস্থা কি রিফ্রেশ হয়? যে নিয়ম সংযোগের সময় একবার রিজলভ করে আর কখনো নয়, তা আরও ভালো ব্র্যান্ডিংযুক্ত স্ন্যাপশট। তৃতীয়ত, ব্যবস্থাটি কি সাবডোমেইন ও উভয় ঠিকানা পরিবার ঢাকে, নাকি কেবল আপনি যে নামগুলো টাইপ করেছেন?
এই তিনটির উত্তর দিন, পছন্দ সাধারণত স্পষ্ট হয়ে যায়। আন্দাজ করা এমন নিয়ম তৈরি করে যা পরীক্ষায় কাজ করে আর উৎপাদনে ব্যর্থ হয়।
একটি সেশন পরীক্ষা করুন, পৃষ্ঠা নয়
পৃষ্ঠাটি লোড করুন, তারপর গুরুত্বপূর্ণ কাজটি করুন: সাইন ইন করুন, প্লেব্যাক শুরু করুন, একটি ফাইল আপলোড করুন। এর প্রত্যেকটি ভিন্ন হোস্টে পৌঁছাতে পারে, আর যেটি ব্যর্থ হয় সেটিই আপনার নিয়মের মিস করা।
পৃষ্ঠাটি যা দেখায় তার বদলে সেশনটি আসলে যা সংস্পর্শ করে তা তালিকাভুক্ত করুন:
dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5তুলনার সময় রিজলভারটি দৃশ্যমান রাখুন, কারণ যে নিয়ম একটি রিজলভার থেকে কাজ করে আর অন্যটি থেকে ব্যর্থ হয়, তা আপনাকে টানেল সম্পর্কে নয়, CDN-এর উত্তর সম্পর্কে বলে। ছোট TTL-ও বোঝায় যে আপনি যে উত্তরটি রেকর্ড করেছেন তার একটি মেয়াদ আছে।
প্রতিটি ব্যবস্থা আসলে কী ঢাকে
দুটি ব্যবস্থা সেটিংস পৃষ্ঠায় বিনিময়যোগ্য দেখায়, কিন্তু ভেতরে ভিন্নভাবে আচরণ করে।
| Mechanism | What it matches | How it fails |
|---|---|---|
| Domain rule | Names the client resolves, then their addresses | Misses subdomains, or goes stale when refresh is off |
| Address route | A prefix you wrote down | Keeps matching an address the service has left |
কার্নেলের ঠিকানা রুট প্রিফিক্স মেলায়। হোস্টনেম কী তা এর জানা নেই, তাই যে সেবা ঠিকানা বদলায় তাকে অনুসরণ করতে পারে না। ডোমেইন নিয়ম নাম রিজলভ করে ফলাফল রাউট করে; এটি সেবাটিকে অনুসরণ করে কিন্তু রিজলভার, রিফ্রেশ আচরণ ও সাবডোমেইন নিয়ে ক্লায়েন্টের ব্যবহারের ওপর নির্ভর করে, তাই নাম অনুসরণকারী নিয়ম ক্লায়েন্ট যে রিজলভার আসলে ব্যবহার করে সেটি দিয়েই পরীক্ষা করতে হবে।
কোনোটিই অন্যটির সুপারসেট নয়, তাই নোট ছাড়া দুটিকে মেশালে পরে বিভ্রান্তি তৈরি হয়।
সেবা বদলানোর পরে আবার যাচাই করুন
ক্লায়েন্ট আপডেট বা সেবা পরিবর্তনের পরে একই সেশন পরীক্ষা আবার চালান। আগে কাজ করা ঠিকানার তালিকা সেই সময়ের প্রমাণ, সেবার অবকাঠামোর স্থায়ী ইনভেন্টরি নয়।
কোন ব্যবস্থা কোন হোস্টনেম ঢাকে এবং শেষবার কবে যাচাই করেছেন তা লিখে রাখুন।
এই নোটটিই এমন নিয়মের মধ্যে পার্থক্য যা আপনি রক্ষা করতে পারেন আর এমন নিয়মের মধ্যে যা কেউ ছুঁতে সাহস করে না। সেবাটি যদি নিজের প্রিফিক্স তালিকা প্রকাশ করে, তা ব্যবহার করুন এবং তারিখ উল্লেখ করুন। যদি না করে, তা বলুন, আর ডোমেইন নিয়মটি তার রিফ্রেশ আচরণসহ পাশে লিখে রাখুন।