IPsec پر ڈیٹابیس استفسار لٹک جاتا ہے: UDP کی دوبارہ ترتیب یا TCP؟
صاف handshake کے بعد لٹکنے والا استفسار سرنگ کے راستے کے اندر کی طرف اشارہ کرتا ہے۔ راستہ درست کرنا ہے یا 443 پر TCP پر واپس جانا، یہ تین شرطیں طے کرتی ہیں۔
TCP handshake کے بعد لٹکنے والا استفسار روٹنگ کا مسئلہ نہیں ہے۔ راستے کی خرابیاں handshake ناکام کرتی ہیں، اس لیے جو سیشن قائم ہو کر پھر خاموش ہو جائے وہ راستے کے اندر کی طرف اشارہ کرتا ہے: معائنہ، MTU، یا سرنگ کے UDP پیکٹ آنے کا طریقہ۔ آپ کے سامنے فیصلہ یہ ہے کہ وہ راستہ درست کریں یا سرنگ کو TCP پر منتقل کریں۔ تین شرطیں یہ طے کرتی ہیں، اور ان میں سے کوئی بھی ڈیٹابیس کے بارے میں نہیں ہے۔
سرنگ کو مورد الزام ٹھہرانے سے پہلے لٹکنے کی درجہ بندی کریں
چار نتائج صارف کو ایک جیسے لگتے ہیں اور انجینئر کے لیے بالکل مختلف معنی رکھتے ہیں۔
| What the client sees | What it rules out |
|---|---|
| Connection refused | Nothing is listening on the address and port the client reached |
| Timeout before the handshake | A filter, a missing route, or the wrong address |
| Handshake completes, query hangs | The session exists, so look at inspection, MTU and packet order |
| Stalls that recover on retry | Often reordering, or a state table entry expiring |
صرف آخری دو سطریں سرنگ پر وقت صرف کرنے کا جواز پیش کرتی ہیں۔ VPN کے ذریعے مسترد کنکشن عام طور پر ڈیٹابیس کا صرف loopback پر سننا ہوتا ہے، جو سننے والے کا مسئلہ ہے، اور handshake سے پہلے وقت کا ختم ہونا فلٹر یا راستہ ہے۔ دونوں میں سے کوئی بھی encapsulation بدلنے سے بہتر نہیں ہوتا۔
درجہ بندی پہلے ٹکٹ میں لکھیں۔ یہ سب سے سستا قدم ہے اور تلاش کی زیادہ تر جگہ ختم کر دیتا ہے۔
UDP اور TCP کے درمیان فیصلہ کرنے والی تین شرطیں
encapsulated IPsec ٹریفک UDP پر چلتی ہے، اور UDP راستے کو بغیر کسی کو بتائے دوبارہ ترتیب دینے اور گرا دینے کی آزادی دیتا ہے۔ جب دوبارہ ترتیب پیکٹوں کو سرنگ کی تکرار کے خلاف ونڈو سے باہر دھکیلتی ہے، تو وہ خاموشی سے خارج ہو جاتے ہیں اور اندرونی TCP سیشن صرف انتظار کرتا ہے۔ کامیاب handshake اور کبھی واپس نہ آنے والے استفسار کے پیچھے یہی طریقہ کار ہے۔
راستہ درست کرنا یا TCP پر واپس جانا تین چیزوں پر منحصر ہے۔ پہلا، راستے پر حقیقی پیکٹ کا نقصان ہے یا صرف دوبارہ ترتیب؟ دوسرا، کیا آپ معائنہ کی جگہ بدل سکتے ہیں، یا اس سرنگ کو دوبارہ ترتیب دینے والے جزو سے نکال سکتے ہیں؟ تیسرا، کیا کام کا بوجھ لٹکنے کے انداز کے لیے حساس ہے، مثلاً ایک لنک بانٹنے والے بہت سے ملٹی پلیکس سیشن؟
اگر پہلا جواب نقصان ہے اور دوسرا نہیں،تو 443 پر TCP عملی متبادل ہے۔ اگر دوسرا جواب ہاں ہے، تو راستہ درست کریں اور UDP رکھیں۔
ایپلی کیشن کی خرابی نہیں، فائر وال کا ریکارڈ پڑھیں
ایپلی کیشن وقت ختم ہونے کی اطلاع دیتی ہے، جو وجہ کے بارے میں کچھ نہیں بتاتی۔ فائر وال کا اپنا لاگ وہ جگہ ہے جہاں خارج کرنا یا بلاک ہونا ظاہر ہوتا ہے، اس لیے ڈیٹابیس اور ایپلی کیشن کے پتوں سے فلٹر کریں اور قبولیتوں کے ساتھ خارج ہونے بھی تلاش کریں۔خطرے کی روک تھام کے بلیڈ ایپلی کیشن کی سطح پر خرابی پیدا کیے بغیر پیکٹ خارج کر سکتے ہیں، اور لٹکنے والے استفسار کی یہی شکل ہے۔ لاگ میں خاموشی بھی معلومات ہے: یہ کسی ایسی چیز کی طرف اشارہ کرتی ہے جو لاگ نہیں کرتی، جیسے دوبارہ ترتیب۔
کلسٹر بھی چیک کریں۔ غلط ترتیب دیا گیا کلسٹر ایک ممبر کی اسٹیٹ ٹیبل میں سیشن رکھ سکتا ہے جبکہ پیکٹ دوسرے ممبر کے راستے جاتے ہیں، اس لیے جواب وہاں پہنچتے ہیں جہاں کوئی اسٹیٹ نہیں۔ ایسے لٹکنے بے ترتیب لگتے ہیں اور بوجھ سے متعلق نہیں ہوتے۔
کچھ بھی بدلنے سے پہلے دونوں سروں کا موازنہ کریں، اور پیکٹوں کی تعداد نہیں بلکہ آنے کی ترتیب کا موازنہ کریں:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcap443 پر TCP آپ کو اصل میں کتنا مہنگا پڑتا ہے
سرنگ کو TCP پر منتقل کرنے سے دوبارہ ترتیب کی علامت ختم ہو جاتی ہے، کیونکہ درمیانی باکس اب ترتیب شدہ بہاؤ دیکھتا ہے۔ لیکن یہ TCP کے اوپر TCP بھی پیدا کرتا ہے۔ بیرونی کنکشن وہی دوبارہ بھیجتا ہے جو اندرونی کنکشن پہلے ہی دوبارہ بھیج چکا ہے، اور ایک ہی نقصان تمام ملٹی پلیکس سیشن ایک ساتھ روک سکتا ہے۔ صاف راستے پر یہ نظر نہیں آتا۔ نقصان والے راستے پر علاج علامت سے بدتر ہے۔
متبادل مکمل طور پر رابطے کی عدم موجودگی ہو تو یہ تبادلہ قابل قبول ہے، اور اسے معمول سمجھ کر قبول کرنے کے بجائے مالک کے ساتھ استثنا کے طور پر درج کرنا چاہیے۔
ٹرانسپورٹ، پورٹ، نمونہ استفسار اور ناپا گیا نتیجہ، نیز تاریخ درج کریں۔ اس ریکارڈ کے بغیر اگلا انجینئر تجربہ دہراتا ہے، اور استثنا خاموشی سے معماری بن جاتا ہے۔
فیصلے کو قابلِ نظرثانی رکھیں
راستے کی تشخیص جلد پرانی ہو جاتی ہے۔ درمیانی باکس بدل دیا جاتا ہے، بلیڈ کی ترتیب بدلتی ہے، لنک اپ گریڈ ہوتا ہے، اور 443 پر TCP کی وجہ غائب ہو جاتی ہے جبکہ ترتیب رہتی ہے۔ استثنا پر نظرثانی کی تاریخ لگائیں اور وہ شرط بتائیں جو آپ کو UDP پر واپس جانے دے گی۔
دونوں ٹرانسپورٹ چھوٹے استفسار اور بڑے نتائج کے مجموعے کے ساتھ آزمائیں۔ دوبارہ ترتیب سائز پر منحصر لٹکنے کے طور پر ظاہر ہوتی ہے، جبکہ سننے والے کی خرابی دونوں سائز برابر روکتی ہے۔