سائٹ سے سائٹ VPN کے ذریعے IPv6 سابقہ تفویض: چیک لسٹ

سرنگ اوپر اٹھانا آسان نصف ہے۔ میں نے سائٹ سے سائٹ لنک کو دنوں تک قائم رہتے دیکھا ہے جبکہ دور دراز LAN کے ہر میزبان کو خاموشی ہی واپس ملتی رہی، کیونکہ اُس گیٹ وے کے پیچھے تفویض شدہ سابقہ کسی انٹرفیس پر کنفیگر تھا مگر کبھی سرنگ میں روٹ نہیں ہوا۔ سرنگ کے پتے سارا وقت پنگ کا جواب دیتے رہے، اور یہی وجہ تھی کہ کسی نے سابقہ کی طرف نہیں دیکھا۔ تفویض شدہ IPv6 سابقہ جب سائٹ VPN سے گزرنا ہو تو میں یہ ترتیب جانچتا ہوں: سابقہ نقشہ، ٹریفک سلیکٹر، فارورڈنگ اور فائر وال، پھر واپسی راستہ۔

سرنگ کو چھونے سے پہلے سابقہ نقشہ لکھیں

سابقہ تفویض درخواست کرنے والے روٹر کو ایک بلاک دیتی ہے۔ یہ ہم منصب پر روٹ نصب نہیں کرتی، اُس بلاک کو on-link نہیں پھیلاتی، اور دور دراز گیٹ وے کو نہیں بتاتی کہ درخواست کرنے والے روٹر کے پیچھے کیا ہے۔ یہ تینوں آپ خود کنفیگر کریں، اور کسی بھی کنفگ فائل کی تبدیلی سے پہلے یہ پتہ منصوبے میں ہونے چاہئیں۔

ہر سائٹ کے لیے تفویض شدہ سابقہ، LAN پر واقعی استعمال ہونے والا /64، سرنگ کے پتے اور ہر روٹ کا مالک درج کریں۔ فراہم کنندہ سائٹ A کو 2001:db8:a1::/56 تفویض کرتا ہے، جو اپنے LAN پر 2001:db8:a1:10::/64 مہیا کرتی ہے؛ سائٹ B 2001:db8:b2::/64 رکھتی ہے۔ اگر سائٹ A صرف وہی ایک /64 مہیا کرتی ہے تو دونوں سروں کو پورے /56 کے بجائے 2001:db8:a1:10::/64 بتانا چاہیے۔

تقریباً ہر بار دو غلطیاں سامنے آتی ہیں۔ ایک یہ کہ دور دراز سابقہ کو on-link سمجھا جائے، اُسے برج کیا جائے یا سرنگ انٹرفیس پر رکھا جائے، جس سے گیٹ وے اُن میزبانوں کے لیے ہمسایہ درخواست کا جواب دیتا ہے جن تک پہنچ نہیں سکتا۔ دوسری یہ کہ پورا /56 اعلان کیا جائے جب صرف ایک /64 کنفیگر ہو: روٹ جدول دعویٰ کرتا ہے کہ بلاک قابل رسائی ہے اور زیادہ تر پتے کالے سوراخ میں گر جاتے ہیں۔

دونوں سروں کے ٹریفک سلیکٹر روٹوں سے ہم آہنگ کریں

IKEv2 اور WireGuard دونوں غیر موافق ٹریفک مسترد کرتے ہیں، اِتنی خاموشی سے کہ سرنگ اب بھی صحت مند دکھائی دیتی ہے۔

strongSwan میں سلیکٹر واضح ہوتے ہیں۔ سائٹ A پر:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

سائٹ B کا conn دونوں ذیلی نیٹ کی عکاسی کرتا ہے۔ جب وہ نہیں ملتے تو جواب دہندہ CHILD_SA کو TS_UNACCEPTABLE کے ساتھ مسترد کرتا ہے، اس لیے IKE_SA کے اٹھنے کے باوجود child SA کبھی نہیں اٹھتا۔ دونوں طرف کنفیگر شدہ ذیلی نیٹ اُس کے برابر ہونا چاہیے جو مقامی کرنل سرنگ کی طرف روٹ کرتا ہے۔

WireGuard وہی معلومات AllowedIPs میں رکھتا ہے، ایک موڑ کے ساتھ: AllowedIPs وصولی پر ماخذ فلٹر اور ارسال پر روٹ ہے۔ اگر سائٹ B کا سائٹ A کے لیے peer اندراج 2001:db8:a1:10::/64 چھوڑ دے تو سائٹ A سے آنے والے پیکٹ درست handshake پر آ کر غیر اجازت شدہ قرار دے کر پھینک دیے جاتے ہیں۔ اِس سے وہی جانا پہچانا نمونہ بنتا ہے: handshake مسلسل تجدید ہوتا رہتا ہے مگر کوئی جواب کبھی باہر نہیں جاتا۔ دونوں سروں کا wg show wg0 allowed-ips سے موازنہ کریں۔ جب بھی تفویض بدلے وہ فہرست دوبارہ جانچیں؛ پرانا /64 سیشن کو زندہ رکھتا ہے اور نیا سابقہ ناقابل رسائی بنا دیتا ہے۔

