সুসংগত VPN ক্লায়েন্ট অ্যাড্রেস পুল কীভাবে পরিকল্পনা করবেন
সার্ভারের ফিল্ডে পুলটি বাছুন, তারপর ক্লায়েন্ট আসলে যে ঠিকানা পায় তা পড়ুন, উত্তরটি ফিরতি পথে অনুসরণ করুন এবং রেঞ্জ, মোড, রুট ও DNS পরিসর লিখে রাখুন।
VPN সার্ভারের পুল ফিল্ডে শুরু করুন, স্প্রেডশিটে নয়। আপনি সেখানে যা লিখবেন তা পরবর্তীতে সংযুক্ত প্রতিটি ক্লায়েন্টের অভ্যন্তরীণ ঠিকানা-স্থান হয়ে যায়, এবং তা সেই ক্লায়েন্টরা যে LAN-এ পৌঁছায়, তার পেছনের রাউটেড সাইট এবং ক্লায়েন্টের বাড়িতে ইতিমধ্যে থাকা ঠিকানার সঙ্গে সহাবস্থান করতে হবে। পুল সংরক্ষণের সঙ্গে সঙ্গেই একটি ক্লায়েন্ট সংযুক্ত করুন, কারণ সেই প্রথম সংযোগই আপনাকে বলে মানটি বাস্তবে কাজ করে কি না। সেখান থেকে পরিভ্রমণ বাইরের দিকে এগোয়: ক্লায়েন্ট যে ঠিকানা পেয়েছে, উত্তর যে পথ ধরে, এবং আপনি যে রেকর্ড রেখে যান।
পুল ফিল্ডে শুরু করুন, কোনো ক্লায়েন্ট সংযুক্ত হওয়ার আগেই
প্রতিটি পণ্য এটি ভিন্নভাবে প্রকাশ করে, তাই যে অবজেক্টটি আসলে ঠিকানা বরাদ্দ করে তা খুঁজুন। OpenVPN-এ সার্ভার-পাশের পুল নির্দেশিকা আছে যা পরবর্তী মুক্ত ঠিকানা দেয়, IKEv2 গেটওয়েতে পিয়ার কনফিগারেশনের সঙ্গে বাঁধা একটি পুল অংশ আছে, আর WireGuard-এ কোনোটিই নেই কারণ প্রতিটি পিয়ার নিজের ঠিকানা নিজের কনফিগারেশন ফাইলে বহন করে। পুল নির্দেশিকা আর প্রতি-পিয়ার ঠিকানা বিনিময়যোগ্য নয়, এবং ভুলটি সম্পাদনা করলে পরিভ্রমণের বাকি অংশ বৃথা যায়।
ফিল্ড পেলে ইতিমধ্যে থাকা রেঞ্জগুলো তালিকাভুক্ত করুন: অফিস LAN, প্রতিটি রাউটেড সাইট, ক্লাউড VPC এবং সেবায় থাকা অন্য যেকোনো পুল। ওভারল্যাপ প্রিফিক্স গাণিতিকভাবে নির্ধারিত হয়, হোস্ট নম্বরগুলো চেনা লাগে কি না তা দিয়ে নয়, তাই প্রতিটি রেঞ্জের সঙ্গে সমষ্টিটি তুলনা করুন। 10.x-এর মতো দেখতে দুটি রেঞ্জ নিরীহ যখন তাদের সমষ্টি ছেদ করে না, আর সাপোর্ট ঘটনা যখন ছেদ করে।
তারপর সিদ্ধান্ত নিন ঠিকানাটি কে সংযুক্ত হয় তার ফাংশন, না কখন সংযুক্ত হয় তার। গতিশীল বরাদ্দ যা মুক্ত তা দেয়, আর পরিচয়ভিত্তিক বরাদ্দ একটি নির্দিষ্ট ঠিকানাকে একটি ক্রেডেনশিয়ালের সঙ্গে বেঁধে দেয়। পছন্দটি লিখে রাখুন, কারণ এটি পরে পুনঃসংযোগ কেমন হওয়া উচিত তা বদলে দেয়।
ক্লায়েন্ট আসলে যে ঠিকানা পেয়েছে তা পড়ুন
একটি ক্লায়েন্ট সংযুক্ত করুন এবং টানেল যা জানায় তা পড়ুন, পুল যা প্রতিশ্রুতি দিয়েছিল তা নয়। ক্লায়েন্ট সংযোগের অবস্থায় তার অভ্যন্তরীণ ঠিকানা দেখায়, আর Linux-এ ইন্টারফেসটি তা সরাসরি বহন করে।
সেই ঠিকানাটি আপনার সংরক্ষিত রেঞ্জের সঙ্গে তুলনা করুন। যদি তা রেঞ্জের বাইরে থাকে, আপনি যে বরাদ্দ-পথটি সম্পাদনা করেছিলেন তার চেয়ে ভিন্ন একটি দেখছেন। প্রিফিক্সের দৈর্ঘ্যও পরীক্ষা করুন, কারণ /32 বহনকারী ক্লায়েন্টের কোনো অন-লিংক পিয়ার থাকে না এবং প্রতিটি গন্তব্য তার ডিফল্ট রুট দিয়ে পাঠায়।
ip -4 addr show tun0
ip route get 192.168.50.20
একই রেঞ্জ ব্যবহার করা হোম রাউটার থেকে সংযুক্ত ক্লায়েন্ট সংযুক্ত হবে এবং তারপর প্রায় কিছুই পৌঁছাবে না। ক্লায়েন্ট সেই প্রিফিক্সের জন্য তার স্থানীয় রুট ধরে রাখে, তাই টানেল ঠিকানাটি তার পেছনের নেটওয়ার্কের সঙ্গে সংঘর্ষে পড়ে এবং ট্রাফিক ভুল ইন্টারফেস দিয়ে বেরিয়ে যায়। সেই ক্ষেত্রটি সার্ভারে মেরামত করা যায় না; নথিভুক্ত প্রতিকার হলো হোম নেটওয়ার্ক পুনঃসংখ্যায়ন করা বা যথেষ্ট দূরের পুল রেঞ্জ বেছে নেওয়া যাতে সংঘর্ষ বিরল থাকে। ব্যর্থতা ও প্রতিকার দুটোই লিখে রাখুন, কারণ হেল্প ডেস্ক আবার এটি পাবে।
একই ক্লায়েন্ট আবার সংযুক্ত করুন এবং ঠিকানাটি লক্ষ্য করুন। গতিশীল পুল একই মান বা ভিন্ন মান ফেরত দিতে পারে এবং দুটোই সঠিক, অন্যদিকে পরিচয়ভিত্তিক পুল যা ঠিকানা বদলায় তা বন্ধনটি মানছে না। সেই পরীক্ষায় কয়েক সেকেন্ড লাগে এবং প্রথম অংশে আপনি যে মোড লিখেছিলেন সেটিই কার্যকর মোড কি না তা নিষ্পত্তি করে।
সেবা থেকে উত্তর ফিরতি পথে অনুসরণ করুন
পুল কেবল তখনই কাজ করে যখন উত্তরগুলো তার কাছে ফিরে যেতে পারে। LAN-এর একটি সেবা অভ্যন্তরীণ ঠিকানায় উত্তর দেয়, তাই তার গেটওয়ের পুলের জন্য একটি রুট বা সেবার সামনে একটি অনুবাদ দরকার। যখন কোনো অনুরোধ টানেল দিয়ে আসে আর উত্তর ভিন্ন পথে বেরোয়, তখন স্টেটফুল ফায়ারওয়াল বা বিপরীত-পথ পরীক্ষা তা ফেলে দেয়, এবং ক্লায়েন্ট এমন সেবা দেখে যা সংযুক্ত হয় তারপর ঝুলে থাকে। প্রতি-হোস্ট রুট যোগ করার বদলে পুলটিকে রাউটিং নকশায় একটি সংক্ষেপণযোগ্য ব্লক হিসেবে রাখুন।
অনুবাদ বদলে দেয় বাকি সিস্টেম যা দেখে। যখন উৎস পুনঃলিখিত হয়, হোস্ট ফায়ারওয়ালে ও অ্যাপ্লিকেশন লগে থাকা ঠিকানাটি অনূদিতটি হয়, তাই পুল ঠিকানার বিরুদ্ধে লেখা নিয়ম কিছুর সঙ্গে মেলে না এবং লগের লাইন কোনো ক্লায়েন্ট পর্যন্ত ফেরানো যায় না। strongSwan-এর ফরওয়ার্ডিং ডকুমেন্টেশন IKEv2 গেটওয়ের জন্য সেই পথের সার্ভার-পাশের অর্ধেকটি কভার করে। DNS একই সীমাবদ্ধতা বহন করে, কারণ যে নাম এমন ঠিকানায় সমাধান হয় যা ক্লায়েন্ট পৌঁছাতে পারে না তা পরে এবং অন্য জায়গায় ব্যর্থ হয়।
দুটি ক্লায়েন্ট, তারপর একটি প্রত্যাহার
একসঙ্গে দুটি ক্লায়েন্ট সংযুক্ত করুন এবং দুটি ঠিকানাই পড়ুন। সেগুলো আলাদা, ব্যবহারযোগ্য এবং পুলের ভিতরে হতে হবে, আর প্রতিটি তার উদ্দিষ্ট সেবায় পৌঁছাতে হবে। যে পুল নকল ঠিকানা দেয় তা সাধারণত এখানেই ধরা পড়ে, প্রথম একক-ক্লায়েন্ট পরীক্ষায় নয়।
অন্য ক্লায়েন্ট সংযুক্ত থাকা অবস্থায় একটি ক্রেডেনশিয়াল প্রত্যাহার করুন, তারপর টিকে থাকা ক্লায়েন্ট থেকে সেবাটি চেষ্টা করুন। যে প্রত্যাহার অন্য সেশনকে বিঘ্নিত করে তা ভাগ করা অবস্থার দিকে ইঙ্গিত করে, প্রায়শই একটি ক্রেডেনশিয়াল বা একটি ঠিকানা ডিভাইস জুড়ে পুনর্ব্যবহৃত হয়। প্রত্যাহৃত ক্লায়েন্ট আবার সংযুক্ত করুন এবং নিশ্চিত করুন যে মুক্ত হওয়া ঠিকানাটি দেওয়ার বদলে তাকে প্রত্যাখ্যান করা হয়।
এমন গন্তব্য দিয়ে শেষ করুন যা প্রত্যাখ্যান করা উচিত। যে ক্লায়েন্ট সবকিছুতে পৌঁছায় তাকে সংযুক্ত করা হয়েছে, পরীক্ষা করা হয়নি।
চারটি মান সেখানেই লিখুন যেখানে পরবর্তী পরিবর্তন তাদের খুঁজে পাবে
রেকর্ডটি ছোট: পুল রেঞ্জ ও প্রিফিক্স, বরাদ্দ মোড, ব্যবহৃত ফেরত-পথ বা অনুবাদ, এবং সেই গন্তব্যগুলোর জন্য উত্তর দেওয়া DNS পরিসর। এটি টিকিটে নয়, সার্ভার কনফিগারেশনের পাশে রাখুন এবং তারিখ দিন। পরে চারটির একটি বদলানো যে কেউ তার সামনে বাকি তিনটি চাইবে, কারণ পুলের আকার বদলালে রুট ভাঙে আর রুট বদলালে DNS উত্তর ভাঙে।
এর সঙ্গে মালিকানা-নোটটি রাখুন: টানেল রেঞ্জ VPN সার্ভারের, এবং LAN DHCP পরিসরে করা একটি সংরক্ষণ টানেলের ভিতরের ক্লায়েন্টের জন্য কিছুই সংরক্ষণ করে না। সেই এক লাইনই সবচেয়ে সাধারণ পুনঃকাজ আটকায়, যেখানে কেউ একটি সংরক্ষণ যোগ করে এবং আশা করে টানেল ঠিকানা তা অনুসরণ করবে।