Nebula রিলে কনফিগার করা হয়েছে কিন্তু অব্যবহৃত: যাচাই করার তিনটি সেটিংস

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

কনফিগ সম্পাদনার আগে তিনটি ভূমিকা মানচিত্রে বসান

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

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

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

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

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

মিশ্র ফ্লিটে ভার্সন লাইন গুরুত্বপূর্ণ। রিলে হ্যান্ডলিং, পাঞ্চিং আচরণ এবং গৃহীত কনফিগ কীগুলো রিলিজভেদে অভিন্ন নয়, তাই ধরে নেবেন না যে পুরোনো বিল্ড এমন একটি সেকশন বোঝে যার জন্য এটি লেখা হয়নি। হোস্টগুলোকে একই মাইনর সিরিজে আনুন, তারপর প্রতিটি হোস্টে nebula -test -config /etc/nebula/config.yml চালান এবং এমন ট্রান্সপোর্ট ডিবাগ করার আগে আউটপুট তুলনা করুন যা কোডটি বাস্তবায়ন করে না।

রিলে হোস্টে ফরোয়ার্ডিং ভূমিকা সক্রিয় করুন

রিলে ভূমিকা ফরোয়ার্ডিং হোস্টে একটি ফ্ল্যাগ, এবং এটি লাইটহাউস হওয়া থেকে আলাদা। ডিসকভারি সক্রিয় ও রিলে ফরোয়ার্ডিং নিষ্ক্রিয় থাকা হোস্ট এখনো কেবল একটি ডিসকভারি সার্ভিস। রিলেতে:

relay:
  am_relay: true

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

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

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

ক্লায়েন্ট থেকে নয়, গন্তব্য থেকে রিলে বিজ্ঞাপন করুন

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

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

পিয়াররা লাইটহাউসে চেক-ইন করার সময় তাদের ঠিকানার সঙ্গে ওই তালিকা রিপোর্ট করে, তাই বিজ্ঞাপন সরাসরি বিনিময়ের বদলে ডিসকভারির মাধ্যমে ছড়ায়। যদি গন্তব্য কোনো লাইটহাউসে পৌঁছাতে না পারে, তার রিলে তালিকা কখনো ছড়ায় না এবং সঠিকভাবে কনফিগার করা একটি রিলে নিষ্ক্রিয় থাকে। সেই ব্যর্থতা হুবহু ভাঙা রিলের মতো দেখায়, কিন্তু তা নয়।

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

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

সংযোগকারী পিয়ারকে রিলে ব্যবহার করতে দিন

উদ্যোগকারী পক্ষের নিজস্ব অনুমতি দরকার। relay.use_relays ডিফল্টভাবে চালু থাকে, তাই খোঁজার মতো কেস হলো স্পষ্ট false, যা প্রায়ই রিলে ফিচার তৈরির আগে লেখা টেমপ্লেট থেকে কপি করা বা সরাসরি পথ জোর করার আগের প্রচেষ্টা থেকে পড়ে থাকা:

relay:
  use_relays: true

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

NAT ট্রাভার্সাল সেটিংস এসবের সঙ্গে মিথস্ক্রিয়া করে। punchy.punch দুটি পিয়ারকে সরাসরি পথ খুলতে সাহায্য করে, এবং এটি সফল হলে পর্যবেক্ষণ করার মতো কোনো রিলে ট্রাফিক থাকে না; সেটি সফলতা, অনুপস্থিত রিলে নয়। যে জোড়া মাঝে মাঝে কাজ করে তার অর্থ সাধারণত পাঞ্চিং মাঝে মাঝে সফল হয়, তাই একবারের প্রচেষ্টা থেকে সিদ্ধান্ত না নিয়ে ওই জোড়া কয়েকবার পরীক্ষা করুন।

যে জোড়া ব্যর্থ হয়েছে তার সঙ্গে যাচাই করুন, তারপর রিলোড করুন

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

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

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

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload কেবল তখনই কাজ করে যখন স্থানীয় ইউনিট ExecReload সংজ্ঞায়িত করে, এবং প্রকল্পের সঙ্গে আসা ইউনিট তা করে না, তাই স্টক ইনস্টলে সফল হওয়া ধাপ হলো systemctl kill -s HUP। রিলোডের পর প্রসেস যে কনফিগ পথ খুলেছে তার জন্য জার্নাল পড়ুন, যাতে জানেন নতুন ফাইলটি পড়া হয়েছে, আপনি যে ফাইলটি ধরে নিয়েছিলেন সেটি নয়।

রিলে সেটিংস ও NAT পাঞ্চিং দুটোই পথে কাজ করে; কোনোটিই পরিচয়ে কাজ করে না। চলমান কনফিগে am_relay, relays এবং use_relays নিশ্চিত হওয়ার পরেও যদি জোড়ার হ্যান্ডশেক ব্যর্থ হয়, তবে যাচাই করুন যে দুটি হোস্টই যে নামে কনফিগার করা তাদের জন্য ইস্যু করা সার্টিফিকেট উপস্থাপন করে এবং দুই পাশে CA একই। সার্টিফিকেট ও ফায়ারওয়াল কনফিগ অপরিবর্তিত রাখুন, একবারে একটি ট্রান্সপোর্ট সেটিং বদলান, কারণ একই পরীক্ষায় পড়া সার্টিফিকেট সম্পাদনা ও রিলে সম্পাদনা আপনাকে বলে না কোনটি হ্যান্ডশেক সরিয়েছে। নাম বা CA মিল না হলে ঠিক সেখানেই ব্যর্থ হয় যেখানে কখনো খুঁজে পাওয়া যায়নি এমন রিলে ব্যর্থ হয়, তাই এই পাল্টা-যাচাই একই ধাপে প্রযোজ্য।

তারপর নিশ্চিত করুন প্রতিটি বিবৃতি তার নিজের ফাইলে আছে:

• ফরোয়ার্ডিং হোস্টে am_relay: true, এবং সেই হোস্ট দুই পাশ থেকে UDP-তে নাগালযোগ্য।
• গন্তব্যে সেই হোস্টের Nebula ঠিকানা উল্লেখ করে relays:।
• সংযোগ শুরু করা পিয়ারে use_relays: true।
• পথ বদলানোর পরেও গন্তব্যের ইনবাউন্ড নিয়ম আসল সোর্সকে অনুমতি দেয়।