پہلے فارورڈنگ، فائر وال اور MTU خارج کریں

اگلی لاگ سطر پڑھنے سے پہلے تصدیق کریں کہ گیٹ وے واقعی فارورڈ کرتے ہیں۔ sysctl net.ipv6.conf.all.forwarding کو دونوں پر 1 واپس کرنا چاہیے، سرنگ اور LAN انٹرفیس پر بھی لاگو۔ ایک جال بھی ساتھ ہے: فارورڈنگ آن ہونے کے بعد accept_ra=1 والا انٹرفیس فراہم کنندہ سے روٹر اعلانات وصول کرنا بند کر دیتا ہے، اس لیے مشین سرنگ کے اندر مکمل طور پر روٹ کرتے ہوئے بھی اپنا بالائی طے شدہ راستہ کھو سکتی ہے۔ جہاں فراہم کنندہ کا RA اب بھی ضروری ہو وہاں accept_ra=2 مقرر کریں۔

پھر فائر وال قواعد کو سابقہ دونوں سمتوں میں اجازت دینی چاہیے، اور ICMPv6 کو بچنا چاہیے: ہمسایہ دریافت، packet-too-big اور destination-unreachable اختیاری نہیں۔ اِنہیں چھوڑ دیں تو راستے کی MTU دریافت بگڑ جاتی ہے اور ایسے کنکشن ملتے ہیں جو کھل کر پہلے بڑے جواب پر رک جاتے ہیں۔ کم از کم قواعد کی جوڑی ایسی دکھتی ہے:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU اِس کے پیچھے ہے۔ سرنگ قابل استعمال MTU کو 1500 سے نیچے کر دیتی ہے، اور IPv6 کا تقاضا ہے کہ ہر لنک کم از کم 1280 لے کر چلے۔ چھوٹے پنگ گزر جاتے ہیں، SSH سیشن بڑے بھڑکے پر جم جاتا ہے، اور /proc/net/snmp6 میں ایسے packet-too-big پیغام دکھتے ہیں جو کبھی واپس نہیں آتے۔ سرنگ کا MTU واضح طور پر مقرر کریں، یا mangle جدول میں TCP MSS محدود کریں، اور چھوٹا MTU بتانے والے ICMPv6 کو واپس آنے دیں۔

سرنگ کا پتہ نہیں، واپسی راستہ جانچیں

سب سے زیادہ وقت لینے والی خرابی یک طرفہ روٹنگ ہے۔ ہر گیٹ وے دور دراز سابقہ کو سرنگ میں روٹ کرتا ہے، مگر میزبان اپنے طے شدہ گیٹ وے سے جواب دیتے ہیں کیونکہ اُن کا /64 وہیں ہوتا ہے۔ پیکٹ کو منزل تک پہنچانا آدھا راستہ ہے۔

دو کمانڈ زیادہ تر حل کر دیتے ہیں۔ سائٹ A پر ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 دکھاتا ہے کہ اُس ماخذ سے آنے والا جواب کون سا انٹرفیس استعمال کرے گا؛ سائٹ B پر آئینے والی جانچ کریں۔ پھر ٹریفک گیٹ وے کے بجائے میزبان سے پیدا کریں اور دونوں سروں کے شمار کنندہ کا موازنہ کریں۔

اگر دور دراز سابقہ کے لیے ہمسایہ درخواست سرنگ پر نظر آئے تو وہ سابقہ کسی ایسی جگہ on-link ہے جہاں نہیں ہونا چاہیے؛ روٹ ایڈجسٹ کرنے سے پہلے اُسے درست کریں۔ Proxy NDP اُن صورتوں کو ڈھکتا ہے جہاں برج کرنا واقعی ضروری ہو، روٹ کا متبادل نہیں۔

سابقہ کے بدلنے کی منصوبہ بندی کریں

سابقہ تفویض تفویض کرنے والے اور درخواست کرنے والے روٹر کے درمیان کرایہ داری ہے، اور تجدید مختلف بلاک واپس کر سکتی ہے: فراہم کنندہ کی منتقلی کے بعد دوسرا /56، یا سرنگ کے قائم رہنے کی مدت سے کم کرایہ۔ پرانے سابقہ کا ذکر کرنے والی ہر جگہ بیک وقت پرانی ہو جاتی ہے: روٹ، سلیکٹر، AllowedIPs، فائر وال قواعد، DNS ریکارڈ اور کوئی بھی نگرانی جو لفظی پتے ہارڈ کوڈ کرتی ہو۔ پیغامات کا بہاؤ RFC 8415 میں ہے۔

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

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