সাইট VPN-এর আগে সাবনেট পরিকল্পনা করুন: পুনঃসংখ্যায়ন বা অনুবাদ

দুটি অফিসই 192.168.1.0/24 ব্যবহার করে কারণ অন্য কেউ পরিকল্পনা করেনি, আর টানেলই এটি সমাধান করবে বলে ধরা হচ্ছে। তা পারে না: একটি রাউটার একই প্রাইভেট ঠিকানাকে দুটি ভিন্ন জায়গা বোঝাতে পারে না। এটি প্রতিরোধের কাজটি প্রথম টানেল প্যারামিটার লেখার আগেই ঘটে।

প্রতিটি রেঞ্জের তালিকা করুন, যেগুলো ভুলে গেছেন সেগুলোসহ

LAN, সার্ভার সেগমেন্ট, রিমোট-অ্যাক্সেস ক্লায়েন্ট পুল, ক্লাউড VPC রেঞ্জ এবং হোস্টগুলোর পৌঁছাতে হবে এমন যেকোনো কন্টেইনার বা ওভারলে নেটওয়ার্ক সংগ্রহ করুন। ক্লায়েন্ট পুলগুলোই মানুষ ভুলে যায়, এবং সেগুলো অবাক করার মতোই প্রায়ই কোনো অফিস রেঞ্জের সাথে ওভারল্যাপ করে, কারণ দুটোই একই ডিফল্ট থেকে বেছে নেওয়া হয়েছিল। ম্যানেজমেন্ট নেটওয়ার্ক এবং যেকোনো আউট-অব-ব্যান্ড সেগমেন্ট অন্তর্ভুক্ত করুন।

মালিক, গেটওয়ে, উদ্দেশ্য এবং প্রিফিক্সটি অন্য সাইট থেকে পৌঁছানোযোগ্য হতে হবে কি না তা লিখে রাখুন। যে প্রিফিক্সকে কখনোই টানেল পার হতে হয় না, সেটিকে অনন্য হতে হয় না, এবং এটা জানলে পুনঃসংখ্যায়নের কাজ কমে।

IPv6 আলাদাভাবে করুন, কারণ এর পরিকল্পনা ও এর ওভারল্যাপ স্বাধীন।

পরিচিত ঠিকানা নয়, প্রিফিক্স তুলনা করুন

ভিন্ন হোস্ট ঠিকানার দুটি নেটওয়ার্কও ওভারল্যাপ করতে পারে, কারণ ওভারল্যাপ মাস্কের বৈশিষ্ট্য, মানুষের মনে রাখা সংখ্যার নয়। 10.20.0.0/16-এ 10.20.30.0/24 আছে, কেউ জোরে বলুক বা না বলুক। সম্পূর্ণ প্রিফিক্স জোড়া তুলনা করুন, এবং অ্যাগ্রিগেটগুলো তাদের ভেতরের ছোট নেটওয়ার্কের সাথে মিলিয়ে দেখুন। এজন্য এই যাচাই স্প্রেডশিটে থাকা উচিত, কারও মাথায় নয়।

একই যাচাই VPN-এর নিজের ক্লায়েন্ট পুল এবং আপনি যে অনূদিত রেঞ্জটি চালু করার পরিকল্পনা করছেন তার ক্ষেত্রেও প্রযোজ্য, কারণ সংঘর্ষকারী অনূদিত রেঞ্জ মূল ওভারল্যাপের চেয়েও খারাপ।

মাস্কসহ প্রিফিক্সের একটি সারণিই যথেষ্ট; মাস্ক ছাড়া একটি ডায়াগ্রাম যথেষ্ট নয়।

আসলে কী পার হতে হবে তা ঠিক করুন

একটি সাইটে ত্রিশটি সাবনেট থাকতে পারে, অথচ একটি পরিষেবা নেটওয়ার্কের রিমোট অ্যাক্সেস দরকার। সেই প্রয়োজন থেকেই শুরু করুন এবং শুধু যা দরকার তা ঘোষণা করুন, কারণ ছোট ঘোষণা ও মিলে যাওয়া অ্যাক্সেস নিয়ম পর্যালোচনা করা সহজ এবং ভুলবশত বিস্তৃত করা কঠিন। ব্যবহৃত প্রতিটি প্রাইভেট রেঞ্জ ঘোষণা করা এমন একটি অভ্যাস যা টানেলকে সেতুতে পরিণত করে। ঘোষণা যত সংকীর্ণ, ভবিষ্যতের ভুলের প্রভাবের পরিধি তত ছোট।

প্রাইভেট DNS-কে এমন ঠিকানা ফেরত দিতে হবে যেগুলো অভীষ্ট ক্লায়েন্টরা পৌঁছাতে পারে, তাই অঘোষিত বা ওভারল্যাপিং রেঞ্জের দিকে ইঙ্গিত করা নাম লুকআপ সফল হলেও ভাঙাই থাকে।

অ্যাক্সেস তালিকাটি টানেল কনফিগারেশনের আগে লিখুন, ব্যর্থ হওয়ার পরে নয়।

পুনঃসংখ্যায়ন করুন বা অনুবাদ করুন, এবং খরচ জানুন

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

যেটিই বেছে নিন, মূল এবং উপস্থাপিত—দুটো ঠিকানাই নথিভুক্ত করুন, কারণ পরবর্তী প্রতিটি সমস্যা-সমাধানের আলোচনায় দুটোই দরকার।

প্রত্যাবর্তন পথ ছাড়া কোনো সমাধান সমাধান নয়।

গ্রহণযোগ্যতা পরীক্ষা হিসেবে রুট ম্যাট্রিক্স ব্যবহার করুন

শেষ করুন একটি ম্যাট্রিক্স দিয়ে: স্থানীয় প্রিফিক্স, দূরবর্তী প্রিফিক্স, অনুমোদিত পরিষেবা এবং ফেরৎ গেটওয়ে। টানেল উঠলে ওই সারণিই গ্রহণযোগ্যতা পরীক্ষা, এবং এটিই সেই নথি যা পরবর্তী ইঞ্জিনিয়ার পড়বেন। গেটওয়ে থেকে নয়, নির্বাচিত সাবনেটের বাস্তব হোস্ট থেকে পরীক্ষা করুন।

টানেল ঠিকানার মধ্যে ping প্রমাণ করে টানেল আছে, এর পেছনের ঠিকানা পরিকল্পনা সম্পর্কে কিছুই নয়।

ম্যাট্রিক্সটি টানেল কনফিগারেশনের সাথে রাখুন, এবং পরবর্তী সাইট যোগ করা শুরু হবে ডেটা থেকে, স্মৃতি থেকে নয়। পরিকল্পনা থাকলে strongSwan ফরওয়ার্ডিং গাইড গেটওয়ে দিকটি কভার করে।