لینکس پر فارورڈنگ فعال کرنے کے بعد IPv6 کا ڈیفالٹ راستہ غائب ہو گیا

میں نے ایک Debian گیٹ وے پر net.ipv6.conf.all.forwarding=1 مقرر کیا تاکہ وہ VPN کلائنٹس کی ٹریفک آگے بھیج سکے، اور تقریباً آدھے گھنٹے بعد مشین کے پاس IPv6 کا کوئی ڈیفالٹ راستہ باقی نہیں تھا۔ اوپر والا راؤٹر فعال تھا، link-local ہمسایہ اب بھی جواب دے رہا تھا، اور uplink اب بھی اپنا عالمی پتہ رکھے ہوئے تھا۔ جو چیز رک گئی وہ کرنل کی یہ آمادگی تھی کہ وہ اس انٹرفیس پر راؤٹر اعلانات وصول کرتا رہے۔ راستہ اس وقت غائب نہیں ہوا جب میں نے sysctl لکھا؛ وہ اس وقت غائب ہوا جب RA سے سیکھے گئے ڈیفالٹ راستے کی مدت ختم ہوئی اور کسی چیز نے اسے تازہ نہیں کیا۔

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

کسی بھی sysctl کو چھونے سے پہلے راستوں کا جدول پڑھیں

ip -6 route show default سے شروع کریں اور خصوصیات پڑھیں، صرف گیٹ وے نہیں۔ RA سے سیکھا گیا ڈیفالٹ راستہ proto ra سے نشان زد ہے، ترجیح رکھتا ہے اور expires کی الٹی گنتی دکھاتا ہے۔ ہاتھ سے شامل کیا گیا راستہ ان دونوں میں سے کچھ نہیں رکھتا، اور یہی فرق آپ کو بتاتا ہے کہ راستے کا مالک کون سا طریقہ کار ہے۔

$ ip -6 route show default
default via fe80::1 dev eth0 proto ra metric 1024 expires 1432sec hoplimit 64 pref medium

پھر پتہ دیکھیں: ip -6 addr show dev eth0۔ عالمی پتہ جس کی ترجیحی اور درست مدتیں گھنٹوں میں ناپی جاتی ہیں، ایسے ڈیفالٹ راستے سے زیادہ جیے گا جس کی راؤٹر مدت منٹوں میں ناپی جاتی ہے۔ پتہ موجود ہو اور ڈیفالٹ راستہ نہ ہو، یہ اعلانات کے مسئلے کی نشانی ہے۔ اگر پتہ بھی نہ ہو تو پہلے لنک، سابقے کی معلومات یا دہرے پتوں کی نشاندہی کو دیکھنا ہوگا۔

فارورڈنگ RA کی کارروائی کیوں بند کر دیتی ہے

RA ایک ICMPv6 پیکٹ ہے جو قسم 134 کا ہے، link-local ماخذ سے 255 کی چھلانگ حد کے ساتھ بھیجا جاتا ہے۔ کرنل اسے استعمال کرنے سے پہلے انٹرفیس کا accept_ra دیکھتا ہے۔ طے شدہ قدر 1 ہے، اور 1 کا مطلب ہاں نہیں ہے۔ اس کا مطلب یہ ہے: صرف تب قبول کرو جب تک یہ میزبان آگے نہ بھیج رہا ہو۔ forwarding=1 مقرر کریں تو یہ شرط پوری نہیں ہوتی، اس لیے اعلان اس سے پہلے ہی خارج کر دیا جاتا ہے کہ اس میں موجود کوئی سابقہ یا ڈیفالٹ راؤٹر زیر غور آئے۔

تین قدریں ہیں، اور فارورڈنگ سے صرف تیسری بچتی ہے:

دو دیگر جھنڈے طے کرتے ہیں کہ دراصل کیا نصب ہوتا ہے۔ accept_ra_defrtr یہ کنٹرول کرتا ہے کہ اعلان میں موجود ڈیفالٹ راؤٹر راستہ بنتا ہے یا نہیں، اور accept_ra_pinfo یہ کنٹرول کرتا ہے کہ سابقے کی معلومات پتے کی تشکیل کے لیے استعمال ہوتی ہیں یا نہیں۔ accept_ra_defrtr بند کرنا یہ عام طریقہ ہے کہ آگے بھیجنے والے میزبان پر SLAAC پتے رکھے جائیں بغیر ڈیفالٹ راستہ سیکھے۔ یہ accept_ra سے مختلف لیور ہے، اور یہی استعمال ہوتا ہے جب پتے چاہیے ہوں مگر راستہ نہیں۔ کرنل کا IP sysctl حوالہ تینوں کی فہرست دیتا ہے۔

تین احکامات سے تصدیق کریں

پہلے وہ اقدار پڑھیں جو چل رہی ہیں، نہ کہ وہ فائل جو آپ کے خیال میں لوڈ ہے:

sysctl net.ipv6.conf.eth0.forwarding net.ipv6.conf.all.forwarding \
       net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_defrtr

