VPN ঠিকানা স্থান বরাদ্দ দিয়ে বাছুন, অস্পষ্টতা দিয়ে নয়
বেঞ্চমার্ক, ভাগাভাগি ও নথিভুক্তির রেঞ্জগুলোর প্রত্যেকের মালিক ও উদ্দেশ্য আছে। রেজিস্ট্রি থেকে VPN স্থান বাছুন, তারপর যে ওভারল্যাপ সরাতে পারবেন না তা পরিকল্পনা করুন।
অস্বাভাবিক দেখতে একটি প্রিফিক্স ঘর ও অফিসের ঠিকানা সংঘর্ষ থেকে বেরোনোর পথ মনে হয়, এবং সাধারণত তা নয়। IPv4 বিশেষ উদ্দেশ্য রেজিস্ট্রির প্রতিটি ব্লকের মালিক, উদ্দেশ্য এবং থাকার কারণ আছে, এবং শান্ত দেখায় বলে একটি ধার করা সংঘর্ষ সরানোর বদলে স্থানান্তর করে। এটি একটি ক্রম হিসেবে চালান: বরাদ্দ পড়ুন, ইতিমধ্যে কী ওভারল্যাপ করছে তার তালিকা করুন, এবং তারপরেই সিদ্ধান্ত নিন আপনি পুনঃসংখ্যায়ন করছেন, অনুবাদ করছেন নাকি নতুন স্থান তৈরি করছেন। ক্রম গুরুত্বপূর্ণ কারণ তৃতীয় ধাপ প্রথম দুটি কী পেয়েছে তার উপর নির্ভর করে।
রেঞ্জ ধার করার আগে বরাদ্দ পড়ুন
IANA-র বিশেষ উদ্দেশ্য রেজিস্ট্রি পুনর্ব্যবহারযোগ্য ব্যক্তিগত স্থান হওয়া রেঞ্জগুলোকে একটি নির্দিষ্ট কারিগরি উদ্দেশ্যে কাজ করা রেঞ্জ থেকে আলাদা করে। ব্যক্তিগত ব্যবহার, ভাগাভাগি ঠিকানা স্থান, বেঞ্চমার্ক ও নথিভুক্তি ব্লক স্প্রেডশিটে একই রকম দেখায় এবং রাউট হওয়ার পর সম্পূর্ণ ভিন্ন আচরণ করে।
| Range | Category | What it means for a VPN plan |
|---|---|---|
| 172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8 | RFC 1918 private use | Reusable by any network, so remote sites may already use the same numbers |
| 100.64.0.0/10 | Shared address space | Intended for provider-side carrier-grade NAT arrangements, not a second private pool |
| 198.18.0.0/15 | Benchmarking | Reserved for test traffic measurement; not spare production space |
| 203.0.113.0/24, 198.51.100.0/24, 192.0.2.0/24 | Documentation (RFC 5737) | Illustration only; a guide that uses them is not assigning them to you |
| 169.254.0.0/16, 240.0.0.0/4 | Link-local, reserved | Never a routed site subnet, whatever the prefix length suggests |
কেবল দ্বিতীয় অক্টেটে আলাদা দুটি প্রিফিক্স একই ব্লক নয়: 198.18.0.0/15 বেঞ্চমার্ক সংরক্ষণ বহন করে, আর 192.18.0.0/16 তেমন কিছু বহন করে না। কেবল সংরক্ষিত রেঞ্জের মতো দেখতে একটি সংখ্যা তার অর্থ উত্তরাধিকারসূত্রে পায় না। এই বিভ্রান্তি ফায়ারওয়াল নিয়মে পৌঁছানোর আগে দ্বিতীয়বার দেখার যোগ্য হওয়ার মতো সাধারণ।
পণ্য কখনও কখনও সমন্বিত ওভারলের ভেতরে বিশেষ রেঞ্জ সচেতনভাবে ব্যবহার করে, এবং সেটিই তাদের নথিভুক্ত করার মতো নকশা। এটি একই রেঞ্জকে অসংযুক্ত LAN-এর জন্য খালি জায়গা করে না। প্রকাশ্য স্থানও লুকানোর জায়গা নয়: অন্যের ঠিকানার দিকে ব্যক্তিগত পথ তার বৈধ গন্তব্যের জন্য পাঠানো ট্রাফিক ঘুরিয়ে দেয়।
ইতিমধ্যে থাকা ওভারল্যাপগুলোর তালিকা করুন
প্রিফিক্স বাছার আগে টানেল থেকে পৌঁছানো যাবে এমন প্রতিটি নেটওয়ার্ক তালিকাভুক্ত করুন। সাইট, ক্লায়েন্ট পুল, ক্লাউড VPC এবং অংশীদার লিঙ্ক সবই গণনা করা হয়, এবং প্রথম সংযোগ প্রচেষ্টা ব্যর্থ না হওয়া পর্যন্ত মানুষ অংশীদার লিঙ্কটিই ভুলে যায়।
ip -4 route show table all ip -6 route show ip -br addr ip route get 192.168.1.10
ফলাফল একটি সারণিতে প্রতিটি রেঞ্জের মালিককে পাশে রেখে দিন। যে রেঞ্জের মালিক আপনি বলতে পারেন না সেটি পরে পুনঃসংখ্যায়ন করতে পারবেন না, এবং এই তালিকাই «অস্বাভাবিক» প্রিফিক্স নিয়ে বিতর্ককে নির্দিষ্ট সংখ্যা নিয়ে সিদ্ধান্তে বদলে দেয়। যে সংঘর্ষ এড়াতে চাইছেন তা সত্যিকারে না কল্পনায় আছে তাও এটি জানায়।
যদি দূরবর্তী কর্মীর বাড়ির নেটওয়ার্ক অফিসের LAN-এর মতো একই প্রিফিক্স ব্যবহার করে, তবে সেই সংঘর্ষ তালিকায় দেখা যায় এবং স্পষ্টভাবে মোকাবেলা করা যায়। এটি প্রমাণ নয় যে বেঞ্চমার্ক ব্লক বুদ্ধিমান পছন্দ হবে, এবং এভাবে বিবেচনা করাই পরবর্তী সংঘর্ষ তৈরি করার উপায়।
প্রিফিক্স কপি করার বদলে একটি অনন্য ULA তৈরি করুন
IPv6 পুনর্ব্যবহারের সমস্যাটি আরও সুন্দর সংখ্যার বদলে অন্য কৌশলে সমাধান করে। RFC 4193 স্থানীয়ভাবে বরাদ্দকৃত অনন্য স্থানীয় ঠিকানাগুলোকে সিউডো-র্যান্ডম 40-bit বৈশ্বিক শনাক্তকারীসহ সংজ্ঞায়িত করে, যা আপনাকে এমন সাইট /48 দেয় যার অন্য কারও সঙ্গে সংঘর্ষের সম্ভাবনা খুব কম। সম্ভাবনা বেশি, পরম নয়, এবং ULA প্রিফিক্স এখনও ইন্টারনেট প্রবেশযোগ্যতা দেয় না।
openssl rand -hex 5
দশটি হেক্সাডেসিমেল অঙ্ক চল্লিশ বিট। তাদের আগে fd বসান এবং /48-এ দলবদ্ধ করুন: 3f9c1a7b02-এর আউটপুট fd3f:9c1a:7b02::/48 হয়। প্রতিটি সাইটের জন্য একটি তৈরি করে লিখে রাখুন, প্রতিটি স্থাপনায় একই সুবিধাজনক fd00::/48 আটকানোর বদলে।
তারপর নিশ্চিত করুন যে পুরো পথটি সত্যিই IPv6 বলে। ক্লায়েন্ট, গেটওয়ে, রুট, ব্যক্তিগত DNS এবং সেবা নীতি সবাইকে একমত হতে হবে, এবং টানেলে প্রিফিক্স বরাদ্দ করলে কেবল IPv4-ভিত্তিক অ্যাপ্লিকেশন তা ব্যবহার করতে শুরু করে না।
যে ওভারল্যাপ সরাতে পারবেন না তা পরিকল্পনা করুন
কিছু ওভারল্যাপ স্থায়ী, সাধারণত কারণ অংশীদার পুনঃসংখ্যায়ন করবে না এবং আপনি বাধ্য করতে পারবেন না। তখন আপনি সচেতনভাবে সমর্থিত কৌশল বাছেন: নিজের দিকে পুনঃসংখ্যায়ন, বিচ্ছিন্ন রাউটিং প্রসঙ্গ, বা সীমান্তে স্পষ্ট অনুবাদ। সচেতনভাবে বাছাই মানে লেখা যে কোনটি বেছেছেন এবং বাকি দুটি কেন বাতিল হয়েছে। সেই টীকাই ভবিষ্যতের পরিবর্তন পর্যালোচনা সত্যিই পড়বে।
অনুবাদকে ফেরার পথ সংরক্ষণ করতে হবে, অর্থাৎ মূল ও উপস্থাপিত উভয় প্রিফিক্স লিখে রাখতে হবে এবং সেগুলোতে সমাধান হওয়া ব্যক্তিগত DNS নামের সঙ্গে মেলাতে হবে। ম্যাপ করা উপনাম একটি সংযোগকে দ্ব্যর্থহীন করতে পারে; এটি মূল ঠিকানাগুলোকে বিশ্বব্যাপী অনন্য করে না এবং দ্বিতীয় ম্যাপিং ছাড়া দ্বিতীয় ওভারল্যাপিং অংশীদারকে টিকিয়ে রাখতে পারবে না।
বরাদ্দটি তার ব্যতিক্রমসহ লিখুন
প্রতিটি প্রিফিক্স, তার শ্রেণি, মালিক এবং বাছাইয়ের কারণ তালিকাভুক্ত করা একটি নথি দিয়ে শেষ করুন। ব্যতিক্রমগুলো তাদের অনুবাদ বা পুনঃসংখ্যায়ন নিয়ম এবং কেউ অনুমোদন করার তারিখসহ যোগ করুন। এটি বাস্তবায়নকারী ফায়ারওয়াল নিয়মের পাশে রাখুন, ঘটনার সময় কেউ না খোলা উইকিতে নয়। নথিটিই ডেলিভারেবল, তার সারাংশ নয়।
সেই রেকর্ডই পরবর্তী প্রকৌশলীকে আরও অদ্ভুত দেখতে সংখ্যা খোঁজা থেকে বিরত রাখে, এবং এই সমস্যাটি প্রতি কয়েক বছরে নতুন নামে আবার আবিষ্কৃত হয় এভাবেই। এটি পরিবর্তন পর্যালোচনাকে প্রিফিক্স নিয়ে মতের বদলে অনুমোদনের জন্য ঠোস কিছু দেয়। এটি একবার, বরাদ্দের শেষে লিখুন, যখন যুক্তি এখনও আপনার সামনে।