Запит до бази даних зависає через 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.
Перевіряйте обидва транспорти малим запитом і великим набором результатів. Перевпорядкування проявляється як зависання, залежні від розміру, а збій слухача однаково зупиняє обидва розміри.