استعلام قاعدة بيانات يتوقّف عبر IPsec: إعادة ترتيب UDP أم TCP؟
استعلام يتوقّف بعد مصافحة نظيفة يشير إلى داخل مسار النفق. ثلاثة شروط تحدد ما إذا كان يجب إصلاح المسار أو الرجوع إلى TCP على المنفذ 443.
استعلام يتوقّف بعد مصافحة TCP ليس مشكلة توجيه. أعطال التوجيه تُفشل المصافحة، لذا الجلسة التي تُنشأ ثم تصمت تشير إلى داخل المسار: الفحص، أو 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 فقط، وهذه مشكلة مستمع، وانتهاء المهلة قبل المصافحة يعني مرشّحًا أو مسارًا. لا شيء منهما يتحسّن بتغيير التغليف.
اكتب التصنيف في التذكرة أولًا. إنها أرخص خطوة وتزيل معظم فضاء البحث.
ثلاثة شروط تحدد UDP مقابل TCP
حركة IPsec المغلّفة تسير على UDP، وUDP يمنح المسار حرية إعادة الترتيب والإسقاط دون إبلاغ أحد. عندما تدفع إعادة الترتيب الحزم خارج نافذة منع الإعادة في النفق، تُسقط بصمت وتنتظر جلسة TCP الداخلية فقط. هذا هو الميكانيزم وراء مصافحة تنجح واستعلام لا يعود أبدًا.
إصلاح المسار أو الرجوع إلى TCP يعتمد على ثلاثة أمور. أولًا، هل هناك فقدان حزم حقيقي على المسار أم إعادة ترتيب فقط؟ ثانيًا، هل يمكنك تغيير مكان الفحص، أو استثناء هذا النفق من المكوّن الذي يعيد الترتيب؟ ثالثًا، هل الحمل حسّاس لنمط التوقف، مثل جلسات متعددة ومضاعفة تتشارك رابطًا واحدًا؟
إذا كان الجواب الأول فقدانًا والثاني لا،فإن TCP على المنفذ 443 هو البديل العملي. وإذا كان الجواب الثاني نعم، فأصلح المسار وأبقِ على UDP.
اقرأ سجل الجدار الناري، لا خطأ التطبيق
التطبيق يبلّغ عن انتهاء مهلة، وهذا لا يقول شيئًا عن السبب. سجل الجدار الناري نفسه هو حيث يظهر الإسقاط أو الحجب، لذا رشّح حسب عنواني قاعدة البيانات والتطبيق وابحث عن حالات الإسقاط كما تبحث عن القبول.وحدات منع التهديدات يمكنها إسقاط الحزم دون توليد خطأ على مستوى التطبيق، وهذا بالضبط شكل استعلام يتوقف. الصمت في السجل بيانات أيضًا: إنه يشير إلى شيء لا يسجّل، مثل إعادة الترتيب.
افحص العنقود أيضًا. العنقود المهيّأ خطأً قد يحتفظ بجلسة في جدول الحالة على عضو بينما تأخذ الحزم مسار عضو آخر، فتصل الردود حيث لا توجد حالة. تلك التوقفات تبدو عشوائية ولا ترتبط بالحمل.
قارن الطرفين قبل أن تغيّر أي شيء، وقارن ترتيب الوصول لا أعداد الحزم:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapما يكلّفك إياه TCP على المنفذ 443 فعليًا
نقل النفق إلى TCP يزيل عرَض إعادة الترتيب، لأن الوسيط الأوسط يرى الآن تدفقًا مرتّبًا. لكنه ينشئ TCP فوق TCP. الاتصال الخارجي يعيد إرسال ما أعاد الاتصال الداخلي إرساله أصلًا، وفقدان واحد قد يوقف كل جلسة مضاعفة دفعة واحدة. على مسار نظيف هذا غير مرئي. وعلى مسار سيّئ الفقدان يكون العلاج أسوأ من العرَض.
المقايضة مقبولة عندما يكون البديل هو انعدام الاتصال، وينبغي توثيقها كاستثناء له مالك بدلًا من استيعابها كأمر عادي.
سجّل النقل والمنفذ واستعلامًا نموذجيًا والنتيجة المقيسة، مع التاريخ. بدون ذلك السجل يعيد المهندس التالي التجربة، ويصبح الاستثناء بهدوء هو المعمارية.
أبقِ القرار قابلًا للمراجعة
تشخيص المسار يتقادم سريعًا. يُستبدل الوسيط الأوسط، وتتغير تهيئة الوحدة، ويُرقّى الرابط، ويختفي سبب TCP على المنفذ 443 بينما تبقى التهيئة. ضع تاريخ مراجعة على الاستثناء وسمِّ الشرط الذي يسمح بالعودة إلى UDP.
اختبر النقلين باستعلام صغير وبمجموعة نتائج كبيرة. إعادة الترتيب تظهر كتوقفات تعتمد على الحجم، بينما عطل المستمع يوقف الحجمين بالتساوي.