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

একটি পিয়ার স্পর্শ করার আগে পাঠককে কী উত্তর দিতে হবে

কম্প্রেশন ঠিকানাকে গোছানো দেখায়, আর গোছানো ভাব গঠন নয়। গঠন হলো জানা: প্রদানকারী কোন পরিসর প্রতিনিধিত্ব করেছে, আপনি কোনটি বেছেছেন, কোনটি ক্লায়েন্ট পুল এবং কোনটি একটি সাইটের পেছনে বসে আছে।

পরের প্রান্তিকে যে সহকর্মী যোগ দেবে এবং দ্বিতীয় সাইট যোগ করবে তার জন্য লিখুন। এন্ট্রি নিজে না বললে পাতার কিছুই বলে না প্রিফিক্স কোথা থেকে এসেছে। এটি বাদ দিলে প্রথম পরিবর্তনই প্রত্নতত্ত্বে পরিণত হয়।

পরিকল্পনার প্রতিটি লাইনকে কী বহন করতে হবে

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

আজ দুটির একটি প্রিফিক্স ভাগ করলেও ভূমিকাগুলো আলাদা সারিতে রাখুন। সেগুলো এক করলে পরের বিভাজন সংশোধনের বদলে নতুন বণ্টনের মতো পড়ায়।

EntryFields to recordWhy a reviewer needs it
Endpoint addressesPrefix, owning side, session initiatorFirewall rules and peer config both read it
Tunnel interfacesPrefix and length, next hop, interface nameShows the path a packet actually takes
Client allocationsPool range, size, distributing componentShows room left before a redesign
Downstream networksPrefix, site label, return routeExplains a reply that never arrives

কোথায় প্রচলিত পাঠ্য ও কনফিগারেশন সিনট্যাক্স আলাদা হয়

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

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

প্রতিটি চিহ্নিত থাকলে দুটি স্বরলিপিই ঠিক। চিহ্নহীন মিশ্রণই ভুলটিকে আমন্ত্রণ জানায়।

কোথায় ওভারল্যাপিং পরিসর ও অনুপস্থিত ফেরার পথ দেখা যায়

ওভারল্যাপ অন্য ভুলের চেয়ে বেশি দিন টেকে, কারণ দুটি সাইট একই পরিসরের উত্তর দেওয়ার আগে কিছুই ভুল দেখায় না। সাইট চিহ্নিত করুন এবং উদাহরণ কপি না করে নথিভুক্ত পদ্ধতিতে অনন্য-স্থানীয় প্রিফিক্স তৈরি করুন।

ক্লায়েন্ট তালিকা কখনো বলে না উত্তর কোন দিকে যায়। টানেল যে পিয়ার পরিসর বহন করে তার পাশে ল্যান গেটওয়ের ফেরার পথ লিখুন, এবং রেকর্ডটি ব্যাখ্যা করে দূরবর্তী সাবনেট যা অনুরোধ পায় অথচ চুপ থাকে। নিচের পরীক্ষাগুলো বাক্সে চালান এবং এন্ট্রির সঙ্গে মিলিয়ে দেখুন। ip -6 route-এর সঙ্গে অমিল থাকা পরিকল্পনা এমন পরিকল্পনা যা মানুষ পড়া বন্ধ করে দেয়।

ip -6 route show default
ip -6 route get 2001:db8:2::10
ip -6 addr show dev wg0

পৌঁছানো মানেই অনুমতি নয়, এবং প্রিফিক্স কখনো নীতি বোঝায় না। যে রুটে প্রযোজ্য তার পাশে অভিপ্রেত প্রবেশাধিকার লিখুন। নইলে পরের পাঠক পরিকল্পনার একটি ঠিকানাকে তার পেছনের প্রতিটি পরিষেবায় পৌঁছানোর অনুমতি ভাবেন।

তৃতীয় সাইট পর্যন্ত পরিকল্পনা কীভাবে টেকে

প্রতিটি প্রিফিক্সকে প্রতিনিধিত্বপ্রাপ্ত, স্থানীয়ভাবে বরাদ্দকৃত বা অন্য উপায়ে রুট করা হিসেবে চিহ্নিত করুন। যা সরতে পারে তার জন্য সরানোর প্রক্রিয়ার নাম দিন। তারপর একই সময়ে বদলাতে হবে এমন DNS রেকর্ড ও ফায়ারওয়াল নিয়ম তালিকা করুন, কারণ রাউটারে থেমে যাওয়া প্রিফিক্স হালনাগাদ অর্ধেক কাজ।

পরিবর্তনের পর নথি সম্পাদনার আগে পরিবর্তন যে সীমা স্পর্শ করেছে তার পেছনের প্রতিটি সম্পদে পৌঁছান। গত মাসের নেটওয়ার্ক বর্ণনা করা পরিকল্পনা কিছু না থাকার চেয়েও খারাপ, কারণ মানুষ তাতে ভরসা করে। প্রত্যাহৃত বরাদ্দ তারিখসহ তালিকায় রাখুন যাতে কেউ ভুলে আবার ইস্যু না করে। গোপনীয়তা ফাইলের বাইরে থাকে; পরিকল্পনা নেটওয়ার্ক ব্যাখ্যা করে, খোলে না।

পরিবর্তন পর্যালোচনা হয় এমন জায়গায়, যে কনফিগারেশন বর্ণনা করে তার পাশে পরিকল্পনা রাখুন। যে নথি কেউ আবার পড়ে না তা যে নেটওয়ার্কের মানচিত্র দেয় তার চেয়ে দ্রুত পচে যায়।

সম্পর্কিত নিবন্ধ