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

Все началось в январе 2026 года с тикета техподдержки, который звучал обманчиво просто: поды периодически не могут достучаться до сервера API Kubernetes. Ошибка выглядела как знакомый тайм-аут. Клиент уже исключил собственные операторы. Ни один из нас еще не знал, что мы имеем дело с тремя отдельными багами — на трех разных уровнях стека, — которые сошлись вместе, чтобы вызвать один и тот же симптом.

К тому моменту, когда все закончилось, около 800 разработчиков на недели были заблокированы в развертывании продакшна, а кластеры GKE по всему региону europe-west остановились. В спешке исправляя проблему, мы задействовали инженеров Google Kubernetes Engine (GKE), Private Service Connect, сетевых подсистем, hostnet, ядра и сообщества разработчиков ядра Linux, которые вместе обнаружили не одну, а три разные первопричины. И окончательное исправление было выпущено не в виде изменения конфигурации или флажка функции, а в виде патча для самого ядра Linux.

Это история о том, как мы к этому пришли.

Часть первая: Тревожный звонок, который не умолкал

Клиент управлял большой многокластерной средой GKE в регионе Google Cloud europe-west. Их кластеры использовали Private Service Connect — механизм Google Cloud для приватного предоставления доступа к плоскости управления GKE — и имели богатую экосистему рабочих нагрузок системного уровня: сканеры безопасности Twistlock, External Secrets Operator для управления секретами, Cilium для сетевых политик, а также несколько внутренних операторов Kubernetes.

Первые ошибки появились в одном из их кластеров приемочного тестирования (UAT) в europe-west, а несколько дней спустя — во втором кластере в том же регионе. Они выглядели следующим образом:

Логи приложений — поды в нескольких пространствах имен

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

Проблема сохраняется даже после полного уменьшения масштаба External Secrets Operator. Ошибки поступают от рабочих нагрузок клиента и системных подов, к которым мы не прикасались.

Растущий список подозреваемых

Когда поступает такой запрос, первое инстинктивное желание — спросить: что изменилось? Хронология клиента предоставила нам несколько кандидатов, и мы методично проработали их.

Кастомный оператор (kopf): Исключен сразу — ошибки начались на неделю раньше развертывания и продолжались после отключения.

Кастомный оператор (kopf): Исключен сразу — ошибки начались на неделю раньше развертывания и продолжались после отключения.

External Secrets Operator: Удален полностью по запросу клиента. Тайм-ауты продолжились в рабочих нагрузках клиента, зависящих от подключения к плоскости управления Kubernetes (KCP), а также во внутренних системных подах кластера.

External Secrets Operator: Удален полностью по запросу клиента. Тайм-ауты продолжились в рабочих нагрузках клиента, зависящих от подключения к плоскости управления Kubernetes (KCP), а также во внутренних системных подах кластера.

Агенты безопасности: Удалены. Тот же результат. Теперь мы наблюдали, как системные компоненты Kubernetes не могут связаться с собственной плоскостью управления.

Агенты безопасности: Удалены. Тот же результат. Теперь мы наблюдали, как системные компоненты Kubernetes не могут связаться с собственной плоскостью управления.

Переполнение таблицы conntrack: Одна из гипотез заключалась в том, что слишком много полуоткрытых соединений забивают таблицу отслеживания соединений ОС на узлах плоскости управления. Мы проверили. Таблица conntrack была заполнена примерно на 50% от максимального значения по умолчанию в 1,3 млн записей. Даже близко не переполнение.

Переполнение таблицы conntrack: Одна из гипотез заключалась в том, что слишком много полуоткрытых соединений забивают таблицу отслеживания соединений ОС на узлах плоскости управления. Мы проверили. Таблица conntrack была заполнена примерно на 50% от максимального значения по умолчанию в 1,3 млн записей. Даже близко не переполнение.

Перегрузка плоскости управления: Мы увеличили размер ВМ KCP. Задержки kube-apiserver выглядели нормальными. Никаких улучшений в отношении тайм-аутов.

Перегрузка плоскости управления: Мы увеличили размер ВМ KCP. Задержки kube-apiserver выглядели нормальными. Никаких улучшений в отношении тайм-аутов.

