IKEv2 کی ٹکڑوں میں تقسیم اور سند زنجیر کے مسئلے میں فرق

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

دو ٹکڑوں میں تقسیم کے طریقے، ایک علامت

IKEv2 کا اپنا تقسیم کا اضافہ ہے، جو RFC 7383 میں بیان کیا گیا ہے اور محفوظ IKE پیغامات کو چھوٹے IKE پیغامات میں تقسیم کرتا ہے۔ دونوں فریق اس صلاحیت پر بات چیت کرتے ہیں، اور پیغام IP پرت کے بجائے IKE کے نفاذ سے دوبارہ جوڑا جاتا ہے۔

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

NAT سے گزرنا تیسرا متغیر شامل کرتا ہے، کیونکہ پھر ESP کو UDP میں لپیٹا جاتا ہے اور بیرونی پیکٹ بڑا ہو جاتا ہے جبکہ وہ پورٹ 4500 پر عام UDP ٹریفک جیسا دکھتا ہے۔ UDP کو اچھی طرح گزارنے والا راستہ بھی ایسے ڈیٹا گرام پر ناکام ہو سکتا ہے جو اب سما نہیں سکتا۔

ناکام تبادلہ پڑھیں

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

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

راستہ بدلیں، سند نہیں

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

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

کچھ بھی ترمیم کرنے سے پہلے تبادلہ ناپیں

زنجیر کا سائز اور راستے کا سائز حاصل کریں۔ دونوں اعداد محدود کرتے ہیں کہ مصافحہ کیا بھیج سکتا ہے، اور دونوں کو ناپنا سستا ہے:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

پہلے دو سندوں کی تعداد اور فائل کا سائز دیتے ہیں، جو تصدیقی پیغام کے کتنے بڑے ہونے کا معقول اشارہ ہے۔ ping جانچ بتاتی ہے کہ اس سائز کا ڈیٹا گرام راستے پر قائم رہتا ہے یا نہیں، اور انٹرفیس کاؤنٹر دکھاتے ہیں کہ آپ کے سرے پر ٹکڑے پھینکے گئے یا نہیں۔ Windows پر مساوی جانچ do-not-fragment جھنڈے اور واضح پے لوڈ سائز والی ping ہے۔

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

جو پرت واقعی ٹوٹی ہے اسے ٹھیک کریں

اگر راستہ بڑے ڈیٹا گرام گراتا ہے، تو دونوں فریقوں پر IKE تقسیم فعال کریں اور تصدیق کریں کہ اضافہ صرف تجویز نہیں ہوا، بات چیت ہوئی ہے۔ اگر راستہ IP سطح پر ٹکڑوں سے برا سلوک کرتا ہے، تو اصلاح وہیں یا بیرونی انٹرفیس کے MTU میں ہے، سند کے ذخیرے میں نہیں۔

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

لکھیں کہ کون سا طریقہ بدلا اور اس کے بعد مصافحہ کیسا لگا۔ اگلا واقعہ عام طور پر اسی علامت کے ساتھ کسی دوسرے نیٹ ورک پر ہوتا ہے، اور وہی نوٹ دو گھنٹے کو دس منٹ میں بدلتا ہے۔