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