Что делало этот случай по-настоящему странным, так это масштаб. Мы подтвердили, что тайм-ауты происходят в пяти разных кластерах, затрагивая DaemonSets, Deployments и системные поды. Внешние клиенты — ноутбуки разработчиков, сборщики GitHub Actions — также упирались в ту же стену. Это была не сломанная рабочая нагрузка. Что-то было не так с путем между всеми компонентами и сервером API.

Хронология на данный момент

День 1: Появляются первые ошибки тайм-аута ввода-вывода (Один из кластеров UAT в europe-west3. Эпизодические, легко отмахнуться.)

День 1: Появляются первые ошибки тайм-аута ввода-вывода (Один из кластеров UAT в europe-west3. Эпизодические, легко отмахнуться.)

День 10: Ошибки становятся постоянными (Частота значительно возрастает. Проблему больше нельзя игнорировать.)

День 10: Ошибки становятся постоянными (Частота значительно возрастает. Проблему больше нельзя игнорировать.)

День 15: Тикет эскалирован — зарегистрирован баг P0 (Подтверждено влияние на несколько кластеров. Заблокировано около 800 разработчиков. Релизы в продакшн заморожены. Начинается официальная эскалация.)

День 15: Тикет эскалирован — зарегистрирован баг P0 (Подтверждено влияние на несколько кластеров. Заблокировано около 800 разработчиков. Релизы в продакшн заморожены. Начинается официальная эскалация.)

День 20: Все очевидные подозреваемые исключены (Кастомный оператор, агенты безопасности, переполнение conntrack, изменение размера плоскости управления — все сняты с подозрений.)

День 20: Все очевидные подозреваемые исключены (Кастомный оператор, агенты безопасности, переполнение conntrack, изменение размера плоскости управления — все сняты с подозрений.)

День 22: Собраны дампы сетевых пакетов (Захват трафика выполнен одновременно на сетевой карте (NIC) узла плоскости управления и изнутри контейнера kube-api. Расследование вступает в свою самую критическую фазу.)

День 22: Собраны дампы сетевых пакетов (Захват трафика выполнен одновременно на сетевой карте (NIC) узла плоскости управления и изнутри контейнера kube-api. Расследование вступает в свою самую критическую фазу.)

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

Часть вторая: Поиск призрака в проводе

Чтобы понять, что показали дампы пакетов, вам сначала нужно понять архитектуру, через которую проходит под GKE при выполнении вызова API. В кластере GKE на базе Private Service Connect путь оказывается обманчиво длинным для того, что выглядит как локальное соединение.

(Примечание по форматированию: рассмотрите возможность включения сюда диаграммы потока Под → kube-apiserver: Под -> Рабочий узел -> PSC NAT+Прокси -> ILB -> Сетевая карта ВМ KCP -> kube-apiserver)

Ключевым компонентом здесь является Private Service Connect. Когда под обращается по адресу 1.2.3.4:443, он на самом деле не идет напрямую к плоскости управления; этот IP-адрес является виртуальной конечной точкой. Соединение перехватывается сетевой инфраструктурой Google, преобразуется с помощью NAT через конечную точку Private Service Connect, проходит через внутренний балансировщик нагрузки Network Load Balancer с пробросом трафика и в конечном итоге доставляется на виртуальную машину KCP, где Envoy действует как локальный прокси перед фактическим процессом kube-apiserver.

Private Service Connect добавляет заголовок протокола прокси к каждому новому соединению, чтобы kube-apiserver видел реальный IP-адрес клиента. Это окажется важным в дальнейшем.

Что показали пакеты

Когда мы выполнили одновременный захват на сетевой карте ВМ KCP (интерфейс PIGv, программируемая виртуальная сетевая карта Google) и изнутри контейнера kube-apiserver, мы увидели поразительную картину.

SYN-пакеты от подов поступали на сетевую карту ВМ KCP. Они доходили до этого уровня. Но вместо получения SYN-ACK в ответ — ожидаемого второго шага рукопожатия TCP — клиент получал несоответствующий ACK. Не RST. Не тишину. ACK, который логически принадлежал другому, более раннему соединению.

