پرس‌وجوی پایگاه داده روی IPsec معلق می‌ماند: بازآرایی UDP یا TCP؟
پرس‌وجویی که پس از یک handshake تمیز معلق می‌ماند به درون مسیر تونل اشاره می‌کند. سه شرط تعیین می‌کند که مسیر اصلاح شود یا به TCP روی 443 بازگردیم.
پرس‌وجویی که پس از handshake TCP معلق می‌ماند مسئله مسیریابی نیست. خطاهای مسیر باعث شکست 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 یعنی فیلتر یا مسیر. هیچ‌کدام با تغییر کپسوله‌سازی بهتر نمی‌شود.
دسته‌بندی را اول در تیکت بنویسید. ارزان‌ترین گام است و بیشتر فضای جست‌وجو را حذف می‌کند.
سه شرطی که بین UDP و TCP تصمیم می‌گیرد
ترافیک کپسوله‌شده IPsec روی UDP حرکت می‌کند و UDP به مسیر آزادی بازآرایی و حذف می‌دهد بی‌آنکه به کسی بگوید. وقتی بازآرایی بسته‌ها را بیرون از پنجره ضدتکرار تونل می‌راند، آن‌ها بی‌صدا دور ریخته می‌شوند و نشست TCP درونی فقط منتظر می‌ماند. این همان سازوکاری است که پشت handshake موفق و پرس‌وجویی که هرگز بازنمی‌گردد قرار دارد.
اصلاح مسیر یا بازگشت به TCP به سه چیز بستگی دارد. نخست، آیا روی مسیر افت واقعی بسته وجود دارد یا فقط بازآرایی؟ دوم، آیا می‌توانید جای بازرسی را تغییر دهید یا این تونل را از مؤلفه‌ای که بازآرایی می‌کند مستثنا کنید؟ سوم، آیا بار کاری به الگوی توقف حساس است، مثلاً نشست‌های چندگانه‌ی چندپلکسی که یک پیوند را شریک‌اند؟
اگر پاسخ نخست افت باشد و دومی نه،TCP روی 443 همان جایگزین عمل‌گرایانه است. اگر پاسخ دوم بله باشد، مسیر را اصلاح کنید و UDP را نگه دارید.
رکورد فایروال را بخوانید، نه خطای برنامه را
برنامه پایان مهلت را گزارش می‌کند که هیچ چیزی درباره علت نمی‌گوید. گزارش خود فایروال جایی است که حذف یا مسدودسازی ظاهر می‌شود، پس بر اساس نشانی‌های پایگاه داده و برنامه فیلتر کنید و هم دورریزها و هم پذیرش‌ها را بجویید.ماژول‌های جلوگیری از تهدید می‌توانند بسته‌ها را بدون تولید خطا در سطح برنامه دور بریزند، و این دقیقاً شکل پرس‌وجویی است که معلق می‌ماند. سکوت در گزارش هم داده است: به چیزی اشاره می‌کند که ثبت نمی‌شود، مانند بازآرایی.
کلاستر را هم بررسی کنید. کلاستر بدتنظیم می‌تواند نشستی را در جدول وضعیت روی یک عضو نگه دارد در حالی که بسته‌ها مسیر عضو دیگری را می‌روند، پس پاسخ‌ها جایی می‌رسند که وضعیتی وجود ندارد. چنین توقف‌هایی تصادفی به نظر می‌رسند و با بار همبستگی ندارند.
پیش از هر تغییری دو سر را مقایسه کنید و ترتیب رسیدن را بسنجید، نه تعداد بسته‌ها را:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapTCP روی 443 واقعاً چه هزینه‌ای برای شما دارد
بردن تونل به TCP نشانه بازآرایی را حذف می‌کند، چون جعبه میانی اکنون جریانی مرتب می‌بیند. اما TCP روی TCP هم می‌سازد. اتصال بیرونی چیزی را دوباره می‌فرستد که اتصال درونی پیش‌تر دوباره فرستاده است، و یک افت می‌تواند همه نشست‌های چندپلکسی را همزمان متوقف کند. روی مسیر تمیز این نامرئی است. روی مسیر پرافت، درمان بدتر از نشانه است.
این معاوضه زمانی پذیرفتنی است که جایگزین نداشتن اتصال باشد، و باید به‌عنوان استثنایی با یک مسئول مستند شود نه اینکه به‌عنوان وضع عادی پذیرفته شود.
حامل، پورت، یک پرس‌وجوی نمونه و نتیجه اندازه‌گیری‌شده را همراه با تاریخ ثبت کنید. بدون این رکورد مهندس بعدی آزمایش را تکرار می‌کند و استثنا بی‌صدا به معماری تبدیل می‌شود.
تصمیم را قابل بازبینی نگه دارید
تشخیص مسیر بد کهنه می‌شود. جعبه میانی عوض می‌شود، پیکربندی ماژول تغییر می‌کند، پیوند ارتقا می‌یابد و دلیل TCP روی 443 از بین می‌رود در حالی که پیکربندی می‌ماند. روی استثنا تاریخ بازبینی بگذارید و شرطی را نام ببرید که بازگشت به UDP را ممکن می‌کند.
هر دو حامل را با پرس‌وجوی کوچک و مجموعه نتایج بزرگ بیازمایید. بازآرایی به‌صورت توقف‌های وابسته به اندازه ظاهر می‌شود، در حالی که نقص شنونده هر دو اندازه را یکسان متوقف می‌کند.