دو سائٹ WireGuard ہب کے لیے IPv6 منصوبہ بندی: سابقہ، ساتھی، راستے
دو LAN کے لیے ایک نجی IPv6 ہب پر کام کریں: سابقہ منتخب کریں، ٹنل پتے محفوظ کریں، پھر AllowedIPs کو بتانے دیں کہ کون سا ساتھی کون سی ذیلی نیٹ کا مالک ہے۔
دو LAN، ایک WireGuard ہب اور ایک IPv6 پتہ منصوبہ جسے تین الگ سوالات کے جواب دینے ہیں: کون سا سابقہ، کون سا پتہ کس راؤٹر کا ہے، اور کون سا ساتھی کون سی ذیلی نیٹ کا مالک ہے۔ ان میں سے ایک بھی غلط ہو تو ایسی ٹنل بنتی ہے جو ہاتھ ملاتی ہے مگر کچھ راستہ نہیں دیتی۔ نیچے دیا گیا منصوبہ اسی ترتیب سے نجی دو سائٹ ڈیزائن پر چلتا ہے۔ یہ جان بوجھ کر IPv6 انٹرنیٹ رسائی نہیں دیتا۔
فیصلہ کریں کہ سابقہ کس لیے ہے
جب مقصد سائٹوں کے درمیان نجی رسائی ہو تو fd00::/8 سے منفرد مقامی سابقہ قدرتی انتخاب ہے۔ ہر جگہ کو کون سا ISP سروس دیتا ہے اس سے قطع نظر یہ مستحکم رہتا ہے اور عالمی روٹنگ جدول میں اعلان نہیں ہوتا، اس لیے آپ کی اندرونی نمبرنگ انٹرنیٹ پر نہیں بہہ سکتی۔
یہی خصوصیت حد ہے۔ ULA کوئی عوامی واپسی راستہ نہیں دیتا، کیونکہ کسی بالائی فراہم کنندہ کو معلوم نہیں کہ اسے آپ کے گیٹ وے کی طرف روٹ کرنا ہے۔ اگر ضرورت میں IPv6 انٹرنیٹ اخراج شامل ہو تو آپ کو ضرورت ہے ایسی فراہم کنندہ سے تخصیص جو اسے آپ تک روٹ کرتا ہے، اور یہ اپنے سابقہ سائز کے ساتھ الگ ڈیزائن فیصلہ ہے۔
یہ نہ سمجھیں کہ ہر تعیناتی کو /48 درکار ہے۔ RFC 6177 اختتامی سائٹ کے ایک لازمی سائز سے دور ہوا، اور درست سائز ان نیٹ ورکس کی تعداد پر منحصر ہے جو آپ چلائیں گے۔ ULA کو RFC 4193 طریقہ کار سے بنائیں، بجائے ایسا سابقہ ایجاد کرنے کے جو کوئی دوسری تنظیم بھی استعمال کر سکے۔ کسی بھی آلے کی ترتیب سے پہلے نتیجہ پتہ منصوبے میں لکھیں، کیونکہ جس سابقہ کو کسی نے درج نہ کیا وہ سابقہ ہے جسے کوئی دوبارہ استعمال کرے گا۔
سابقہ کو کرداروں میں تقسیم کریں
نیچے کی مثال fd7c:2e91:4a00::/48 استعمال کرتی ہے، اور جدول سائٹ کے بجائے اس بنیاد پر ترتیب دیا گیا ہے کہ ہر بلاک کہاں لکھا جاتا ہے۔ اقدار کو نمونہ سمجھیں اور کچھ بھی تعینات کرنے سے پہلے اپنی بنائیں۔
| Where it is written | What appears there | Block used | What it establishes |
|---|---|---|---|
| Hub wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::1/128 | The hub's own tunnel identity |
| Hub wg0.conf, Site A peer | Two ranges in one AllowedIPs line | ::2/128 and :10::/64 | That A owns its tunnel address and its LAN |
| Hub wg0.conf, Site B peer | Two ranges in one AllowedIPs line | ::3/128 and :20::/64 | That B owns its tunnel address and its LAN |
| Site A wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::2/128 | A's identity as the hub sees it |
| Site B wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::3/128 | B's identity as the hub sees it |
LAN بلاک /64 ہیں کیونکہ عام SLAAC 64 بٹ انٹرفیس شناخت کنندہ کی توقع کرتا ہے۔ LAN کو چھوٹے بلاک میں تقسیم کرنا زیادہ تر میزبانوں پر یہ مفروضہ توڑ دیتا ہے، اور نجی منصوبے میں پتوں کی بچت کے لیے آپریشنل لاگت مناسب نہیں۔ دونوں LAN بلاک /48 کے وسط سے آتے ہیں، جس سے نچلی رینج بعد کی سائٹوں کے لیے خالی رہتی ہے۔
ٹنل پتے انتظامی ذخیرہ ہیں، لنک پر نیٹ ورک نہیں۔ ہر انٹرفیس اس سے ایک /128 لیتا ہے، اس لیے کوئی میزبان ٹنل پر مشترکہ ذیلی نیٹ فرض نہیں کرتا اور جہاں ضرورت نہ ہو وہاں ہمسایہ دریافت نہیں چلتی۔ کردار الگ رکھیں اور تنظیم کے پتہ منصوبے میں درج کریں تاکہ بعد کی سائٹ بلاک دوبارہ استعمال نہ کرے۔
ہر راؤٹر کو ایک ٹنل پتہ دیں
ہر راؤٹر کے لیے ایک /128 مختص کریں اور کام کرنے والے ہب کی موجودہ کلیدیں اور اختتامی نقاط رکھیں۔ نیچے کی تین اقدار صرف میزبان حصے میں مختلف ہیں۔
Hub: Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128
یہ /128 اسی انٹرفیس کو مختص واحد پتہ بیان کرتا ہے۔ یہ نہیں بتاتا کہ ساتھی کتنے منزلوں تک راستہ دے سکتا ہے، کیونکہ رسائی انٹرفیس سابقہ میں نہیں بلکہ AllowedIPs میں ظاہر ہوتی ہے۔
ہر سائٹ راؤٹر کو اپنے LAN بلاک میں پتہ اور اسے تقسیم کرنے کا طریقہ بھی درکار ہے، عام طور پر SLAAC کے لیے راؤٹر اعلانات۔ WireGuard وہ اعلانات آپ کی طرف سے نہیں بھیجتا اور دو LAN کو پل نہیں کرتا۔ سائٹ راؤٹر دونوں سمتوں میں راؤٹر ہے۔
ذیلی نیٹ کی ملکیت AllowedIPs میں رکھیں
سائٹ A کے لیے ہب کا ساتھی اندراج A کے ٹنل پتے اور A کے LAN کا مالک ہے، اور یہی جوڑی پورا ملکیت بیان ہے۔ اس ساتھی حصے میں اور کچھ بھی سائٹ کو بیان کرنے کی ضرورت نہیں۔
AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64
سائٹ B کا ساتھی اندراج ملتی جلتی جوڑی کا مالک ہے، اور یہاں توازن اختصار سے زیادہ اہم ہے۔ دونوں سطریں ساتھ پڑھیں اور ملکیت کی تقسیم ایک نظر میں نظر آتی ہے۔
AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64
یہ دو الگ ساتھی حصے ہیں، ایک ساتھی کے لیے مقابلہ کرنے والی دو فہرستیں نہیں۔ WireGuard AllowedIPs کو دونوں سمتوں میں استعمال کرتا ہے: باہر جانے والی منزل کے لیے ساتھی منتخب کرتا ہے، اور ایسے آنے والے پیکٹ کو مسترد کرتا ہے جس کا ماخذ اس ساتھی کو مختص رینج سے میل نہیں کھاتا جس نے اسے ڈکرپٹ کیا۔ دونوں ساتھیوں کو پورا /48 دینا اس دوسری جانچ کو بند کر دیتا اور یہ دھندلا دیتا کہ کون سی سائٹ کس بلاک کی مالک ہے۔ یہی فرق غلط ماخذ پتے کو خاموشی سے قبول ہونے کے بجائے نظر آنے والا بناتا ہے۔
ہر سائٹ کو صرف وہ منزلیں درکار ہیں جو اس کے ہب ساتھی کے ذریعے قابل رسائی ہوں: سائٹ A ہب کا پتہ، سائٹ B کا ٹنل پتہ اور B کا LAN درج کرتی ہے، اور سائٹ B الٹا مجموعہ درج کرتی ہے۔ فہرستیں جان بوجھ کر غیر متوازن ہیں، کیونکہ ہر راؤٹر ٹوپولوجی کا الگ پہلو دیکھتا ہے۔ دونوں کو پتہ منصوبے سے لکھیں، دوسری سائٹ کی ترتیب سے نہیں، کیونکہ اسی طرح پرانی رینج دوبارہ نمبرنگ سے بچ جاتی ہے۔
wg-quick کے ساتھ یہ رینجیں راستے بھی بناتی ہیں۔ systemd-networkd یا دستی ترتیب میں مساوی راستے خود شامل کریں؛ ورنہ ٹنل ایسے پیکٹ لے جاتی ہے جو کرنل کبھی اس میں نہیں بھیجتا۔
فارورڈنگ مکمل کریں اور دونوں سمتیں جانچیں
ہب پر اور دونوں سائٹ راؤٹروں پر IPv6 فارورڈنگ فعال کریں، اور فارورڈ پالیسی میں ضروری بین السائٹ خدمات کی اجازت دیں۔ ICMPv6 Packet Too Big پیغامات قابل استعمال رکھیں، کیونکہ انہیں پھینکنے سے راستہ MTU دریافت ٹوٹ جاتی ہے اور بڑی منتقلیوں میں ایسی رکاوٹیں پیدا ہوتی ہیں جو ایپلیکیشن خرابی جیسی لگتی ہیں۔ فائر وال اجازت کے بغیر فارورڈ کرنے والا ہب پیکٹ کو روٹنگ اور ٹنل کے درمیان پھینک دیتا ہے۔ یہ ناکامی کی حالت جاننے کے قابل ہے، کیونکہ ٹنل چلتی رہتی ہے اور صرف چند بہاؤ مرتے ہیں۔
sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1
سائٹ A کے میزبان سے سائٹ B کے میزبان تک اور پھر الٹی سمت میں جانچیں۔ ہب کے ٹنل پتے پر ping صرف پہلی چھلانگ جانچتا ہے اور LAN راستے غلط ہونے پر بھی کامیاب ہوگا۔ منصوبہ میزبان سے میزبان بہاؤ ہی ثابت کرتا ہے۔
بیرونی WireGuard کنکشن IPv4 پر چل سکتا ہے جبکہ اندرونی ٹریفک IPv6 ہو، اور یہ آزادی منتقلی کے دوران مفید ہے۔ اگر بعد میں عالمی IPv6 اخراج شامل کیا جائے تو فراہم کنندہ کی تخصیص، ماخذ پتہ انتخاب اور واپسی روٹنگ کو نئے ڈیزائن مرحلے کے طور پر دوبارہ دیکھیں؛ اوپر کا نجی منصوبہ سائٹ سے سائٹ ٹریفک کے لیے درست رہتا ہے۔