دو سائٹس کے درمیان موجودہ VPN پر IPv6 کی روٹنگ

صرف IPv4 والا WAN پھر بھی اندرونی IPv6 لے جا سکتا ہے۔ سلیکٹرز، کرنل روٹس، فارورڈنگ اور وہ واپسی پریفکس ٹریس کریں جو جوابات کو خاموشی سے گرا دیتا ہے۔

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

دو ہیڈر، دو ایڈریس خاندان

IPsec ٹنل موڈ میں اندرونی IPv6 پیکٹ ESP ہیڈر کے پیچھے پے لوڈ بن جاتا ہے۔ وہ ESP پیکٹ اٹھانے والا بیرونی ہیڈر IPv4 یا IPv6 ہو سکتا ہے اور local_addrs اور remote_addrs کی پیروی کرتا ہے۔ WireGuard یہی کام کم رسم کے ساتھ کرتا ہے: اندرونی پیکٹ ساتھی کے سرے کی طرف جانے والے UDP ڈیٹا گرام کا پے لوڈ ہے۔ دونوں اندرونی ہیڈر کو اچھوت چھوڑتے ہیں، اسی لیے دور کا فریق ڈی کیپسولیشن کے بعد اسے روٹ کر سکتا ہے۔

سائٹس کے درمیان راستہ صرف UDP 4500 دیکھتا ہے جب IPsec NAT ٹریورسل استعمال کرتا ہے، یا ڈیفالٹ WireGuard سننے والے کے لیے UDP 51820۔ راستے پر کوئی بھی روٹر صرف IPv4 ہو سکتا ہے اور IPv6 ٹریفک پھر بھی گزر جاتی ہے، کیونکہ وہ اس راستے پر کبھی IPv6 پیکٹ کے طور پر ظاہر نہیں ہوتی۔ یہ ایک صاف پہلا تقسیم دیتا ہے: tcpdump -ni eth0 udp port 51820 خفیف شدہ راستہ دکھاتا ہے، tcpdump -ni wg0 ip6 اندرونی ٹریفک دکھاتا ہے۔ بیرونی کیپچر مصروف اور اندرونی خاموش ہو تو مطلب ہے کرنل IPv6 ٹنل میں نہیں ڈال رہا؛ یہ روٹنگ یا پالیسی ہے، لنک کی حالت نہیں۔

گیٹ وے فارورڈ کرتے وقت اندرونی Hop Limit بھی کم کرتا ہے، اس لیے سرے IPv6 راستے پر روٹر شمار ہوتے ہیں۔ بیرونی ہاپ شمار اور اندرونی Hop Limit الگ الگ چلتے ہیں، اور دور کے گیٹ وے پر مرنے والا پیکٹ فارورڈنگ میں مرا، خفیف کرنے میں نہیں۔

سلیکٹرز اور AllowedIPs اجازت کی فہرست ہیں

IKEv2 طے کرتا ہے کہ child SA کون سے اندرونی پریفکس لے جا سکتا ہے۔ strongSwan 5.9 اور بعد میں انہیں swanctl.conf میں لکھنا ایسا دکھتا ہے:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

اگر local_ts اور remote_ts چھوڑ دیں تو strongSwan انہیں اپنے منتخب کردہ انٹرفیس کے ذیلی نیٹ سے نکالتا ہے۔ دوہرے اسٹیک والے میزبان پر یہ شارٹ کٹ اکثر صرف IPv4 کا جوڑا دیتا ہے: SA اٹھتا ہے اور IPv6 ESP کوڈ تک پہنچنے سے پہلے مسترد ہو جاتا ہے۔ دونوں پریفکس لکھنا SA کو انہیں لینے کے قابل بناتا ہے، اور start_action = trap اسے پہلے مماثل پیکٹ پر اٹھاتا ہے۔

WireGuard کے پاس ایک ہی فہرست ہے جو دو کام کرتی ہے۔ ساتھی بلاک میں AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 بھیجتے وقت نصب راستہ بھی ہے اور وصول کرتے وقت لگایا گیا فلٹر بھی: ایسا ڈی خفیف شدہ پیکٹ جس کا اندرونی ماخذ اس ساتھی کی فہرست سے باہر ہو خاموشی سے گرا دیا جاتا ہے۔ wg-quick ہر اندراج کے لیے راستہ شامل کرتا ہے، اس لیے نیچے والے ساتھی بلاک کو الگ ip -6 route کمانڈ کی ضرورت نہیں۔

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

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

فارورڈنگ، روٹس اور واپسی پریفکس

Linux اس وقت تک IPv6 فارورڈ نہیں کرتا جب تک آپ نہ کہیں، اور ترتیب انٹرفیس کے بجائے namespace کے حساب سے ہے:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

