VPN এন্ডপয়েন্ট নাম বনাম ব্যক্তিগত সেবার নাম: দুই মালিক

দুটি নাম একই শাখা বর্ণনা করতে পারে এবং সম্পূর্ণ ভিন্ন প্রশ্নের উত্তর দিতে পারে। vpn.branch.example দূরবর্তী সহকর্মীকে বলে VPN এন্ডপয়েন্ট কোথায় পাবে, এবং কোনো টানেল তৈরি হওয়ার আগেই এটি রিজলভ হতে হবে। inventory.branch.example অনুমোদিত ব্যবহারকারীকে বলে ব্যক্তিগত অ্যাপ্লিকেশন কোথায় থাকে, আর টানেল চালু হওয়ার পরেই কেবল এটি গুরুত্বপূর্ণ। এর একটির রক্ষণাবেক্ষণ অন্যটির জন্য কিছুই করে না।

যেকোনোটি ডিবাগ করার আগে দুটি রেকর্ডের নাম দিন

দুটিই তাদের মালিকদের সঙ্গে লিখে রাখুন। এন্ডপয়েন্টের জন্য লিখুন কে সর্বজনীন ঠিকানা হালনাগাদ করে এবং VPN ক্লায়েন্ট কীভাবে তার উত্তর সতেজ করে। সেবার জন্য লিখুন কে ব্যক্তিগত ঠিকানার মালিক, কোন জোন রেকর্ডটি রাখে এবং কোন রিজলভারগুলোর এর জন্য উত্তর দেওয়ার কথা।

এই সংক্ষিপ্ত তালিকা এই ক্ষেত্রের সবচেয়ে সাধারণ ভুল রোগনির্ণয় ঠেকায়: একটি কাজ করা শাখা টানেল পুনরায় চালু করা এমন একটি রেকর্ড সারাতে যা সম্পূর্ণভাবে তার ভিতরেই থাকে। টানেল সেবার নামের জন্য পরিবহন; এটি তার কর্তৃত্ব নয়।

কোনো পরিবর্তন প্রস্তাব করা হলে জিজ্ঞাসা করুন এটি দুটি রেকর্ডের কোনটিকে স্পর্শ করে। কেউ উত্তর দিতে না পারলে পরিবর্তনটি সময়সূচির জন্য প্রস্তুত নয়।

কোনো টানেল তৈরি হওয়ার আগেই এন্ডপয়েন্ট রিজলভ হতে হবে

ধরুন শাখার ইন্টারনেট সংযোগ নতুন একটি সর্বজনীন ঠিকানা পেল। এন্ডপয়েন্ট হালনাগাদকারী নতুন ঠিকানাটি প্রকাশ করে, এবং দূরবর্তী VPN বাস্তবায়নকে পরিবর্তিত উত্তরটি পড়তে পারতে হবে। যে রিজলভারই সেই উত্তর দেয়, তাকে টানেল ছাড়াই নাগালে থাকতে হবে, নইলে ক্লায়েন্ট এমন একটি নামের পিছু ছুটছে যা সে কেবল সেই জিনিসটির সঙ্গে সংযোগ করার পরেই রিজলভ করতে পারে যা সে খুঁজে পাচ্ছে না।

এই বুটস্ট্র্যাপ নির্ভরতা স্পষ্ট করে বলা দরকার, কারণ সব অভ্যন্তরীণ রিজলভার VPN-এর পিছনে থাকলে এটি দুর্ঘটনাক্রমে তৈরি করা সহজ। এন্ডপয়েন্ট অনুসন্ধানের জন্য টানেলের আগের একটি পথ রাখুন, এবং নতুন উত্তর সঙ্গে সঙ্গে ধরা পড়বে ধরে নেওয়ার বদলে ক্লায়েন্টের পুনঃসংযোগ আচরণ নিশ্চিত করুন।

ডায়নামিক DNS-এরও সীমা আছে যা রেকর্ড হালনাগাদ পার হতে পারে না। রেকর্ড হালনাগাদ কোনো ফায়ারওয়াল পোর্ট খোলে না, NAT ম্যাপিং তৈরি করে না এবং কোনো সহকর্মীর পরিচয় প্রমাণ করে না। বন্ধ পোর্টসহ প্রকাশিত ঠিকানা এমন ক্লায়েন্ট দেয় যা সঠিকভাবে রিজলভ করে এবং তবুও কোনো কিছুতে সংযোগ করতে পারে না।

