NetBird-এ দুটি LAN: কোন পিয়ার রাউট করে, আর কে কথা বলতে পারে
নথিভুক্তি কোনো LAN-কে রাউট করে না। প্রতি সাইটে একটি রাউটিং পিয়ার বাছুন, মাস্কারেডিং চালু রাখুন, নীতির পরিসর নির্ধারণ করুন, তারপর প্রতিটি LAN গেটওয়েকে পরবর্তী হপ শেখান।
পশ্চিম LAN-এর একটি ওয়ার্কস্টেশন ব্রাউজার খোলে, পূর্ব LAN-এর একটি অ্যাপ্লিকেশনের ঠিকানা লেখে এবং সময় শেষ হওয়া পর্যন্ত অপেক্ষা করে। NetBird-এর প্রতিটি স্ক্রিন বলে পিয়ারগুলো সংযুক্ত, যা সত্য কিন্তু মূল বিষয় নয়: একটি ওভারলে নেটওয়ার্কে থাকা আর দুটি স্থানীয় সাবনেটকে একটি নেটওয়ার্কে আনা এক নয়। নিচের হাঁটা ওই ওয়ার্কস্টেশন থেকে শুরু হয় এবং এমন একটি অনুরোধে শেষ হয় যা নকশা ইচ্ছাকৃতভাবে প্রত্যাখ্যান করে, আর প্রতিটি থামা এমন কিছু যা ডিভাইস থেকে পড়া যায়, অনুমান করা নয়। আশা করুন অনুপস্থিত অংশটি একটি রুট বা নীতি, ওভারলে নয়।
আগে ওয়ার্কস্টেশন থেকেই ব্যর্থতা পড়ুন
ম্যানেজমেন্ট কনসোল খোলার আগে নির্ধারণ করুন ওয়ার্কস্টেশন আসলে কী পাঠায়। তার নিজের রাউটিং টেবিল ঠিক করে প্যাকেটটি সাইট গেটওয়েতে যাবে, স্থানীয় ইন্টারফেসে যাবে, নাকি কোথাও যাবে না, এবং সেই সিদ্ধান্ত কোনো ওভারলে টুলিং ছাড়াই দেখা যায়। দূরের প্রিফিক্সের জন্য রুট নেই এমন মেশিন পিয়ার তালিকা যতই সুস্থ দেখাক, ব্যর্থ হবে। ওভারলে পরিসর আর সাইটের নিজের প্রিফিক্স আলাদা ঠিকানা-ক্ষেত্র, আর নথিভুক্তি তাদের একটিমাত্র কনফিগার করেছে।
এরপর নাম সমাধানকে পৌঁছানো থেকে আলাদা করুন, কারণ ব্রাউজার দুটোকেই একই টাইমআউট হিসেবে জানায়। NetBird ক্লায়েন্ট চালানো মেশিন থেকে, তারপর না-চালানো সাধারণ ওয়ার্কস্টেশন থেকে ঠিকানা দিয়ে অনুরোধটি পুনরাবৃত্তি করুন। নথিভুক্ত মেশিন সফল হয়ে সাধারণটি ব্যর্থ হলে ফাঁক স্থানীয় রাউটিংয়ে; দুটোই ব্যর্থ হলে রুট বদলানোর আগে পড়া চালিয়ে যান।
প্রতি সাইটে একটি রাউটিং পিয়ার বাছুন
রাউটিং পিয়ার হলো এমন হোস্ট যা ওভারলেতে নিজের LAN-এর প্রতিনিধিত্ব করে, তাই কারও ডেস্ক ওয়ার্কস্টেশনের বদলে সাবনেটে স্থির পৌঁছানো আছে এমন Linux মেশিন বাছুন। স্বাভাবিক প্রক্রিয়ায় এটি নথিভুক্ত করুন এবং ভূমিকার নামে একটি গ্রুপে রাখুন, কারণ নেটওয়ার্ক রিসোর্স আর নীতি দুটোই ওই গ্রুপকে নির্দেশ করবে। প্রতি সাইটে একজন প্রতিনিধি বোধগম্য থাকে; একই প্রিফিক্স ঘোষণা করা স্বেচ্ছাসেবকদের বহর প্রতিটি পরবর্তী প্রশ্নকে ডিবাগিং সেশনে বদলে দেয়। স্থানীয় সেগমেন্টে পিয়ারের ঠিকানা ওভারলে পরিচয়ের মতোই গুরুত্বপূর্ণ, কারণ সেই ঠিকানাই প্রতিটি সাধারণ ডিভাইসকে বলা পরবর্তী হপ হয়।
কনসোল ছোঁয়ার আগে পরিকল্পনা লিখে ফেলুন, কারণ নাম আর প্রিফিক্সই এসব নকশার গড়মিলের জায়গা: প্রিফিক্স, গেটওয়ে, পিয়ার ঠিকানা আর গ্রুপ, প্রতি সাইটে। পশ্চিম 10.52.0.0/24, সেবা দেয় 10.52.0.5, আর পূর্ব 10.63.0.0/24, সেবা দেয় 10.63.0.5; দুটি গ্রুপ west-routers আর east-routers, এবং কোনো প্রিফিক্স অন্যটির সঙ্গে, ওভারলে পরিসরের সঙ্গে বা অন্য কোনো রাউটেড গন্তব্যের সঙ্গে ওভারল্যাপ করতে পারবে না।
রিসোর্স তৈরি করুন, মাস্কারেডিং চালু রাখুন
স্থাপিত ড্যাশবোর্ডে প্রতি সাইটে একটি নেটওয়ার্ক রিসোর্স তৈরি করুন এবং সেই সাইটের রাউটিং-পিয়ার গ্রুপটি তার সঙ্গে যুক্ত করুন। রিসোর্স হলো প্রিফিক্স আর গ্রুপ হলো যে হোস্ট তার পক্ষে উত্তর দেয়, এবং কিছু ঘোষণার আগে দুটোকেই থাকতে হবে। নিশ্চিত করুন স্থাপিত স্ব-হোস্টেড সংস্করণে নেটওয়ার্কস ওয়ার্কফ্লো আদৌ আছে, কারণ একই রকম নামের রুট অবজেক্ট থাকা পুরোনো ইন্টারফেস ভিন্ন বৈশিষ্ট্য।
মাস্কারেডিং চালু রাখুন। NetBird-এর সাইট-থেকে-সাইট নির্দেশিকা এই বিন্যাসে এটি দাবি করে, আর প্রতিটি মূল ঠিকানা দৃশ্যমান রাখতে এটি বন্ধ করা এক হপ কম এমন একই নকশা নয়; এটি বদলে দেয় ওভারলের উৎস-পরীক্ষা ও নীতিগুলো কী দেখে। পরিণামটি সোজা বলে দেওয়া দরকার: গ্রহণকারী সেবা উৎস হিসেবে রাউটিং পিয়ার লিপিবদ্ধ করে, আলাদা ওয়ার্কস্টেশন নয়। সেই সেবার অনুমতি-তালিকা বা নিরীক্ষা ওয়ার্কস্টেশনের ঠিকানা আশা করলে হয় প্রত্যাশা বদলাতে হবে, নয়তো অনুবাদের আগে সাইট-সীমায় পরিচয় বলবৎ করতে হবে।
ক্ষমতা দিন সূচনাকারীদের, প্রিফিক্সগুলোকে নয়
রুট একটি ঠিকানাকে পৌঁছানোর যোগ্য করে, আর নীতি ঠিক করে কে তা ব্যবহার করতে পারবে; দুটি আলাদা মালিকের আলাদা অবজেক্ট। ওয়ার্কলোড থেকে পেছনে হেঁটে নীতি লিখুন: কোন গ্রুপ সূচনা করে, কোন রিসোর্স লক্ষ্য করে এবং কোন TCP সেবা দরকার। যে নেটওয়ার্ক প্রতিটি নথিভুক্ত পিয়ারকে দুটি প্রিফিক্সই ঘোষণা করে, সে পৌঁছানো তৈরি করেছে কিন্তু কিছুই মেটায়নি।
তারপর পড়ুন আর কী ইতিমধ্যে অনুমোদিত, কারণ সংকীর্ণ নতুন নিয়ম তার ওপরে থাকা প্রশস্ত পুরোনো নিয়ম বাতিল করে না। পূর্বকেও পশ্চিমে সংযোগ শুরু করতে হলে সেই দিকটি আলাদা নীতি হিসেবে লিখুন; পশ্চিমে খোলা সেশনের ফেরত ট্রাফিক পূর্বমুখী নতুন সেশন অনুমোদনের চেয়ে ভিন্ন প্রশ্ন। কেবল কিছু পশ্চিম ওয়ার্কস্টেশনের পূর্ব অ্যাপ্লিকেশনে পৌঁছানো দরকার হলে অনুবাদের আগে সাইট-সীমায় সেগুলো বাছুন এবং অ্যাপ্লিকেশনের নিজস্ব প্রমাণীকরণ যথাস্থানে রাখুন। রাউটিং পিয়ার LAN ট্রাফিককে প্রতি-ব্যবহারকারী ওভারলে পরিচয় হিসেবে নয়, গোটা সাইট হিসেবে বহন করে, তাই প্রতি-ব্যবহারকারী হিসাব অন্য কোথাও থেকে আসতে হবে।
প্রতিটি গেটওয়েকে পরবর্তী হপ শেখান, তারপর প্রত্যাখ্যান পরীক্ষা করুন
সাধারণ ডিভাইস ওভারলে কখনো দেখে না, তাই তাদের নিজের গেটওয়ের দরকার একটি স্ট্যাটিক রুট যা দূরের প্রিফিক্সকে রাউটিং পিয়ারের LAN ঠিকানায় পাঠায়। মানুষ এই ধাপটাই বাদ দেয়, কারণ NetBird-এর ভেতরে দৃশ্যমান সবকিছু ইতিমধ্যে কাজ করে, অথচ সাধারণ ওয়ার্কস্টেশন এখনো সময় শেষে ব্যর্থ হয়। গেটওয়ে তার ডিফল্ট রুট যেমন ছিল তেমনই রাখে; এই প্রিফিক্স সংযোজন, প্রতিস্থাপন নয়।
দুটি রুটের বর্ণনা প্রতিটি সাইটের নিজের গেটওয়ে কনফিগারেশনে থাকা উচিত, হোস্ট ওভাররাইডে নয়। দুটোই সাধারণ স্ট্যাটিক রুট, আর কোনোটিই ডিফল্ট রুট স্পর্শ করে না:
west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5প্রকল্পের সত্যিই প্রয়োজনীয় অ্যাপ্লিকেশন দিয়ে, সাধারণ ওয়ার্কস্টেশন থেকে পরীক্ষা করুন এবং তিনটি জিনিস লিখে রাখুন: পাঠানোর দিকে বেছে নেওয়া পরবর্তী হপ, যে নীতি মিলেছে, এবং সেবা যে উৎস-ঠিকানা লিপিবদ্ধ করেছে। প্রত্যাখ্যানও পরীক্ষা করুন, কারণ যে নকশা কখনো কিছু প্রত্যাখ্যান করেনি তার অজানা কিনারা আছে, আর প্রত্যাখ্যানই একমাত্র প্রমাণ যে রাউটিং নয়, নীতিই কাজটি করছে। পূর্বকেও সূচনা করতে হলে দ্বিতীয় দিকটি অনুসরণ করবে ধরে নেওয়ার বদলে সেই দিক থেকে নতুন সংযোগ শুরু করুন। রাউটিং পিয়ারের পুনরায় চালু, উন্নয়ন ও প্রতিস্থাপনেরও পরিকল্পনা করুন, কারণ একটি হোস্ট সাইটের নির্ভরতা হয়ে দাঁড়িয়েছে।
| Test | A pass looks like | A failure points at |
|---|---|---|
| Ordinary workstation opens the east application | Next hop on west is the routing peer | Missing static route on the west gateway |
| A source outside policy is refused | No session in the service log | Policy too broad, or a route bypasses it |
| East starts a connection, if required | A fresh reverse session succeeds | No policy for the reverse direction |
ব্যক্তিগত নামের নিজস্ব রিজলভার নকশা দরকার, কারণ পৌঁছানো DNS রেকর্ড তৈরি করে না, আর ভাঙা নামের সঙ্গে কাজ করা IP পথ হুবহু ভাঙা পথের মতোই পড়া যায়। রাউটিং পিয়ার কোনো ক্লাউড নেটওয়ার্কে চললে সরবরাহকারীর ফরওয়ার্ডিং ও ফায়ারওয়াল নিয়মও পর্যালোচনা করুন, কারণ নথিভুক্তি সেগুলো অগ্রাহ্য করে না। পরীক্ষার পর্যবেক্ষণ পরিকল্পনার পাশে রাখুন, কারণ পরে যে এটি ডিবাগ করবে সে টপোলজির বর্ণনা নয়, মিলে যাওয়া নীতি আর লিপিবদ্ধ উৎস-ঠিকানা চাইবে।