Wireshark, анализатор сетевых протоколов, помечал эти потоки меткой, которая поначалу казалась безобидной: «TCP Port numbers reused» (Повторно используемые порты TCP).

Wireshark — поток пакетов, показывающий неудачное рукопожатие

Паттерн был очевиден. Что-то заставляло ВМ KCP отвечать на свежий SYN пакетом ACK, который принадлежал другому соединению, завершившемуся несколько минут назад. Старое соединение использовало тот же исходный порт (53426 в примере выше), и ВМ KCP так и не освободила его полностью.

«Сервер KCP отправляет FIN,ACK; клиент отвечает FIN,ACK, а затем ACK. Но KCP получает ACK до FIN,ACK. Сервер KCP никогда не отправляет ACK на FIN,ACK — происходит непрерывная ретрансляция ACK. RST не очищает состояние».

Всплеск «Недействительных ACK»

Пока одна группа в ходе расследования анализировала дампы пакетов (т.е. pcap), другая команда изучала внутренние метрики для инфраструктуры Private Service Connect — в частности, коммутатор пакетов пользовательского пространства (USPS), уровень программной коммутации Google, который обрабатывает NAT и внедрение заголовков прокси-протокола для соединений Private Service Connect.

Они обнаружили тревожную вещь в метриках Andromeda, сетевой инфраструктуры Google. Счетчик с именем «Proxy protocol drop: invalid ACK packet» оставался на нуле в течение нескольких месяцев, а затем, в феврале 2026 года, резко подскочил до нескольких отброшенных пакетов в секунду в затронутых регионах europe-west.

Эта дата совпала с развертыванием новой версии USPS. Эта версия включала изменение, которое исправляло другую ошибку, но по какой-то причине оно изменило то, как Private Service Connect обрабатывает определенный класс пакетов.

Challenge ACK: механизм из RFC 5961

Чтобы понять следующую часть головоломки, нам нужно поговорить о механизме безопасности TCP под названием challenge ACK, определенном в RFC 5961.

Представьте, что соединение TCP закрылось — прошло через процедуру FIN/ACK и завершилось. Серверная сторона (в данном случае ВМ KCP) может еще некоторое время помнить порядковые номера соединения в своем автомате состояний TCP. Теперь представьте, что вскоре после этого приходит новое клиентское соединение с тем же исходным и целевым портом (тем же 5-туплем). С точки зрения ядра это может быть устаревший пакет от старого соединения, или это может быть злоумышленник, пытающийся внедрить данные в сеанс, который, по мнению ядра, все еще открыт.

RFC 5961 гласит: когда вы получаете SYN, соответствующий сохраненному состоянию существующего или недавно закрытого соединения, не принимайте его вслепую. Отправьте challenge ACK — подтверждение, содержащее последний известный порядковый номер старого соединения. Если новый клиент легитимен, он увидит этот неожиданный ACK, поймет, что соединение устарело, и отправит RST для очистки состояния. Затем сервер нормально принимает следующий SYN.

Поток challenge ACK — как это должно работать

Этот механизм работает идеально, когда challenge ACK пропускается. Но именно это блокировало новое изменение USPS.

Виновник: благая цель исправления

Изменение в USPS было разработано для устранения реальной проблемы безопасности при обработке прокси-протокола в Private Service Connect. Часть его эффекта заключалась в отбросе пакетов, классифицируемых как «недействительные ACK» во время фазы рукопожатия соединения, в частности ACK, которые прибывали до отправки начального SYN-ACK, что в нормальных условиях является аномалией.

К сожалению, challenge ACK выглядят точно так же: они поступают от сервера до завершения нового рукопожатия в ответ на SYN. С точки зрения новой логики USPS они выглядели как недействительные пакеты. Они отбрасывались безмолвно.

Почему это сломало именно GKE: Private Service Connect использует NAT для совместного использования одной публичной конечной точки множеством клиентских подов. Это означает, что множество разных подов — работающих на разных узлах из разных пространств имен — в конечном итоге могут использовать один и тот же исходный порт после NAT, что создает высокую частоту коллизий 5-туплей. Механизм challenge ACK срабатывал гораздо чаще, чем в сценарии с обычным прямым соединением. Исправление USPS не вводило challenge ACK — они были там всегда. Оно ввело их отбрасывание, что нарушило поток, на который стек TCP GKE молчаливо полагался для очистки устаревшего состояния.

