دو سائٹس، ایک سب نیٹ، ایک WireGuard ہب: اسے کام کرائیں

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

اوورلیپ اصل مسئلہ کیوں نہیں ہے

WireGuard منزل کے مطابق آگے بھیجتا ہے: ایک peer کے AllowedIPs طے کرتے ہیں کہ کون سا peer پیکٹ لے گا۔ دو peer ایک ساتھ 10.10.7.0/24 کا اعلان نہیں کر سکتے، جب تک ان میں سے ایک ہر تلاش نہ جیتے۔ یہ peer جدول کی خصوصیت ہے، ٹنل کی نہیں، اسی لیے یہاں حل پتہ منصوبہ ہے، روٹنگ کی ترکیب نہیں۔

منصوبہ یہ ہے کہ LAN کا اعلان بالکل بند کر دیا جائے۔ اس کے بجائے ہر سروس کے لیے alias کا اعلان کریں، ہر سائٹ کے لیے ایک پتہ، اور ہر سائٹ کا گیٹ وے اس alias کو اپنی اصل ایپلیکیشن میں ترجمہ کرے۔

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

ہر سائٹ کو وہ alias دیں جو صارف روٹ کر سکے

ایسی رینج سے پتے چنیں جو صارف کی مشین، ہب یا دونوں LAN میں سے کسی بھی چیز سے نہ ٹکرائیں۔ یہاں ہب 10.66.0.1 ہے، صارف 10.66.0.10، گیٹ وے 10.66.0.21 اور 10.66.0.22، اور دو alias 10.77.1.20 اور 10.77.2.20 ہیں۔ ہب ہر alias کو اُس peer کے ذریعے شائع کرتا ہے جو اس کا مالک ہے، اس لیے ایک alias کی طرف بھیجا گیا باہر جانے والا پیکٹ صرف مماثل سائٹ سے ہی نکل سکتا ہے:

[Interface]
Address = 10.66.0.1/32
ListenPort = 51820
PrivateKey = HUB_KEY

[Peer]
PublicKey = USER_PUBLIC_KEY
AllowedIPs = 10.66.0.10/32

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
AllowedIPs = 10.66.0.21/32, 10.77.1.20/32

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
AllowedIPs = 10.66.0.22/32, 10.77.2.20/32

صارف کی طرف صرف دو alias درکار ہیں، جو کلائنٹ کنفیگریشن کو دونوں LAN سابقوں سے آزاد رکھتا ہے۔ اُس کنفیگریشن میں کچھ بھی کسی حقیقی LAN کا ذکر نہیں کرتا:

[Interface]
Address = 10.66.0.10/32
PrivateKey = USER_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub.example.net:51820
AllowedIPs = 10.77.1.20/32, 10.77.2.20/32
PersistentKeepalive = 25

ہر گیٹ وے ہب اور صارف کے ماخذ کا اعلان کرتا ہے، اور کچھ نہیں، اس لیے ایک سائٹ کبھی دوسری سائٹ کا LAN نہیں جانتی۔ Keepalive سائٹ کے اپ لنک پر NAT میپنگ برقرار رکھتا ہے؛ یہ ٹریفک کی اجازت نہیں دیتا، اور فائر وال اب بھی طے کرتا ہے کہ کیا قبول ہوگا۔ ایک گیٹ وے کی کنفیگریشن دوسرے میں کاپی کرنا ٹھیک ہے بشرطیکہ نجی کلید، انٹرفیس پتہ اور alias سب بدلیں۔

ہب کو اپنے دو peer کے درمیان کیا اجازت دینی چاہیے

ہب اپنے ہی دو peer کے درمیان پیکٹ آگے بھیجتا ہے، جو forward زنجیر کا فیصلہ ہے، ان پٹ فیصلہ نہیں۔ پلیٹ فارم کے معمول کے طریقے سے IPv4 فارورڈنگ فعال کریں، پھر صرف اُن جوڑوں کو اجازت دیں جن کی ڈیزائن کو ضرورت ہے۔

نیچے دیا گیا قاعدہ صارف کو ایک alias اور ایک پورٹ کی اجازت دیتا ہے، اور کنکشن ٹریکنگ کے ذریعے واپسی ٹریفک کی اجازت دیتا ہے۔ یہ forward راستے میں باقی سب چھوڑ دیتا ہے، اور یہی بات ہے:

