Nebula static_host_map: যে ঠিকানা বাতিঘর দিতে পারে না

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

দুই কাজে দুই ঠিকানা

প্রতিটি Nebula হোস্টের একটি ওভারলে ঠিকানা থাকে যা ডিভাইস নেটওয়ার্কের মধ্যে চলাচল করলেও স্থির থাকে। এই ঠিকানাটি সার্টিফিকেট, ফায়ারওয়াল নিয়ম ও পিয়ার সম্পর্কের ব্যবহৃত পরিচয়, এবং একা এটি কোথাও রুট করে না। পৌঁছানো যায় এমন এন্ডপয়েন্ট অন্য কিছু: অন্তর্নিহিত নেটওয়ার্কে একটি হোস্টনাম বা ঠিকানা এবং একটি UDP পোর্ট, এবং মেশিন স্থান বদলালে এটি বদলে যায়। স্থির মানচিত্র দুটির মধ্যে সংযোগ।

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

পরিচয় যায় সেখানে যেখানে পরিচয় প্রত্যাশিত। পৌঁছানোর ক্ষমতা যায় মানচিত্রে।

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

মানচিত্র এন্ট্রির গঠন

কী হলো উদ্ধৃতি চিহ্নে লেখা ওভারলে ঠিকানা, আর মান হলো এন্ডপয়েন্টের তালিকা, তাই এক পরিচয়ের একাধিক প্রবেশবিন্দু থাকতে পারে। প্রতিটি এন্ডপয়েন্টে একটি হোস্ট ও একটি পোর্ট থাকে, এবং পোর্টটি অপর পক্ষ আসলে যা শোনে তার সঙ্গে মিলতে হবে। Nebula-র ডিফল্ট হলো UDP 4242, যা একটি সূচনাবিন্দু, আপনার ডিপ্লয়মেন্ট সম্পর্কে কোনো প্রতিশ্রুতি নয়।

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

ভুল পোর্ট ত্রুটির বদলে নীরবতা দেয়, কারণ UDP-র প্রত্যাখ্যান করার কোনো হ্যান্ডশেক নেই। তাই এন্ট্রির বিন্যাস স্মৃতির বদলে Nebula-র static_host_map রেফারেন্স এর সঙ্গে মিলিয়ে দেখা উচিত। রেফারেন্সটি এন্ডপয়েন্ট তালিকা ও DNS রিফ্রেশ আচরণও কভার করে।

ওভারলের আগে বুটস্ট্র্যাপ কাজ করতে হবে

মানচিত্রের একটি DNS নাম যেকোনো টানেল থাকার আগে হোস্টের যে রিজলভার আছে তার মাধ্যমে সমাধান হতে হবে, অর্থাৎ সাধারণ সিস্টেম রিজলভার। একই মেশিন থেকে, বুটের সময়, ওভারলে বন্ধ রেখে এটি পরীক্ষা করুন। যে নাম কেবল ওভারলের নিজস্ব DNS দিয়ে সমাধান হয় তা ওভারলে বুটস্ট্র্যাপ করতে পারে না। একই পরীক্ষা রুটের ক্ষেত্রেও প্রযোজ্য: যে ফায়ারওয়াল নিয়ম ওভারলেকে অনুমতি দেয় কিন্তু প্রথম UDP বিনিময়কে নয়, তা প্রাথমিক প্যাকেট ব্লক করে।

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

স্থির এন্ট্রিগুলো সরাসরি ডায়াল হয় এবং কখনো বাতিঘরের সঙ্গে পরামর্শ করে না। তাই এখানে ব্যর্থতা কোনো পিয়ার ছাড়াই সাধারণ টাইমআউটের মতো দেখায়।

প্রথম হ্যান্ডশেকের পরে কী ঘটে

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

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

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

যখন আবিষ্কার কাজ করে আর একটি পিয়ার করে না

বাতিঘরগুলো পৌঁছানোযোগ্য হলে এবং বেশিরভাগ পিয়ার সংযুক্ত হলে বুটস্ট্র্যাপ সমস্যা নয়। বাকি জোড়াটি হয় একে অপরের কাছে ব্যবহারযোগ্য পথ খুঁজে পায় না, নয়তো পৌঁছানোর ক্ষমতার উপরে ব্যর্থ হয়। বাতিঘরের ঠিকানার আরেকটি বানান যোগ করলে কোনোটিই সারানো যায় না।

যে মানচিত্রের উপর বাকি সব কিছু ইতিমধ্যেই নির্ভর করে তা সম্পাদনার আগে জোড়াটি পরীক্ষা করুন। মানচিত্র পরিবর্তন প্রতিটি হোস্টকে বিরক্ত করে, তাই এটি সবার শেষে হাত দেওয়ার জিনিস, প্রথমে নয়।

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