Смягчение последствий: откат изменения

В феврале мы откатили изменение USPS, восстановив старое поведение, при котором challenge ACK пропускались, а не отбрасывались. Частота «Proxy protocol drop: invalid ACK packet» почти сразу упала обратно до базового уровня.

К началу марта 2026 года клиент подтвердил, что все затронутые кластеры восстановились. Больше никаких ошибок тайм-аута.

Но откат не был исправлением. Это был пластырь. Он восстановил поведение, от которого система зависела случайным образом. Более глубокий вопрос — почему ВМ KCP находилась в состоянии FIN_WAIT_2 более двух минут в первую очередь? — оставался абсолютно без ответа.

Этот вопрос привел к Части 3. И именно там все стало по-настоящему странным.

Часть третья: три ошибки, одно место преступления

Смягчение последствий выиграло нам время, но оставило висеть в воздухе вопрос: почему ВМ KCP удерживала соединения в состоянии FIN_WAIT_2 так долго? Корректно работающий стек TCP обрабатывает FIN, подтверждает его и закрывает соединение. ВМ KCP не смогла этого сделать, оставив полуоткрытые соединения, которые сохранялись более двух минут — достаточно долго, чтобы порт был повторно использован уровнем NAT Private Service Connect и чтобы вызвать сценарий challenge ACK, который мы обнаружили.

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

Ошибка № 1: переупорядочивание пакетов на PIGv

Первая часть была обнаружена путем тщательного анализа одновременных дампов в двух точках: на хост-сетевой карте ВМ KCP (внутри физического хоста, на котором запущена ВМ) по сравнению с PIGv — виртуальной сетевой картой, видимой изнутри ВМ.

На уровне сетевого адаптера узла пакеты поступали в идеальном порядке. Но к тому моменту, как они проходили через USPS и появлялись на PIGv, они незаметно менялись местами.

Это происходит из-за особенностей обработки потоков без предварительной регистрации в Private Service Connect. Когда Private Service Connect перехватывает новый, еще не знакомый ему поток («промах» — miss), он пропускает этот пакет по более медленному пути, который добавляет заголовок протокола прокси и настраивает состояние NAT. Последующие пакеты в том же потоке идут по быстрому пути. Последствие: пакет FIN или RST, принадлежащий потоку на этапе закрытия, может прибыть с небольшим нарушением порядка относительно последовавших за ним ACK.

Что на самом деле получила ВМ KCP (измененный порядок последовательности)

Из-за изменения порядка FIN клиента оказался после того, как сервер уже отправил собственный FIN. Сервер перешел в состояние FIN_WAIT_1, а затем в FIN_WAIT_2 после получения ACK сервера от клиента. Но затем прибыл собственный FIN клиента — и ядро сервера проигнорировало его.

Ошибка № 2: полузакрытие Envoy и зависший таймер

Почему операционная система не могла очистить ресурсы самостоятельно? В ядре Linux есть параметр tcp_fin_timeout, который регулирует именно это: как долго сокет в состоянии FIN_WAIT_2 ждет перед принудительным закрытием. На ВМ KCP этот параметр был установлен равным 60 секундам.

Но tcp_fin_timeout применим только к овдовевшим (orphaned) сокетам — сокетам, которые в данный момент не удерживаются открытыми ни одним процессом. Envoy, прокси-сервер, работающий перед kube-apiserver на ВМ KCP, выполнял полузакрытие: он вызывал shutdown(SHUT_WR), который закрывает сторону записи соединения, но оставляет сокет открытым, чтобы он все еще мог принимать данные. Это абсолютно корректное поведение TCP, и именно так должна работать корректная полудуплексная терминация.

Побочный эффект: пока Envoy удерживал сокет с помощью SHUT_WR, ядро не считало его овдовевшим. Таймер tcp_fin_timeout никогда не запускался. Сокет оставался в состоянии FIN_WAIT_2 бесконечно долго, ожидая FIN клиента, который он никогда не смог бы корректно обработать.

