ভৌগোলিক DNS ও অ্যানিকাস্ট: আপনি যে VPN এন্ট্রি পান তা যাচাই
ভৌগোলিক DNS ও অ্যানিকাস্ট ভিন্ন নিয়মে এন্ট্রি পয়েন্ট বেছে নেয়। উত্তরটি কোন রিজলভারকে প্রতিফলিত করে তা যাচাই করুন, তারপর দেখুন নোড পরিবর্তনে সেশন টিকে আছে কি না।
কাছের DNS উত্তরকে সমাধান হওয়া সমস্যা মনে হয়, যতক্ষণ না সংযোগটি অন্য জায়গায় গিয়ে পড়ে। ভৌগোলিক DNS ও অ্যানিকাস্ট দুটোই পথ ছোট করার চেষ্টা করে, আর তারা সেই সিদ্ধান্ত ভিন্ন তথ্য থেকে নেয়। কোনোটিই গ্যারান্টি দেয় না যে আপনি যে গেটওয়েতে পৌঁছান সেটি পৌঁছানোর যোগ্য, যে এটি আপনার ক্লায়েন্টের প্রত্যাশিত পরিচয় উপস্থাপন করে, বা যে আপনার সেশন নোড পরিবর্তন সইবে। নিচের যাচাইগুলো ওই চারটি প্রশ্ন আলাদা করে।
রিজলভার আসলে কার অবস্থান জানায় তা যাচাই করুন
টোপোলজি-সংবেদনশীল কোয়েরির উত্তর দেওয়া একটি অথরিটেটিভ সার্ভার সাধারণত যে রিকার্সিভ রিজলভার জিজ্ঞাসা করেছে তার ঠিকানা দেখে, নামটি টাইপ করা ব্যক্তির ঠিকানা নয়। একটি কেন্দ্রীভূত রিজলভার যে ক্লায়েন্টদের সেবা দেয় তাদের থেকে দূরে থাকতে পারে, আর উত্তরটি তাদের বদলে রিজলভারকেই প্রতিফলিত করে। এটি ত্রুটি নয়; অতিরিক্ত তথ্য না দেওয়া হলে প্রোটোকল এভাবেই আচরণ করে। EDNS ক্লায়েন্ট সাবনেট স্পেসিফিকেশন সীমাবদ্ধতা ও ঐচ্ছিক প্রতিকারের দুটোই বর্ণনা করে।
EDNS ক্লায়েন্ট সাবনেট মূল নেটওয়ার্কের তথ্য বহন করতে পারে, যদি প্রতিটি অংশগ্রহণকারী এটি সমর্থন ও সক্রিয় করে। এটি ঐচ্ছিক, এর গোপনীয়তা ও ক্যাশিং পরিণতি আছে, এবং কোনো পাবলিক রিজলভার সুনির্দিষ্ট ব্যবহারকারী অবস্থান জানায় বলে ধরে নেওয়ার অনুমতি এটি নয়। এটি ঘিরে নকশা করার আগে রিজলভার অপারেটরদের জিজ্ঞাসা করুন।
dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com
অ্যানিকাস্ট রাউটিং কী সিদ্ধান্ত নিয়েছে তা যাচাই করুন
অ্যানিকাস্টে একাধিক অবস্থান একটি সার্ভিস ঠিকানার জন্য পৌঁছানোর যোগ্যতা ঘোষণা করে, আর নেটওয়ার্ক প্রতিটি ক্লায়েন্টকে তার রাউটিং যে নোড পছন্দ করে সেখানে পৌঁছে দেয়। সেই বাছাই ম্যাপের দূরত্ব নয়, BGP ও আশপাশের নীতি করে। টোপোলজিক্যাল নৈকট্যও সাধারণত ভালো রাউন্ড-ট্রিপ কর্মক্ষমতা বোঝায় না, কারণ ছোট দেখানো পথটি ভিড়যুক্ত বা অসমমিত হতে পারে। আপনাকে যে ঠিকানা দেওয়া হয়েছে তা কোন নোড উত্তর দিয়েছে সে বিষয়ে কিছুই বলে না।
সার্ভিং অবস্থানটি কেবল DNS উত্তরের একা নয়, সার্ভিসের দিক থেকে বা যে উত্তর সেটির নাম বলে তা থেকে নিশ্চিত করুন। traceroute -n 198.51.100.20 আপনি যে পথ নিয়েছেন তা দেখায় এবং শেষ পর্যন্ত হোস্টের নামও বলে না, তাই এটি উত্তর নয় পথ হিসেবে পড়ুন।
সেশন নোড পরিবর্তন সইবে কি না তা যাচাই করুন
একটি DNS কোয়েরি ছোট আর একটি VPN সেশন দীর্ঘ, এবং দুটির অবস্থার প্রয়োজনীয়তা সম্পূর্ণ আলাদা। সেশনের মাঝপথে রাউটিং সরে যেতে পারে, আর যখন সরে যায়, পরের প্যাকেটগুলো এমন নোডে পৌঁছাতে পারে যা আপনার টানেল কখনো দেখেনি। এটি সইবে কি না তা নির্ভর করে বাস্তবায়নের উপর: ভাগ করা অবস্থা, ইচ্ছাকৃত পুনঃসংযোগ, বা নথিভুক্ত ব্যর্থতা। কেবল ঠিকানা এর কোনোটিই দেয় না।
ধরে নেওয়ার বদলে সরাটি পর্যবেক্ষণ করুন। sudo tcpdump -ni any -c 20 esp পথ বদলানোর সময় বাইরের প্যাকেটগুলো দেখায়, আর পিয়ার ঠিকানায় হঠাৎ পরিবর্তনই হলো সেই সরানো। আপনি যে বাস্তবায়ন চালান তার জন্য অভীষ্ট আচরণ স্পষ্টভাবে নির্ধারণ করুন, তারপর পথ জোর করে বদলে সেটি পরীক্ষা করুন। যদি নকশা সেশন প্রতিলিপি ধরে নেয়, প্রক্রিয়াটির নাম দিন এবং যে ব্যর্থতা এটি ঢাকে না তার নাম দিন।
পরিচয় এখনো মেলে কি না তা যাচাই করুন
প্রতিটি এন্ট্রি পয়েন্টকে আপনার ক্লায়েন্ট প্রোফাইলের প্রত্যাশিত পরিচয় উপস্থাপন করতে হবে। সার্ভিস নামের জন্য ইস্যু করা সার্টিফিকেট নোড জুড়ে কাজ করে, অথচ প্রতি-নোড সার্টিফিকেট ক্লায়েন্টকে নতুন কিছু গ্রহণ করতে বাধ্য করে, আর সেখানেই ব্যবহারকারীরা সতর্কবার্তা পেরোনো শেখে। প্রত্যাশিত পরিচয় ও প্রোফাইল এন্ট্রি মডেলের সঙ্গে সামঞ্জস্যপূর্ণ রাখুন।
এটি এমন ক্লায়েন্ট থেকে যাচাই করুন যা অস্বাভাবিক নোডে পৌঁছেছে, কারণ সেই ক্ষেত্রেই প্রতি-নোড সার্টিফিকেট দৃশ্যমান হয়। openssl s_client -connect vpn.example.com:443 -servername vpn.example.com চেইন ও নামগুলো ছাপে, আর ক্লায়েন্ট ঠিক সেটাই তুলনা করে। তারপর সিদ্ধান্ত নিন প্রোফাইল সংকুচিত করা উচিত কি সার্টিফিকেট মডেল বদলানো উচিত।
রেকর্ডটি যাচাই করুন, কেবল প্রথম উত্তর নয়
তিনটি পরিস্থিতি মূল্যায়ন করুন এবং প্রতিটির জন্য চারটি তথ্য লিখুন: সাধারণ এন্ট্রি, একটি অবস্থান অনুপলব্ধ, আর সম্মত পুনরুদ্ধার ক্ষেত্র। চারটি তথ্য হলো ব্যবহৃত রিজলভার, ফেরত দেওয়া ঠিকানা, যে অবস্থানটি সেবা দিয়েছে, এবং একটি নতুন অ্যাপ্লিকেশন ফলাফল। এই রেকর্ডটি DNS বাছাইয়ের সমস্যাকে গেটওয়ে সমস্যা, রাউটিং সমস্যা বা সেশন-অবস্থার সমস্যা থেকে আলাদা করে। এটি ছাড়া চারটিই ক্লায়েন্টের দিক থেকে একই রকম দেখায়।
dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health
পরিস্থিতিগুলো কেবল অফিস থেকে নয়, প্রতিনিধিত্বমূলক অ্যাক্সেস নেটওয়ার্ক থেকে চালান, কারণ পুরো প্রশ্নটি হলো ভিন্ন ক্লায়েন্টেরা সত্যিই কোন এন্ট্রি পয়েন্টে পৌঁছায়। একটি নেটওয়ার্ক একটির নমুনা।