دوسرا، ثابت کریں کہ اعلانات اب بھی آ رہے ہیں۔ ICMPv6 قسم کے بائٹ پر فلٹر کرنا کافی ہے، اور یہ آپ کو ہمسایوں کی نشاندہی کی ٹریفک کی دیوار پڑھنے سے بچاتا ہے:

tcpdump -ni eth0 'icmp6 and ip6[40] == 134'

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

rdisc6 eth0

rdisc6 Debian اور Ubuntu پر ndisc6 کے بنڈل میں آتا ہے۔ اخراج میں، کوئی اور چیز بدلنے سے پہلے راؤٹر مدت اور ترجیح دیکھیں۔ جس اعلان کی راؤٹر مدت 0 ہو وہ ڈیفالٹ راؤٹر ہٹانے کی ہدایت ہے، اور accept_ra کی کوئی قدر اسے قابل استعمال راستہ نہیں بناتی۔ اسی طرح آپ اوپر والا CPE پل کے موڈ میں بھی پکڑتے ہیں جو سابقے تقسیم کرتا ہے مگر خود کو کبھی راؤٹر پیش نہیں کرتا۔

uplink کو واحد اجازت دینے والا انٹرفیس بنائیں

اگر اوپر والے حصے کو ڈیفالٹ راؤٹر ہونا چاہیے تو وہاں فارورڈنگ کے باوجود اعلانات قبول کریں، اور کہیں اور نہیں:

# /etc/sysctl.d/60-ipv6-router.conf
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.eth0.accept_ra_defrtr = 1

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

عارضی sysctl -w اگلی باری کے آغاز تک نہیں رہے گا، اور systemd-networkd اور NetworkManager دونوں یہ اقدار اپنی ترتیب سے لکھتے ہیں۔ networkd میں uplink کی .network فائل میں IPv6Forwarding=yes اور IPv6AcceptRA=yes مقرر کریں؛ networkd کرنل کی اسی وجہ سے IPv6Forwarding کو عالمی بتاتا ہے۔ NetworkManager میں uplink پر ipv6.method=auto ہی accept_ra کی قدر چلاتا ہے، اس لیے nmcli connection up کے بعد sysctl دوبارہ پڑھیں بجائے اس کے کہ پہلی جانچ پر بھروسا کریں۔

جامد متبادل، ip -6 route add default via fe80::1 dev eth0، واقعی کام کرتا ہے، اور یہ معقول جواب ہے جب اوپر والے راؤٹر کے پاس مستحکم link-local پتہ ہو۔ صاف طور پر جانیں کہ آپ کیا چھوڑ رہے ہیں۔ جامد ڈیفالٹ راستہ کبھی تازہ نہیں ہوتا اور کبھی واپس نہیں لیا جاتا، اس لیے اوپر والا حصہ بدلنے کے بعد بھی وہ مردہ ہمسایے کی طرف اشارہ کرتا رہتا ہے۔ RA کا راستہ محفوظ طریقے سے ناکام ہوتا ہے؛ جامد خاموشی سے ناکام ہوتا ہے۔

آگے بھیجا گیا پیکٹ جانچیں، خود گیٹ وے کا نہیں

گیٹ وے کے اپنے ping ایسے راستے پر کامیاب ہو سکتے ہیں جو کوئی کلائنٹ استعمال نہیں کر سکتا، اور وہ اس لیے بھی کامیاب ہو سکتے ہیں کہ گیٹ وے ماخذ ہے۔ کسی منسلک کلائنٹ سے جانچیں، پھر گیٹ وے سے پوچھیں کہ وہ اس کلائنٹ کے پتے کے لیے کیا کرے گا:

# on the VPN client
ping -6 -c 3 2001:4860:4860::8888

# on the gateway, using a client address
ip -6 route get 2001:4860:4860::8888 from fd42:20::2

پھر ایک راؤٹر مدت کا انتظار کریں اور دوبارہ دیکھیں۔ جو مستحکم حالت آپ چاہتے ہیں وہ proto ra سے نشان زد ڈیفالٹ راستہ ہے جس کی expires قدر بار بار از سر نو مقرر ہوتی ہے، کے ساتھ all.forwarding=1۔ اگر expires صرف الٹی گنتی کر رہا ہے تو اعلانات اب بھی کہیں خارج ہو رہے ہیں، اور عام مجرم وہ نیٹ ورک منتظم ہے جو accept_ra کو دوبارہ لکھتا ہے بعد اس کے کہ آغاز کے وقت کا sysctl پہلے ہی چل چکا ہو۔

اسے بند کرنے سے پہلے چار چیزیں تصدیق کریں: ڈیفالٹ راستہ proto ra ہے اور تازہ ہو رہا ہے، accept_ra=2 صرف uplink پر لاگو ہے، فارورڈنگ دوبارہ آغاز کے بعد اور منتظم کے دوبارہ آغاز کے بعد بھی 1 ہے، اور IPv6 ping کلائنٹ مکمل کرتا ہے نہ کہ گیٹ وے۔ اگر کلائنٹ صحت مند راستے کے باوجود ناکام ہو تو اگلا مشتبہ واپسی کا راستہ یا اوپر والا فائر وال ہے، اعلان نہیں۔