nft add table inet hub_transit
nft add chain inet hub_transit forward '{ type filter hook forward priority 0 ; policy drop ; }'
nft add rule inet hub_transit forward ct state established,related accept
nft add rule inet hub_transit forward iifname wg0 oifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 accept

دو تفصیلیں قابل ذکر ہیں کیونکہ وہ خاموش ناکامیاں پیدا کرتی ہیں۔ ایک بنیادی زنجیر میں accept دوسری میں drop کو منسوخ نہیں کرتا، اس لیے اسے موجودہ پالیسی کے ساتھ ملائیں، اس کے ساتھ لوڈ نہ کریں۔ اور ماخذ پتہ شخص کی نہیں، ڈیوائس کی شناخت کرتا ہے؛ ایپلیکیشن کی توثیق کو نیٹ ورک کی اجازت سے الگ رکھیں۔

جہاں alias حقیقی پتہ بنتا ہے

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

nft add table ip site_a_nat
nft add chain ip site_a_nat pre '{ type nat hook prerouting priority -100 ; policy accept ; }'
nft add chain ip site_a_nat post '{ type nat hook postrouting priority 100 ; policy accept ; }'
nft add rule ip site_a_nat pre iifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 dnat to 10.10.7.20:443
nft add rule ip site_a_nat post iifname wg0 oifname lan0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.10.7.20 snat to 10.10.7.2

پھر سائٹ A کی forward پالیسی کو ترجمہ شدہ بہاؤ ٹنل انٹرفیس سے LAN انٹرفیس تک، اور واپسی سمت بھی اجازت دینی چاہیے۔ forward hook منزل کو منزل کے ترجمے کے بعد اور ماخذ کی دوبارہ تحریر سے پہلے دیکھتا ہے، اسی لیے قاعدہ اصل ایپلیکیشن کا پتہ بتاتا ہے۔ جب بھی کوئی قاعدہ کسی چیز سے نہ ملتا لگے، وہ دونوں hook اسی ترتیب سے پڑھیں۔ alias کے خلاف لکھا گیا forward قاعدہ کبھی نہیں مل سکتا، کیونکہ اُس hook پر alias اب موجود نہیں۔

سائٹ B اسے اپنے alias اور اپنی کلید کے ساتھ دہراتی ہے۔ اسے سائٹ A کی نجی کلید دوبارہ استعمال نہیں کرنی چاہیے، کیونکہ دو peer کا ایک شناخت ساجھا کرنا کنفیگریشن کی غلطی ہے جسے دیکھنا مشکل اور فائل کاپی کر کے بنانا آسان ہے۔ دونوں گیٹ وے دستاویزات کو مختلف ہونے والی قدروں کے سوا یکساں رکھیں، تاکہ جائزے میں فرق نمایاں ہو۔ کاپی کی گئی فائل اُس نقص کا عام ماخذ ہے۔

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

دونوں شائع شدہ نام جواب دیتے ہیں یہ کیسے ثابت کریں

ہر alias کو DNS نام دیں اور اُس نام کے لیے ایپلیکیشن اور سرٹیفکیٹ کنفیگر کریں، کیونکہ ترجمہ ری ڈائریکٹ یا ایمبیڈ شدہ مطلق URL دوبارہ نہیں لکھتا۔ ہر سائٹ کے لیے ایک نام استعمال کریں تاکہ سرٹیفکیٹ کی عدم مطابقت کبھی روٹنگ خرابی نہ سمجھی جائے۔

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

wg show wg0 allowed-ips
sudo nft list ruleset
curl -sS -o /dev/null -w "%{http_code}\n" https://site-a.example.net/

پہلے حکم میں خالی یا غیر متوقع alias کا مطلب ہے کہ کسی بھی فائر وال قاعدے کے اہم ہونے سے پہلے peer کا انتخاب غلط ہے۔ اگر alias درست ہے اور نام پھر بھی ناکام ہوتا ہے، تو مسئلہ DNS اور سرٹیفکیٹ تک منتقل ہو گیا ہے۔ جب دونوں نام جواب دیں اور تیسرا پورٹ بند رہے، تو ڈیزائن وہی کرتا ہے جو وہ دعویٰ کرتا ہے: تنگ طور پر شائع شدہ دو سروسز، ملی ہوئی دو LAN نہیں۔