শেষে, চলমান ক্লায়েন্ট পুনঃসংযোগের আগ পর্যন্ত ক্যাশে করা এন্ডপয়েন্ট ব্যবহার চালিয়ে যেতে পারে। আপনার নোটে প্রকাশ, ক্যাশে ও পুনঃসংযোগ নীতি আলাদা রাখুন, যাতে পুরোনো সহকর্মীকে নষ্ট হালনাগাদকারী ভুল না করা হয়।

সেবার নাম বলে অ্যাপ্লিকেশনটি কোথায় থাকে

এখন ধরুন টানেল সুস্থ থাকে কিন্তু ইনভেন্টরি সার্ভার 172.26.14.20 থেকে 172.26.14.35-এ সরে যায়। সর্বজনীন এন্ডপয়েন্ট রেকর্ড অপরিবর্তিত থাকে, অথচ ব্যক্তিগত সেবা রেকর্ড বদলাতে হয়। ওই সেবার জন্য সংরক্ষিত ঠিকানা বা স্থির বরাদ্দ ব্যবহার করলে এটি বিরল থাকে; অনুমোদিত হালনাগাদ পথ সেই সময়গুলো সামলায় যখন এটি ইচ্ছাকৃত।

এখানে দুটি হালনাগাদ প্রক্রিয়া মিশে যায়। RFC 2136 একটি জোনে DNS রেকর্ড যোগ ও মুছে ফেলার প্রোটোকল নির্ধারণ করে, আর বাণিজ্যিক ডায়নামিক DNS প্রদানকারী ভিন্ন উদ্দেশ্যে সম্পূর্ণ ভিন্ন HTTP API দিতে পারে। একটি ব্যবহার করলে বোঝায় না অন্যটি আপনার পরিবেশে আছে। এর বিরুদ্ধে হালনাগাদকারী লেখার আগে আপনার জোন আসলে কোন প্রক্রিয়া গ্রহণ করে তা যাচাই করুন।

সঠিক ব্যক্তিগত উত্তর কেবল প্রথম শর্ত। দূরবর্তী ডাককারীকে এটি ব্যবহার করতে দিতে ক্লায়েন্টের দরকার ব্যক্তিগত জোন বহনকারী একটি রিজলভার, সেই রিজলভারে কোয়েরি অনুমোদনকারী নীতি, এবং যে ঠিকানা ফিরে আসে তার জন্য ফরওয়ার্ডিং। এমন ঠিকানায় রিজলভ হওয়া নাম যা ক্লায়েন্টের নাগালে নেই, সার্ভার ত্রুটির মতো দেখতে একটি টাইমআউট তৈরি করে।

দুটি পথ আলাদাভাবে পরীক্ষা করুন

টানেলের বাইরে থেকে এন্ডপয়েন্ট এবং তার ভিতর থেকে সেবা যাচাই করুন, আর ফলাফল দুটি স্বতন্ত্র তথ্য হিসেবে রাখুন:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

প্রথম কোয়েরি ব্যর্থ হলে সমস্যা সর্বজনীন প্রকাশে বা টানেলের আগের রিজলিউশন পথে, আর কোনো অভ্যন্তরীণ পরিবর্তন সাহায্য করবে না। দ্বিতীয়টি ঠিকানা ফেরত দিলে কিন্তু তৃতীয়টি টানেল দিয়ে কোনো রুট না দেখালে, DNS স্তর ঠিক আছে আর ফরওয়ার্ডিং নীতি নয়।

প্রতিটি ঠিকানা পরিবর্তনের পরে জোড়াটি চালান এবং কোন রেকর্ড সরে গেছে তা টুকে রাখুন। যে হস্তান্তর কেবল বলে «DNS হালনাগাদ হয়েছে» তা পরের প্রকৌশলীকে অনুমান করতে ছেড়ে দেয় দুটি জীবনচক্রের মধ্যে কোনটি সত্যিই চলেছিল।