Состояние сокета ядра — зафиксировано через netstat прямо перед новым соединением

Ошибка № 3: молчаливый сбой ядра Linux

Но все еще не хватало одного элемента. Даже с учетом измененного порядка FIN, исправное ядро все равно должно было обработать полученный FIN в состоянии FIN_WAIT_2 и перейти в TIME_WAIT. Сокет в конечном итоге должен был закрыться. Почему этого не происходило?

Это привело нас к глубокому изучению реализации конечного автомата TCP в Linux. Когда измененный FIN клиента прибыл на ВМ KCP, для его обработки была вызвана функция ядра tcp_ack(). И здесь, в версии ядра 6.1 (на которой была основана Container-Optimized OS (COS), работающая на ВМ KCP), содержалась ошибка.

RFC 5961 добавил более строгую проверку допустимых номеров ACK — в частности, ACK мог считаться действительным, даже если он был немного «устаревшим» (в пределах окна номеров последовательностей), чтобы справляться с переупорядочиванием в сети. Но в ядре 6.1 существовал путь выполнения кода, где tcp_ack() возвращал ноль, указывая на то, что «этот пакет не был полностью обработан», когда он сталкивался с устаревшим ACK, попадающим в допустимое окно RFC 5961. Вызывающий код tcp_ack() в пути обработки FIN проверил это возвращаемое значение, увидел ноль и сделал… ничего. FIN был получен и молча отброшен.

Коммит ядра Linux, исправивший эту проблему (в основной ветке)

Ошибка существовала со времен ядра 6.1 и уже была исправлена в ядре 6.9.7, однако ВМ KCP в GKE работали на сборках COS на базе 6.1 и 6.6. Исправление нужно было бэкпортировать и выпустить в качестве обновления образа COS.

Как объединились три ошибки

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

Только ошибка № 1: изменение порядка пакетов вызывает небольшие сбои, но ядро обычно все равно в конечном итоге обрабатывает FIN и освобождает ресурсы, просто медленнее, чем нужно.

Только ошибка № 1: изменение порядка пакетов вызывает небольшие сбои, но ядро обычно все равно в конечном итоге обрабатывает FIN и освобождает ресурсы, просто медленнее, чем нужно.

Только ошибка № 2: полузакрытие Envoy — абсолютно корректное поведение. Проблема возникает только в том случае, если FIN никогда не обрабатывается должным образом.

Только ошибка № 2: полузакрытие Envoy — абсолютно корректное поведение. Проблема возникает только в том случае, если FIN никогда не обрабатывается должным образом.

Только ошибка № 3: неспособность ядра обрабатывать старые, но допустимые ACK приводила бы к зависанию некоторых соединений, но влияние было бы ограниченным без давления повторного использования портов со стороны NAT Private Service Connect.

Только ошибка № 3: неспособность ядра обрабатывать старые, но допустимые ACK приводила бы к зависанию некоторых соединений, но влияние было бы ограниченным без давления повторного использования портов со стороны NAT Private Service Connect.

Все три вместе: изменение порядка приводит к тому, что FIN прибывает не по порядку; ошибка ядра мешает его обработке; SHUT_WR от Envoy предотвращает срабатывание таймера; сокет остается в состоянии FIN_WAIT_2 бесконечно долго. NAT Private Service Connect повторно использует порт. Отправляется ACK-вызов (challenge ACK). Исправление в USPS отбрасывает его. Соединение завершается ошибкой.

Все три вместе: изменение порядка приводит к тому, что FIN прибывает не по порядку; ошибка ядра мешает его обработке; SHUT_WR от Envoy предотвращает срабатывание таймера; сокет остается в состоянии FIN_WAIT_2 бесконечно долго. NAT Private Service Connect повторно использует порт. Отправляется ACK-вызов (challenge ACK). Исправление в USPS отбрасывает его. Соединение завершается ошибкой.

Решение: комплекс мер из трех частей

Для устранения этой проблемы потребовались действия на трех разных уровнях, согласованные между несколькими командами в течение нескольких недель:

