Ping ثبوت نہیں: دو سائٹس کے درمیان راستہ جانچیں

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

جس کلائنٹ کو سروس درکار ہے اسی سے شروع کریں

کچھ جانچنے سے پہلے چار چیزیں لکھیں: کلائنٹ کا پتہ، منزل کا پتہ، ہوسٹ کا نام اور ایپ کا پورٹ۔ پھر تصدیق کریں کہ سروس اپنی سائٹ پر مقامی طور پر چلتی ہے، ساتھ والے ہوسٹ سے۔ اس بنیادی لکیر کے بغیر آپ ٹوٹے ٹنل اور ٹوٹی سروس میں فرق نہیں کر سکتے، اور ان ٹکٹوں میں سے آدھے دوسرے ہیں۔

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

ہر کنارے پر راستہ چلیں

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

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

اگر درخواست دور دراز کنارے پر نظر آئے مگر اس کے پیچھے جواب نہ ہو، مسئلہ دوسری طرف ہے: فائر وال، غائب واپسی روٹ، یا ایسا ہوسٹ جو ماخذ قبول نہیں کرتا۔ اگر درخواست کبھی نظر نہ آئے، تو مقامی روٹ یا ٹنل چننے والوں نے اسے نہیں اٹھایا، اور دوسری طرف ابھی تفتیش کے لائق نہیں۔

وہی پروٹوکول استعمال کریں جو ایپ استعمال کرتی ہے

ICMP کمزور جانچ ہے۔ اسے فلٹر کیا جا سکتا ہے، رفتار سے محدود کیا جا سکتا ہے یا سروس سے مختلف پالیسی سے نمٹا جا سکتا ہے، جو اس کی کامیابی اور ناکامی دونوں کو مبہم بناتا ہے۔ اصل پورٹ اور، جہاں ممکن ہو، اصل پروٹوکول ہینڈ شیک جانچیں۔

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

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

جس حالت میں ناکامی ہوتی ہے اسے دوبارہ پیدا کریں

صرف بڑی منتقلیوں میں ظاہر ہونے والی ناکامیاں سائز کا مسئلہ ہیں، رابطے کا نہیں۔ don't-fragment بٹ سیٹ کر کے بڑا پیکٹ بھیجیں اور دیکھیں کہ وہ کہاں رکتا ہے۔ اگر چھوٹی درخواست کامیاب ہو اور بڑی لٹک جائے، تو ٹنل کا MTU اور گیٹ ویز پر MSS کا انتظام اگلے مشتبہ ہیں۔

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

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

اصلاح کے بعد وہی جانچ دوبارہ کریں

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

چار بنیادی اقدار اور نتیجہ درج کریں۔ اسی علامت کی اگلی رپورٹ پھر پنگ کی بجائے ثبوت سے شروع ہو سکے گی۔