دوسری سطر وہی ہے جو روٹ پر مبنی ڈیزائنوں میں لوگ بھول جاتے ہیں۔ پالیسی پر مبنی IPsec پریفکس سے مماثل XFRM پالیسی نصب کرتا ہے، لیکن vti6 یا WireGuard والی روٹ پر مبنی ترتیب کو ایک حقیقی IPv6 راستہ درکار ہے جو اس ڈیوائس کی طرف اشارہ کرے۔ sysctl کو /etc/sysctl.d/ کے تحت مستقل رکھیں؛ ورنہ دوبارہ بوٹ فارورڈنگ کو خاموشی سے بند کر دیتا ہے۔

فارورڈنگ کا ایک ضمنی اثر ہے جو جاننے کے قابل ہے: کرنل پھر روٹر اعلانات نظر انداز کر دیتا ہے جب تک کہ net.ipv6.conf.<wan>.accept_ra 2 نہ ہو، اس لیے جس گیٹ وے کا WAN پتہ SLAAC سے آتا ہے وہ فارورڈنگ کھالتے ہی اپنا ڈیفالٹ راستہ کھو سکتا ہے۔ اسی فائل میں اس انٹرفیس پر accept_ra = 2 مقرر کریں تو راستہ زندہ رہتا ہے۔ سائٹ B کے کرنل کو بھی ٹنل کے گیٹ وے سے 2001:db8:aa::/48 سیکھنا چاہیے، جامد راستے یا ٹنل پر روٹنگ پروٹوکول کے ذریعے، ورنہ جواب B کے اپنے نیٹ ورک میں مر جاتا ہے۔

چار مرحلوں کی جانچ جو وقفے کا مقام بتاتی ہے

اسی ترتیب سے کام کریں اور پہلے ناکام مرحلے پر رک جائیں، کیونکہ ہر اگلا مرحلہ پچھلوں پر منحصر ہے۔

  1. سلیکٹرز: swanctl --list-sas کو child SA پر IPv6 پریفکس جوڑا دکھانا چاہیے، یا wg show wg0 allowed-ips دور کا پریفکس تازہ latest-handshakes کے ساتھ۔
  2. کرنل روٹ: ip -6 route get 2001:db8:bb::10 کو ٹنل ڈیوائس سے جواب دینا چاہیے، WAN انٹرفیس سے نہیں۔
  3. اندرونی کیپچر: tcpdump -ni wg0 ip6 اصل LAN میزبانوں کے درمیان ping کرتے وقت۔ نکلنے والے مگر کوئی واپس نہ آنے والے پیکٹ B کے راستے یا فائر وال کی طرف اشارہ کرتے ہیں؛ بالکل کوئی پیکٹ نہ ہونا مرحلہ 1 یا 2 کی طرف اشارہ کرتا ہے۔
  4. منزل: B میزبان پر ss -6 -ltn تصدیق کرتا ہے کہ سروس IPv6 پر سن رہی ہے، اور مقامی فائر وال شمار کنندگان بتاتے ہیں کہ پیکٹ قبول ہوا یا گرا دیا گیا۔

MTU اسی مرحلے میں آتا ہے۔ IPv6 روٹر ٹکڑے نہیں کرتے، اس لیے حد سے بڑا پیکٹ گرا دیا جاتا ہے اور Packet Too Big بھیجنے والے کو واپس آتا ہے۔ اگر ہاتھ ملانا اور چھوٹے ping کام کریں مگر فائل کی منتقلی رک جائے تو پے لوڈ کم کریں یہاں تک کہ گزر جائے: ping -6 -s 1400 -c 3 2001:db8:bb::10۔ WireGuard انٹرفیس کا ڈیفالٹ MTU 1420 بائٹ ہے اور IPv4 پر IPsec زیادہ کٹتا ہے، اس لیے اندرونی MTU مقرر کرنا ICMPv6 گرانے والے فائر وال کے ذریعے راستے کا MTU دریافت ہونے کی امید سے بہتر ہے۔

ناکامی کی حالتیں جو فائر وال کے مسائل جیسی لگتی ہیں

سب سے عام کوئی فائر وال نہیں ہے: سروس :: کے بجائے 0.0.0.0 سے بندھتی ہے، AAAA ریکارڈ موجود ہے، اور کلائنٹ کو IPv6 پر تیز انکار ملتا ہے جسے دوہرے اسٹیک والا براؤزر IPv4 پر واپس جا کر چھپا دیتا ہے۔ اگر صرف کچھ ایپلیکیشنز ناکام ہوں تو قواعد کے مجموعے کو چھونے سے پہلے سننے والا خاندان دیکھیں۔

دوسرا ICMPv6 فلٹرنگ ہے۔ Neighbor Discovery اور Packet Too Big عام کام کا حصہ ہیں، تشخیص کا نہیں، اور وہ پالیسی جو تمام ICMPv6 گرا دے وہ ٹنل بناتی ہے جو جڑتی ہے، تصدیق کرتی ہے اور پھر چھوٹے پیکٹ سے بڑی ہر چیز پر رک جاتی ہے۔ جن اقسام پر راستہ منحصر ہے انہیں اجازت دیں اور شمار کنندگان کھلے رکھیں تاکہ گرانا نظر آئے۔

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

متعلقہ مضامین