Немедленное смягчение последствий (февраль 2026 г.): откат изменений в USPS. Восстановлено прежнее поведение, при котором ACK-вызовы пересылались, а не отбрасывались. Кластеры клиентов восстановились к началу марта.

Немедленное смягчение последствий (февраль 2026 г.): откат изменений в USPS. Восстановлено прежнее поведение, при котором ACK-вызовы пересылались, а не отбрасывались. Кластеры клиентов восстановились к началу марта.

Исправление корректности: заменяющее изменение для правильной обработки сценария ACK-вызова на уровне протокола прокси Private Service Connect, вместо простого возврата к старому поведению отбрасывания. В набор тестов был добавлен тест PacketDrill для предотвращения регрессий.

Исправление корректности: заменяющее изменение для правильной обработки сценария ACK-вызова на уровне протокола прокси Private Service Connect, вместо простого возврата к старому поведению отбрасывания. В набор тестов был добавлен тест PacketDrill для предотвращения регрессий.

Устранение первопричины — патч ядра Linux: основной патч («net: tcp: accept old ack during closing»), автор Эрик Дюмазе (Eric Dumazet). Включен в Linux 6.9.7. Бэкпортирован в ветки LTS 6.6.y и 6.1.y — поставляется в GKE 1.33.5 и более поздних версиях. Ошибка полностью устранена на уровне ОС для всех версий GKE, использующих эти образы COS.

Устранение первопричины — патч ядра Linux: основной патч («net: tcp: accept old ack during closing»), автор Эрик Дюмазе (Eric Dumazet). Включен в Linux 6.9.7. Бэкпортирован в ветки LTS 6.6.y и 6.1.y — поставляется в GKE 1.33.5 и более поздних версиях. Ошибка полностью устранена на уровне ОС для всех версий GKE, использующих эти образы COS.

Что отличало этот случай

Большинство сетевых проблем решаются на одном уровне. Вы находите неправильно настроенное правило брандмауэра, исчерпанный пул соединений или неверно рассчитанный MTU. Вы исправляете это и идете дальше. Этот случай был другим, потому что симптом — тайм-аут ввода-вывода при соединении, которое так и не было завершено, — оставался неизменным, независимо от того, рассматривали ли вы уровень Private Service Connect, конечный автомат TCP в ядре или управление соединениями в Envoy. У каждого уровня было правдоподобное объяснение, и каждое объяснение было неполным.

То, что в конечном итоге помогло разобраться, — это дисциплина одновременного захвата пакетов в нескольких точках пути. Без захвата трафика на сетевой карте хоста, PIGv и внутри контейнера одновременно мы бы никогда не увидели переупорядочивание. Без сопоставления этих pcap-файлов со всплеском метрик USPS 18 февраля мы бы никогда не обнаружили отброшенные пакеты challenge ACK. И без воспроизведения проблемы в лабораторных условиях мы бы никогда не нашли ошибку в ядре, из-за которой состояние FIN_WAIT_2 становилось постоянным.

Еще одна вещь, которая помогла в работе, — это команда. В течение двух недель свой вклад внесли инженеры из семи или восьми различных областей: сетевые технологии GKE, инфраструктура Private Service Connect, Hostnet, Andromeda, KCP и, в конечном итоге, сообщество разработчиков ядра. Ни один человек не смог бы удержать все это в голове. Заметки по делу, общий трекер ошибок, тщательно собранные pcap-файлы — все это стало связующим звеном, которое позволило распределенной команде работать как единое целое.

В конце концов, клиент вернулся к работе в продакшене. Ядро получило более качественное исправление ошибки. А остальные из нас получили очень поучительную историю о том, почему переупорядочивание пакетов, полузакрытые сокеты и благие намерения в патчах безопасности никогда не должны оказываться в одном месте в одно и то же время.

Этот блог основан на реальных данных из анонимизированного обращения в службу поддержки и внутренних отчетов об ошибках. Упомянутое исправление ядра Linux — это коммит 795a7dfbc3d9, автором которого является Эрик Дюмазе (Eric Dumazet). Особая благодарность инженерам из GKE, Private Service Connect, Hostnet, Andromeda, COS и сообществу разработчиков сетевых технологий Linux, чья работа сделала это решение возможным.