Nebula লাইটহাউস ফিল্টার বনাম ফায়ারওয়াল: কোনটি কী আটকায়

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

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

নোড যে লোকাল ঠিকানা ঘোষণা করে সেখান থেকে শুরু করুন

local_allow_list লাইটহাউসে রিপোর্ট করার আগে এই হোস্টের লোকাল ঠিকানাগুলো ফিল্টার করে। এন্ট্রিগুলো ঠিকানা রেঞ্জ হতে পারে, এবং কনফিগারেশন ইন্টারফেস-নাম প্যাটার্নও সমর্থন করে। এটি তখন কাজে লাগে যখন হোস্টে কন্টেইনার ব্রিজ বা অতিরিক্ত টানেল ইন্টারফেস থাকে যা পিয়ার এন্ডপয়েন্ট হওয়া উচিত নয়।

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

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

তারপর দূরবর্তী এন্ডপয়েন্ট নির্বাচন দেখুন

remote_allow_list হ্যান্ডশেকের সময় এই হোস্ট দূরবর্তী পিয়ারের জন্য যে ঠিকানাগুলো বিবেচনা করবে সেগুলো ফিল্টার করে। এটি আন্ডারলে ঠিকানায় প্রযোজ্য, টানেল ওঠার পর পিয়ার যে ওভারলে ঠিকানা ব্যবহার করবে তাতে নয়।

একটি প্রাইভেট রেঞ্জ শেয়ার্ড অফিস নেটওয়ার্কে পুরোপুরি ব্যবহারযোগ্য হতে পারে এবং অর্থহীন হয়ে যায় যখন দুটি হোস্ট এমন অসংযুক্ত নেটওয়ার্কে থাকে যারা দুটোই 10.0.0.0/8 ব্যবহার করে। ফিল্টার আপনাকে রাউটযোগ্য পথ পছন্দ করতে এবং কাকতালীয়তা উপেক্ষা করতে দেয়।

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

ঘোষণার দিকের একটি ইন্টারফেস-নাম ফিল্টার গ্রহণকারী দিক এটি দেখার আগেই এন্ডপয়েন্ট সরিয়ে দিতে পারে। কেবল একটি দিক ব্যর্থ হলে দুটি নোডই পরীক্ষা করুন।

হ্যান্ডশেকের পর ওভারলে অ্যাক্সেস নিয়ম প্রযোজ্য হয়

Nebula ফায়ারওয়াল নিয়ম ওভারলের ভিতরে, টানেল প্রতিষ্ঠার পর কাজ করে। এগুলো হোস্ট, গ্রুপ, পোর্ট ও প্রোটোকল মেলায় এবং নির্ধারণ করে প্যাকেট লোকাল হোস্টে ঢুকতে বা বের হতে পারবে কি না। এগুলো আন্ডারলে এন্ডপয়েন্ট নির্বাচন করে না।

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

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

অনুমোদন ও নিষেধ মেশানোর সময় ডিফল্ট পড়ুন

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

lighthouse:
  local_allow_list:
    interfaces:
      docker0: false
  remote_allow_list:
    192.168.0.0/16: true
    default: false

ডিফল্টকে নিয়মের অংশ হিসেবে দেখুন, বয়লারপ্লেট হিসেবে নয়। যদি পরিবারের ডিফল্ট নিষেধ হয়, তালিকায় না থাকা প্রতিটি ঠিকানা বাদ পড়ে, এমনকি কনফিগারেশন লেখার পরে যোগ করা নতুন অফিস রেঞ্জও।

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

সরাসরি এন্ডপয়েন্টে পৌঁছানো না গেলে রিলে ব্যবহার করুন

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

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

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