Linux EHOSTUNREACH اور OpenVPN: کون سا اگلا ہاپ ناکام ہوا؟

EHOSTUNREACH اکثر مقامی فیصلہ ہوتا ہے جتنا کہ دور کی ناکامی۔ کرنل کسی پیکٹ کو مسترد کر سکتا ہے کیونکہ کوئی روٹ کہتا ہے کہ منزل unreachable ہے، کیونکہ Ethernet کا اگلا ہاپ کبھی جواب نہیں دیا، یا کیونکہ راستے میں مزید آگے سے ICMP host-unreachable رپورٹ آئی۔ ہر ماخذ الگ جدول یا کیش میں رہتا ہے، اور ہر ایک الگ جگہ درست ہوتا ہے۔ سائفرز چھونے یا ٹنل دوبارہ انسٹال کرنے سے پہلے منتخب روٹ اور اگلے ہاپ کی حالت پڑھیں۔

وہ پتہ اور namespace منتخب کریں جو کلائنٹ واقعی استعمال کرتا ہے

منزل اور وہ نیٹ ورک namespace جس نے خرابی پیدا کی اسے مقرر کر کے شروع کریں۔ VPN کلائنٹ اپنے namespace میں چل سکتا ہے، اور ڈیفالٹ والے سے کی گئی تلاش مختلف پالیسی قواعد والا دوسرا روٹنگ جدول دیکھتی ہے۔

تلاش کو ناکام ہونے والی ایپلیکیشن جیسا ہی ماخذ، mark اور جدول کا سیاق استعمال کرنا چاہیے، ورنہ یہ ایسے سوال کا جواب دے سکتی ہے جو کسی نے نہیں پوچھا۔ مثال کے IPv4 peer کے لیے، صرف پڑھنے والے جائزے یہ ہیں:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

انتظامی شیل کا نتیجہ صرف یہ ثابت کرتا ہے کہ وہ شیل کیا کرے گا۔ اگر کلائنٹ firewall mark مقرر کرتا ہے یا VRF سے بندھتا ہے، تو تلاش کو اسی mark کے ساتھ یا VRF کے اندر دہرائیں اور منتخب روٹ اور اگلے ہاپ کا موازنہ کریں۔ پہلا پتہ جو تصدیق کرنا ہے وہ پروفائل میں peer کا پتہ ہے، نہ کہ وہ کلسٹر یا سروس جس کا صارف نام لیتا ہے۔

واضح unreachable روٹ پیکٹ کو مقامی طور پر مسترد کرتا ہے

unreachable قسم کا روٹ دانستہ مقامی جواب ہے۔ یہ کرنل کو کہتا ہے کہ پیکٹ پھینک دے اور بھیجنے والے کو EHOSTUNREACH واپس کرے، اسی لیے خرابی فوراً اور مشین سے کوئی ٹریفک نکلنے کے بغیر نظر آتی ہے۔ کسی نے یا کسی آٹومیشن نے وہ روٹ جان بوجھ کر وہاں رکھا۔

روٹ کی اقسام ایک دوسرے کی جگہ نہیں لے سکتیں۔ blackhole بھیجنے والے کو خرابی دیے بغیر پیکٹ پھینک دیتا ہے، prohibit EACCES واپس کرتا ہے، اور unreachable EHOSTUNREACH واپس کرتا ہے۔ دوبارہ جڑنے کے دوران sink روٹ نصب کرنے والا VPN مددگار اسی لیے host-unreachable خرابیوں کا ہجوم پیدا کر سکتا ہے جو ٹنل اٹھنے پر غائب ہو جاتا ہے، جبکہ blackhole روٹ اس کے بجائے خاموش ٹائم آؤٹ پیدا کرتا۔

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

مردہ ہمسایہ Ethernet پر وہی خرابی پیدا کرتا ہے

جب منتخب روٹ on-link گیٹ وے استعمال کرتا ہے تو ترسیل کے لیے حل شدہ لنک لیئر پتہ درکار ہوتا ہے۔ کرنل ARP یا IPv6 ہمسایہ استفسار بھیجتا ہے، اور اگر جواب نہ آئے تو پیکٹ فریم نہیں ہو سکتا۔ پھر بھیجنا EHOSTUNREACH کے ساتھ ناکام ہوتا ہے حالانکہ روٹ خود درست ہے۔

ہمسایہ جدول مرحلہ بتاتا ہے۔ INCOMPLETE کا مطلب ہے کہ حل ابھی جاری ہے، FAILED کا مطلب ہے کہ آخری کوشش کو جواب نہیں ملا، اور REACHABLE یا STALE کا مطلب ہے کہ کرنل کے پاس قابل استعمال پتہ ہے۔ VPN گیٹ وے کے لیے FAILED اندراج مقامی ترسیل کا مسئلہ ہے، ٹنل کے دور کے سرے کے بارے میں ثبوت نہیں۔

اندراج اصل اگلے ہاپ کے لیے پڑھیں، دور کے انٹرنیٹ پتے کے لیے نہیں۔ دور کا پتہ عام طور پر روٹر کے ذریعے پہنچا جاتا ہے، اس لیے اس کا اپنا ARP ریکارڈ نہیں ہوگا؛ اس کا مطالبہ ایک قسم کی غلطی ہے جو لوگوں کو ایسے غائب اندراج کی تلاش میں بھیجتی ہے جو کبھی ہونا ہی نہیں چاہیے تھا۔

دور کی رپورٹیں اور غیر ہم وقت UDP خرابیاں

EHOSTUNREACH باہر سے بھی آ سکتا ہے۔ جو روٹر پیکٹ آگے نہیں بھیج سکتا وہ ICMP host unreachable بھیج سکتا ہے، اور کرنل یہ رپورٹ اسی socket کو دیتا ہے جو بہاؤ کا مالک ہے۔ ایسے میں روٹ اور ہمسایہ ٹھیک ہیں، اور ناکامی مقامی نیٹ ورک سے آگے کے ہاپ کی ہے۔

UDP وجہ کی نشاندہی مشکل بناتا ہے۔ بعد کے send یا receive کال کا واپس کردہ نقصان پہلے کے datagram سے متعلق ہو سکتا ہے، اس لیے ناکام کال کا پتہ اور وقت رپورٹ پیدا کرنے والے پیکٹ سے مطابقت نہیں رکھ سکتے۔ جڑا ہوا UDP socket خرابی ایک بار وصول کرتا ہے، اور غیر جڑا socket اسے کبھی نہ دیکھ سکے۔

اسی لیے وقت ثبوت کا حصہ ہے۔ لکھیں کہ خرابی کب ظاہر ہوئی، socket نے کون سا peer پتہ استعمال کیا، اور کیا ٹنل ابھی دوبارہ جڑا تھا۔ روٹ تبدیلی کے فوراً بعد کا ہجوم مقامی جدول کی طرف اشارہ کرتا ہے؛ مستحکم بہاؤ میں چند منٹ بعد کی اکیلی خرابی راستے کی رپورٹ کی طرف اشارہ کرتی ہے۔

کرپٹو بدلنے سے پہلے تہوں کو الگ کریں

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

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

پہلی تبدیلی سے پہلے منزل، namespace، منتخب جدول، اگلا ہاپ، ہمسایہ کی حالت اور خرابی کا وقت درج کریں۔ درستی کے بعد وہی تلاش دوبارہ چلائیں؛ اب ٹنل کی طرف اشارہ کرنے والا روٹ اور اب حل ہونے والا ہمسایہ اندراج غیر متعلقہ پتے پر کامیاب ping سے زیادہ مضبوط ثبوت ہیں۔