VPN پر IPv6 link-local کام نہیں کر رہا: fe80 لنک پر کیوں رکتا ہے
fe80:: پتے کا مطلب صرف ایک لنک پر ہوتا ہے۔ دیکھیں کہ روٹ شدہ VPN اسے کیوں نہیں لے جا سکتا، ناکامی کیسی دکھتی ہے، اور اس کے بجائے کون سا پتہ استعمال کریں۔
آپ ٹنل اوپر لاتے ہیں، ٹنل کو ماخذ انٹرفیس بنا کر fe80::1 کو ping کرتے ہیں، اور کچھ واپس نہیں آتا۔ یہ کوئی بھولا ہوا firewall قاعدہ نہیں ہے۔ Link-local پتے کا مطلب صرف اسی ایک لنک پر ہوتا ہے جہاں وہ بنا، اور روٹ شدہ VPN وہ لنک نہیں ہے۔ دور کے راؤٹر کا fe80::1 دور کے LAN حصے میں رہتا ہے؛ آپ دوسرے حصے میں ایک ہاپ دور بیٹھے ہیں، اور IPv6 میں راؤٹر کے link-local پیکٹ آگے بھیجنے کا کوئی طریقہ ہی نہیں ہے۔
fe80 سابقہ دائرہ بتاتا ہے، حد نہیں
Link-local unicast fe80::/10 ہے، اور بیان کرنے والی خصوصیت عدد نہیں بلکہ دائرہ ہے۔ پتہ صرف ایک لنک پر درست ہوتا ہے، اور ہر انٹرفیس اپنی شناخت سے ایک بناتا ہے، اسی لیے دو غیر متعلق نیٹ ورکس کی دو غیر متعلق مشینیں بغیر کسی تصادم کے دونوں fe80::1 کا جواب دے سکتی ہیں۔ سابقہ بنیادی طور پر کہتا ہے «کسی لنک پر»؛ لنک خود سیاق و سباق سے آتا ہے۔
میزبان پر وہ سیاق فیصد نشان کے بعد لگایا جانے والا زون، یعنی scope ID ہے: Linux پر fe80::1%eth0، Windows پر اور انٹرفیس اشاریے دکھانے والے اوزاروں میں fe80::1%3 یا fe80::1%12۔ کرنل پتے کو انٹرفیس اشاریے کے ساتھ حل کرتا ہے اور پھر بھیجتا ہے۔ زون ہٹا دیں تو منزل مبہم ہو جاتی ہے، اس لیے اسٹیک کے پاس حصہ چننے کا کوئی راستہ نہیں بچتا۔
روٹ شدہ ٹنل اسے کیوں نہیں پہنچا سکتا
روٹ شدہ VPN ایک نقطہ سے نقطہ انٹرفیس ہے جو اپنے پتے رکھتا ہے، عام طور پر ٹنل کے اندر unique-local یا نجی IPv6 فضا کا /64۔ دور کا LAN الگ لنک ہے، جہاں ٹنل کا سرا آپ کی طرف سے روٹنگ اور فارورڈنگ کر کے پہنچتا ہے۔ یہ دو الگ حصے ہیں، اس لیے ایک کا پتہ دوسرے پر درست منزل نہیں۔
فارورڈنگ قاعدہ معیار میں واضح ہے، یہ آپ کے کلائنٹ کی عجیب بات نہیں: راؤٹر link-local ماخذ یا منزل والے پیکٹ آگے نہیں بھیجتے۔ اسی لیے پیکٹ تب بھی مرتا ہے جب روٹ جدول درست دکھائی دے۔ fe80::/64 کے لیے ٹنل کی طرف روٹ شامل کریں تو معیار پر عمل کرنے والا اسٹیک یا تو اسے مسترد کرتا ہے یا قبول کر کے ہر مماثل پیکٹ گرا دیتا ہے: منزل کا دائرہ کہتا ہے «صرف یہ لنک»، اور باہر جانے والا انٹرفیس وہ لنک نہیں۔
پڑوسی کی دریافت اسی حد کو مضبوط کرتی ہے۔ میزبان link-local اگلی ہاپس 255 ہاپ کی حد کے ساتھ لنک دائرے کے multicast پر بھیجی گئی پڑوسی درخواست سے حل کرتے ہیں، اس لیے راؤٹر آگے بھیجی ہر چیز کو مسترد کر سکتے ہیں۔ اسے ٹنل کے پار چلانا دور کے حصے کے لیے دریافت کی پراکسی کرنا ہے، جو دوسری ٹوپی پہنے Layer 2 پل ہے۔
دوسری، زیادہ خاموش ناکامی ہے، اور وہ روٹ زبردستی لگانے کی کوشش کرنے والوں کو پکڑتی ہے: زون۔ آپ مقامی طور پر جو بھی زون لکھیں وہ ٹنل انٹرفیس کا نام لیتا ہے، جبکہ آپ کا مطلوبہ پتہ دور کے LAN انٹرفیس سے بندھا ہے۔ دونوں کبھی نہیں ملتے، اس لیے پیکٹ کو دور کے سرے پر صحیح انٹرفیس کی طرف نہیں موڑا جا سکتا۔
عملاً ناکامی کیسی دکھتی ہے
دائرے کی غلطی کے لیے اوزار کی آؤٹ پٹ روٹنگ یا firewall کی غلطی جیسی پڑھی جاتی ہے، اور اسی لیے لوگ غلط تہہ میں آدھا دن گزارتے ہیں۔
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
تیسری سطر سب سے زیادہ وقت ضائع کرتی ہے، کیونکہ بغیر آؤٹ پٹ والا ssh کلائنٹ سننے والی سروس کا مسئلہ لگتا ہے۔ اگر اندر آنے کا کوئی راستہ ہو تو دور کا رخ دیکھیں اور تصدیق کریں کہ sshd تمام پتوں سے بندھا ہے یا صرف ایک سے۔
وہ پتہ استعمال کریں جو روٹ ہونے کے لیے بنایا گیا ہو
ٹنل کے ذریعے پہنچنے والی ہر چیز کے لیے وہی پتہ استعمال کریں جو سروس کو اسی مقصد کے لیے دیا گیا: عالمی unicast پتہ، یا fc00::/7 میں سے unique-local پتہ، وہ حد جو بالکل اسی داخلی معاملے کے لیے مخصوص ہے۔ تصدیق کریں کہ سننے والا اسے واقعی باندھتا ہے، اور واپسی کا راستہ اور میزبان کا کوئی بھی firewall قاعدہ جانچیں۔
اندازہ لگانے کے بجائے دور کے میزبان کو دیکھیں۔ ip -6 addr show موجود پتے گنواتا ہے، اور ss -6 -ltn بتاتا ہے کہ ڈیمون کس پر سن رہا ہے۔ صرف fe80:: سے بندھی سروس صرف اپنے حصے سے پہنچی جا سکتی ہے، جو عام طور پر ایسی طے شدہ قدر ہے جو کسی نے جان بوجھ کر نہیں چنی اور منتظم کی رضامندی سے بدلی جا سکتی ہے۔
جب سروس واقعی دوبارہ نہ بندھ سکے، تو پل کو نیٹ ورک تہہ کے بجائے ایپلیکیشن تہہ پر اٹھائیں۔ دور کے میزبان پر روٹ ہونے کے قابل پتے پر سننے والا اور link-local سے جڑنے والا ریلے کسی حصے کو پھیلائے بغیر مسئلہ حل کرتا ہے:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80یہاں زون صحیح طرف ہے، اس میزبان پر جس کے پاس واقعی اس لنک پر eth0 ہے۔ آپ کا کلائنٹ fd00:1:2::10 سے بات کرتا ہے، جو عام طور پر روٹ ہوتا ہے، اور ریلے link-local ہاپ مقامی طور پر کرتا ہے۔ وہی ترکیب کسی آلے کے ویب UI یا پرانے BMC کے لیے بھی کام کرتی ہے جو صرف link-local پتہ مشتہر کرتا ہے۔
جب پل بندی واقعی جواب ہو، اور کیا جانچیں
کچھ تعیناتیوں کو واقعی ایک مشترکہ حصہ چاہیے: ایسا آلہ جو صرف link-local دریافت بولتا ہے، ایسا پرزہ جو multicast پر منحصر ہے، ایسی تجربہ گاہ جو ہموار LAN دوبارہ بناتی ہے۔ یہ Layer 2 کا مسئلہ ہے اور اسے Layer 2 کا جواب چاہیے، جیسے دور کے انٹرفیس سے پل بندھا tap آلہ یا واضح پل موڈ والی کلائنٹ مصنوع۔ اس کی قیمت ٹنل عبور کرنے والی broadcast اور multicast ٹریفک اور سرے سے سرے تک چلنے والی پڑوسی دریافت ہے۔
روٹ شدہ پروفائل میں fe80::/64 شامل کر کے اس کے قریب نہ جائیں۔ اس سے بدترین حالت بنتی ہے: ترتیب مکمل دکھائی دیتی ہے، روٹ جدول اندراج دکھاتا ہے، اور ہر پیکٹ اب بھی دو ایسے اسٹیکوں کے درمیان کہیں گرا دیا جاتا ہے جو دونوں درست برتاؤ کر رہے ہیں۔
ping کے بجائے انٹرفیس سے تصدیق کریں۔ ip -6 addr show tun0 بتاتا ہے کہ ٹنل لنک نے اپنا link-local پتہ بنایا یا نہیں، اور ip -6 route get fe80::1%tun0 بتاتا ہے کہ کرنل دائرے والی منزل کے ساتھ واقعی کیا کرے گا۔ جب کرنل کہے کہ اس انٹرفیس پر منزل ناقابل رسائی ہے، تو کوئی ٹنل ترتیب اسے نہیں بدلے گی، اور پروفائل میں ترمیم بند کرنے کا وقت آ گیا ہے۔
سوال طے کرنے والا مختصر سلسلہ:
- دور کے میزبان پر پتہ پڑھیں اور دیکھیں کہ وہ fe80:: ہے یا روٹ ہونے کے قابل سابقہ۔
- اگر fe80:: ہے تو سروس دوبارہ باندھیں، اس میزبان پر ریلے کریں، یا حصے کو پل باندھیں؛ اگر روٹ ہونے کے قابل ہے تو روٹ، firewall یا بائنڈ پتہ درست کریں۔
- ہر بار دوبارہ جانچتے وقت زون دوبارہ دیکھیں، کیونکہ نقل شدہ کمانڈ عموماً غلط انٹرفیس رکھتی ہے۔
ماخذ: RFC 4291، IPv6 پتوں کی ساخت۔