WireGuard 5G برانچ: برانچ خود ہب کو کال کرے

برانچ کو ہب کی طرف موڑنا اس ڈیزائن کا آسان نصف ہے، جب برانچ بدلتے ہوئے موبائل پتے کے پیچھے ہو اور ہب کے پاس مستحکم نام ہو۔ تب ہب برانچ کو تصدیق شدہ ٹریفک سے سیکھتا ہے، ایسے ریکارڈ سے نہیں جسے آپ اپ ڈیٹ رکھنا پڑے۔ معاہدہ سادہ ہے: برانچ ہمیشہ شروع کرتی ہے۔

اسے جان بوجھ کر ترتیب دیں اور پھر اس حصے کی تصدیق کریں جسے لوگ کام کرتا سمجھتے ہیں۔ دونوں مراحل میں منٹ لگتے ہیں، اور یہ ڈیزائن عام طور پر دوسرے میں ناکام ہوتے ہیں۔

کون سا فریق مستحکم اینڈ پوائنٹ رکھتا ہے

برانچ کی ترتیب ہب کے اینڈ پوائنٹ اور اس کی عوامی کلید کا نام لیتی ہے۔ ہب کی ترتیب برانچ کی عوامی کلید اور اس کے اجازت یافتہ اندرونی سابقوں کا نام لیتی ہے، اور اس میں کوئی اینڈ پوائنٹ بالکل نہ بھی ہو، کیونکہ شناخت کلید سے آتی ہے، آخری پیکٹ کے ماخذ پتے سے نہیں۔ یہی عدم توازن پورا طریقہ کار ہے، اور یہ ہب کی طرف سے دریافت کے مسائل کی پوری قسم ہٹا دیتا ہے۔

جب برانچ تصدیق شدہ پیکٹ بھیجتی ہے تو ہب اس ماخذ کو درج کرتا ہے جہاں سے وہ آیا اور جوابات کے لیے وہی نقشہ استعمال کرتا ہے۔ پھر موبائل لنک کی دوبارہ نمبرنگ اگلے ہینڈ شیک کے سوا کچھ خرچ نہیں کرتی، اور اب جس جزو کی ضرورت نہیں وہ ایسا ہے جو تبدیلی کے دوران ناکام نہیں ہو سکتا۔ یہ خاصیت منصوبہ بند تبدیلی کے دوران جانچنے کے قابل ہے، واقعے کے دوران نہیں۔ یہ اس وقت کریں جب کوئی دونوں سرے ایک ساتھ دیکھ سکے۔

برانچ کو ایسی ترتیب دیں جو دوبارہ نمبرنگ برداشت کرے

اینڈ پوائنٹ اور keepalive برانچ پر رکھیں، اور ہب کے پیر اندراج کو سخت کوڈ شدہ پتے سے پاک رکھیں۔ keepalive ترجمہ شدہ نقشے کو اتنی دیر کھلا رکھتا ہے کہ ہب غیر فعال مدت کے بعد بلا طلب ٹریفک بھیج سکے۔

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

پچیس سیکنڈ NAT نقشے کو زندہ رکھنے کی اکثر دی جانے والی مثال ہے، ہر پیر کے لیے لازم نہیں۔ اسے اسی نقشہ ٹائم آؤٹ کے مطابق مقرر کریں جو آپ واقعی دیکھتے ہیں، اور یاد رکھیں کہ جب تک انٹرفیس آن ہے یہ ڈیٹا محدود لنک پر ٹریفک پیدا کرتا ہے۔

ہب پر، برانچ کے پیر کے اجازت یافتہ سابقوں کو وہ سب ڈھانپنا چاہیے جو برانچ بھیجے گی۔ غائب سابقہ دور کے سرے پر روٹنگ ناکامی کی طرح برتاؤ کرتا ہے اور کسی بھی طرف کوئی انتباہ پیدا نہیں کرتا، اس لیے پہلے حقیقی پیکٹ سے پہلے اس کا جائزہ لینا مناسب ہے۔ پہلے کنکشن سے پہلے ہب کے اجازت یافتہ سابقوں کا برانچ کے انٹرفیس پتوں سے موازنہ کریں۔

نقشے اور فیل اوور کی تصدیق کریں

تصدیق کریں کہ ہینڈ شیک مکمل ہوتا ہے، ہب برانچ کا موجودہ اینڈ پوائنٹ درج کرتا ہے، اور ٹنل کے ذریعے برانچ کے اندرونی پتے قابل رسائی ہیں۔ یہی بنیادی لکیر ہے، اور کسی کے موبائل لنک کو چھونے سے پہلے اسے درج کرنا چاہیے۔ دو سطروں کی آؤٹ پٹ کافی ہے۔ وقت کی مہر کے ساتھ انہیں ٹکٹ میں رکھیں۔

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

پھر وہ ناکامی آزمائیں جس کے لیے یہ ڈیزائن ہے۔ بنیادی WAN کھینچ کر نکالیں اور تصدیق کریں کہ ہب کی طرف برانچ کا بنیادی راستہ اب موبائل انٹرفیس سے نکلتا ہے۔ ٹنل ٹوٹا ہوا طبعی راستہ ٹھیک نہیں کر سکتا، اس لیے مردہ اپ لنک کی طرف اب بھی اشارہ کرنے والا بیرونی راستہ ہینڈ شیک ٹائم آؤٹ پیدا کرتا ہے جو بالکل ہب کے مسئلے جیسا لگتا ہے۔

اگر بیرونی راستہ واضح طور پر بندھا ہوا یا پالیسی سے روٹ شدہ ہے تو فیل اوور میں اسے شامل کرنا ہوگا۔ درست پڑھے جانے والے ڈیزائن اور خلل برداشت کرنے والے ڈیزائن کے درمیان یہی خلا عام طور پر واحد غائب چیز ہوتا ہے۔

یہ ڈیزائن کیا حل نہیں کرتا

یہاں کچھ بھی برانچ کی طرف آنے والے کنکشن کی اجازت نہیں دیتا۔ اگر ہیڈ کوارٹر میں کسی چیز کو موبائل سائٹ کال کرنی ہو تو اس ضرورت کے لیے ٹنل کی سمت غلط ہے، اور متحرک DNS صرف نام اپ ڈیٹ کرتا ہے۔ فراہم کنندہ کا ترجمہ، آنے والی پالیسی اور کلائنٹ کا اینڈ پوائنٹ ریفریش سب راستے میں رہتے ہیں، اور بدلا ہوا ریکارڈ آپریٹر گریڈ NAT نہیں کھول سکتا۔

برانچ کے سابقے کو ہر دوسری سائٹ سے الگ رکھیں، اور محدود کریں کہ اس کا گیٹ وے کیا آگے بھیجے گا۔ مستحکم ہب اینڈ پوائنٹ دریافت کو آسان بناتا ہے اور روٹنگ ڈیزائن، پتہ منصوبہ بندی یا اس سوال کے لیے کچھ نہیں کرتا کہ کون سے ایپلیکیشن راستے فیل اوور برداشت کرتے ہیں۔

رن بک میں چار باتیں لکھیں: کون شروع کرتا ہے، کون سے سابقے اجازت یافتہ ہیں، keepalive کتنا طویل ہے، اور بنیادی لنک گرنے پر کیا ہوتا ہے۔ مستقبل کے آپریٹر کو رات تین بجے واقعی جن سطروں کی ضرورت ہوتی ہے وہی یہ ہیں۔