سائٹ ٹو سائٹ VPN میں دوسرا سب نیٹ شامل کرنا: دو راستے
پالیسی پر مبنی ٹنل کو دونوں طرف ملتے جلتے سلیکٹر چاہیے؛ روٹ پر مبنی کو روٹ۔ درست راستہ چنیں اور پہلے واپسی کا روٹ درست کریں۔
چلتی ہوئی سائٹ ٹو سائٹ ٹنل میں دوسرا سب نیٹ شامل کرنے میں ایک ڈیزائن میں پانچ منٹ اور دوسرے میں تقریباً ساری دوپہر لگتی ہے۔ جب ٹنل آپ کے بتائے گئے سابقوں کے لیے روٹ نصب کرتی ہے تو آپ ایک روٹ شامل کرتے ہیں اور ٹریفک اسی کی پیروی کرتی ہے۔ جب وہ ایک مقررہ سلیکٹر جوڑے پر بات چیت کرتی ہے تو نیا سابقہ دونوں اطراف کے ملتے جلتے جوڑے پر متفق ہونے تک غیر محفوظ رہتا ہے۔ تین چیزیں فیصلہ کرتی ہیں: ہر طرف کی کنفیگریشن واقعی کیا بیان کرتی ہے، بات چیت شدہ ٹریفک چھوٹے سے چھوٹے ملتے جلتے جوڑے تک سمٹتی ہے یا نہیں، اور نئی رینج کا واپسی راستہ کس کا ہے۔
کرنل پڑھیں، حالت کا لیبل نہیں
جڑا ہوا بتانے والی ٹنل نے کم از کم ایک چائلڈ ایسوسی ایشن نصب کی ہے، لیکن ضروری نہیں کہ وہی جو آپ سوچتے ہیں۔ Linux میں کرنل دکھاتا ہے کہ کیا لاگو ہوتا ہے: ip xfrm policy سلیکٹر جوڑے گنتا ہے اور swanctl --list-sas (یا پرانا ipsec statusall) دکھاتا ہے کہ دونوں اطراف نے کیا طے کیا، ہر سمت کے ٹریفک سلیکٹرز سمیت۔ اگر نیا سابقہ دونوں میں نہ ہو تو کنفیگ فائل کچھ بھی کہے، وہ غیر محفوظ ہے۔
اسے روٹ ٹیبل سے موازنہ کریں۔ روٹ پر مبنی ترتیب میں ٹنل ڈیوائس محفوظ سابقوں کے لیے اگلا قدم ہے۔ پالیسی پر مبنی ترتیب میں دور دراز سب نیٹ کے لیے الگ روٹ اکثر نہیں ہوتا، صرف ڈیفالٹ روٹ، کیونکہ ٹریفک ٹیبل نہیں بلکہ پالیسی چنتی ہے۔
پالیسی پر مبنی: دونوں اطراف کو نیا سابقہ درج کرنا ہوگا
strongSwan کی اصطلاح میں سلیکٹر چائلڈ کنفیگ کے local_ts اور remote_ts میں رہتا ہے، جو leftsubnet اور rightsubnet کے جانشین ہیں۔ نیا سابقہ دونوں اطراف آئینے کی طرح نظر آنا چاہیے: جسے سائٹ A مقامی کہتی ہے، سائٹ B اسے دور کہتی ہے۔ فرق شاذ و نادر ہی صاف خرابی دیتا ہے۔ دونوں اطراف قطعے تک سمٹ جاتی ہیں، پرانا سابقہ چلتا رہتا ہے اور صرف نیا خاموشی سے ناکام ہوتا ہے۔
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policypfSense یا OPNsense میں اس کا مطلب دوسری Phase 2 اندراج ہے جو نئے مقامی سب نیٹ کو نئے دور دراز سب نیٹ سے جوڑتی ہے، پھر اطلاق۔ پرانا اندراج رکھیں؛ بدلنے سے اصل سب نیٹ شامل ہونے کے بجائے ہٹ جاتا ہے۔ اگر موجودہ Phase 2 پہلے ہی 0.0.0.0/0 جیسا سپر نیٹ یا خلاصہ رینج ڈھانپتی ہے تو اس کے ساتھ تنگ اندراج نہ لگائیں: اوورلیپ کرنے والے سلیکٹر مقابل پالیسیاں لگاتے ہیں اور جانچ کی ترتیب جیتنے والا طے کرتی ہے۔
IKEv1 ہر سب نیٹ جوڑے کو اپنی Phase 2 بناتا ہے، اور ہر تبادلے پر ایک جوڑا لینے والا فریق باقی چھوڑ دیتا ہے۔ IKEv2 ایک چائلڈ میں کئی سلیکٹر جوڑے لے جا سکتا ہے، مگر تب ہی جب دونوں عمل درآمد قبول کریں۔ swanctl --list-sas کی فہرست سچ ہے؛ آپ نے جو لکھا وہ درخواست ہے۔
روٹ پر مبنی: روٹ ہی پالیسی ہے
XFRM انٹرفیس یا VTI ڈیوائس روٹ ٹیبل کے مطابق ٹریفک لے جاتی ہے۔ آپ نیا سابقہ دونوں سائٹوں پر ڈیوائس کی طرف بھیجتے ہیں، اور انٹرفیس کی تبدیلی سے بندھی حالت لاگو ہوتی ہے۔ ہم آہنگ کرنے کے لیے سلیکٹر جوڑا نہیں، اسی لیے سب نیٹ بڑھنے پر یہ ڈیزائن بہتر پھیلتا ہے۔ strongSwan کی فارورڈنگ گائیڈ کرنل کی طرف تفصیل سے بتاتی ہے۔
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard آگے جاتا ہے۔ AllowedIPs بیک وقت کرپٹو اجازت فہرست ہے اور wg-quick کے ذریعے روٹ ٹیبل اندراج بھی۔ صرف ایک طرف سابقہ لگائیں تو ہاتھ ملانا، باہر جانے والے پیکٹ اور خاموشی ملے گی، کیونکہ دور والا فریق ایسے پیکٹ پھینک دیتا ہے جن کا ماخذ اس کی فہرست میں نہیں۔ wg set کی شکل پوری فہرست بدل دیتی ہے، اس لیے پہلے چلنے والے سابقے دوبارہ لکھیں، ورنہ آپ انہیں کاٹ دیں گے:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0wg-quick کے بجائے wg set استعمال کیا ہو تو وہ دوسرا حکم اختیاری نہیں۔ کرنل نئی فہرست فوراً قبول کرتا ہے، مگر کوئی اس کے لیے روٹ نہیں لگاتا، اس لیے مقامی طور پر بننے والی ٹریفک اب بھی ڈیفالٹ گیٹ وے سے نکلتی ہے۔ نیا WireGuard سب نیٹ ٹنل ہوسٹ سے چلنے اور لیپ ٹاپ سے نہ چلنے کی سب سے عام وجہ یہی ہے۔
واپسی راستہ ٹنل سے زیادہ بار ناکام ہوتا ہے
نئے دور دراز سب نیٹ کے ہوسٹس کو جوابات VPN گیٹ وے سے واپس بھیجنے ہوتے ہیں۔ جب وہ گیٹ وے ان کا ڈیفالٹ راؤٹر نہ ہو تو جواب LAN راؤٹر کی طرف جاتا ہے، جو اسے پھینک دیتا ہے یا نجی ماخذ پتے کے ساتھ انٹرنیٹ پر بھیج دیتا ہے۔ گیٹ وے سے نہیں، دور والے فریق کے ہوسٹ سے جانچیں: Linux میں ip route get 10.30.20.15 یا PowerShell میں Find-NetRoute -RemoteIPAddress 10.30.20.15 وہ اگلا قدم دکھاتا ہے جو ہوسٹ واقعی استعمال کرے گا۔ اگر جواب ٹنل کا آخری نقطہ نہ ہو تو وہاں نئے سابقے کے لیے مستقل روٹ شامل کریں۔
جس سائٹ کے پاس واپسی روٹ نہیں وہاں ماخذ NAT جائز متبادل ہے اور بہت سی hub-and-spoke تعیناتیاں ہر سرور کو چھونے سے اسی طرح بچتی ہیں۔ منزل والے فریق کے گیٹ وے پر بھی نئے سابقے پر اسے لاگو کریں:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEقیمت حقیقی ہے۔ دور دراز لاگ انفرادی ماخذ پتے دکھانا بند کر دیتے ہیں اور اصل سب نیٹ پر مبنی فائر وال قواعد گیٹ وے کے لیے ایک ہی قاعدے میں سمٹ جاتے ہیں۔ روٹ نہ ہونے کی وجہ سے نہیں، جان بوجھ کر یہ چنیں۔
فائر وال واپسی راستے کا دوسرا نصف ہیں۔ زون پر مبنی ڈیوائس موجودہ ٹنل انٹرفیس کا زون نئے سب نیٹ تک خودکار نہیں بڑھاتے، اور پرانے سابقے کے لیے لکھا قاعدہ نہیں ملے گا۔ IPsec کو الزام دینے سے پہلے نیا سب نیٹ زون میں یا دونوں سمتوں کے قاعدہ جوڑے میں شامل کریں۔
تین سوالوں سے فیصلہ کریں، پھر ٹریفک سے تصدیق کریں
مختصر شکل: فریق کی کنفیگریشن سابقوں کے نام دیتی ہے (پالیسی پر مبنی)، یا ٹریفک انٹرفیس میں روٹ ہوتی ہے (روٹ پر مبنی)؟ دونوں سرے نیا سابقہ درج کرتے ہیں؟ نئے سب نیٹ سے اصل ماخذ رینج تک واپسی کا راستہ ہے؟
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
تصدیق وہ جگہ ہے جہاں زیادہ تر تبدیلیاں بہت جلدی بند ہو جاتی ہیں۔ گیٹ وے سے پنگ کم ثابت کرتی ہے، کیونکہ گیٹ وے خود سے بھیجتا ہے اور اکثر ہوسٹ سے مختلف پالیسی سے ملتا ہے۔ نئے سب نیٹ کے ہوسٹ سے پنگ کریں، پھر وہ ایپلیکیشن چلائیں جس نے تبدیلی کا سبب بنایا، اور حالت کی آئیکن کے بجائے کاؤنٹر دیکھیں۔
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showپالیسی پر مبنی ٹنل میں ip xfrm state کے کاؤنٹر دونوں سمتوں میں بڑھنے چاہئیں؛ ہموار کاؤنٹر کا مطلب ہے پیکٹ روٹ ہوا مگر منتخب نہیں ہوا۔ WireGuard میں wg show ہر فریق کی منتقلی بتاتا ہے، اور صفر موصول بائٹ والا ہاتھ ملانا دور والے فریق کی فہرست یا اس کے واپسی روٹ کی طرف اشارہ کرتا ہے۔
آخر میں سابقہ، فریق کا سلیکٹر یا روٹ، واپسی راستے کا فیصلہ اور فائر وال اندراج باقی ٹنل فہرست کے ساتھ درج کریں۔ پھر ایک گیٹ وے ری بوٹ کر کے دوبارہ جانچیں: ہاتھ سے شامل کیا گیا روٹ غائب ہو جاتا ہے اور اگلے شخص کو اسے دوبارہ دریافت نہیں کرنا پڑنا چاہیے۔