Назад | Перейти на главную страницу

Как отлаживать ошибочные контрольные суммы / перевернутые биты в TCP-пакетах?

Веб-приложение, которое мы обслуживаем недавно, столкнулось с очень странной проблемой: три из четырех виртуальных машин на двух физических хостах не смогли подключиться к серверу нашего поставщика платежей через HTTPS. Отладка этой проблемы заставила меня совершить интересный тур по стеку OSI:

  1. на уровне приложения казалось, что запрос HTTPS истек.
  2. с помощью openssl s_client, Я обнаружил, что подтверждение SSL не удалось
  3. Сбрасывая трафик с помощью tcpdump и проверяя его с помощью Wireshark, я заметил, что из-за неудачных рукопожатий все пакеты с сервера после начального SYN / ACK имели недопустимые контрольные суммы TCP. Сравнивая содержимое пакета с успешным рукопожатием, я обнаружил, что по крайней мере один бит перевернулся. Затем сервер пытается повторно передать пакеты (снова с недопустимыми контрольными суммами) и закрывает соединение через 60 секунд.

Ни наш поставщик платежей, ни наша хостинговая компания не помогли в диагностике этой проблемы. К счастью, проблема исчезла через пару часов.

Однако это «решение» меня очень огорчает. Я бы хотел знать:

  1. каковы возможные причины такого поведения?
  2. как можно дальше диагностировать эту проблему, если она повторится в будущем?

Виртуальные машины работают под управлением Debian 7 на KVM.

Итак, используя эту статью как ссылку: https://www.networkdatapedia.com/single-post/2017/09/13/TCP-Checksum-Error-Case-Study

Постараюсь ответить и уточнить:

  1. каковы возможные причины такого поведения?

Есть несколько возможных причин:

  • Выгрузка контрольной суммы TCP. Как уже упоминалось, это метод, при котором ЦП не вычисляет контрольную сумму TCP, а оставляет это сетевой карте. Сетевая карта может вычислить его неправильно.
  • неисправное устройство 3-го уровня. Это должно быть на уровне 3, поскольку ошибки контрольной суммы TCP могут возникать после успешной проверки CRC Ethernet, которая является более надежной, чем контрольная сумма TCP. Таким образом, вы можете устранить неисправные кабели или разъемы.
  • человек в манипуляции с полезной нагрузкой среднего пакета. Это очень маловероятно, поскольку человек посередине может вычислить правильную контрольную сумму TCP и поместить ее в пакет.
  1. как можно дальше диагностировать эту проблему, если она повторится в будущем?

используя упомянутую статью в качестве справочника, вы должны настроить как минимум два местоположения захвата трафика, которые должны включать виртуальную машину, а также интерфейсы голого железа / маршрутизатора.

В зависимости от сетевой архитектуры вы можете обнаружить неисправный сетевой компонент L3. К сожалению, сеть может быть неисправной в восходящем направлении, поэтому убедитесь, что пакеты заглушаются, когда они уходят и входят в вашу контролируемую среду, чтобы убедиться.

Что касается моего личного опыта работы в сети - полностью насыщенная сеть может привести к тому, что такие протоколы, как SSH или HTTPS, не смогут установить соединение. Убедитесь, что доступной полосы пропускания достаточно и что соответствующие хосты могут своевременно отвечать.