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 راستہ بالکل ٹوٹے راستے کی طرح پڑھا جاتا ہے۔ اگر روٹنگ ساتھی کسی کلاؤڈ نیٹ ورک میں چلتا ہے، تو فراہم کنندہ کے فارورڈنگ اور فائر وال قواعد بھی دیکھیں، کیونکہ رجسٹریشن انہیں منسوخ نہیں کرتی۔ جانچ کے مشاہدات منصوبے کے پاس رکھیں، کیونکہ آگے اسے ڈیبگ کرنے والے کو ٹوپولوجی کی تفصیل نہیں، ملی ہوئی پالیسی اور درج ماخذ پتہ چاہیے ہوگا۔