Conntrack NEW на пакете ACK: что это не доказывает
ACK с меткой NEW означает, что у трекера не было подходящего состояния, а не что VPN открыл сеанс. Прочитайте hook, tuple и окно захвата.
В журнале межсетевого экрана есть строка, которую вы не ожидали: пакет ACK, состояние conntrack NEW, адрес источника не ваш, порт назначения открыт. Соблазн — прочитать это как новое входящее соединение, которое никто не разрешал. То, что строка действительно говорит, уже: когда этот пакет дошёл до этого hook, у трекера не было подходящего состояния, и пакет нёс ACK. Это два факта о двух разных вещах, и ни один из них не является полной записью рукопожатия. Вот порядок, который я прохожу, прежде чем сделать вывод.
Начните с пакета, а не с вердикта
Разделите наблюдения, прежде чем их интерпретировать. Флаги TCP описывают этот пакет, состояние трекера описывает, что он знал на этом hook, а ваш захват описывает только то окно, которое вы записали.
Смешивание этих трёх — это способ, которым ACK превращается в «провайдер кого-то впустил».
Что NEW на самом деле означает на hook
сопоставление conntrack в iptables документирует NEW как пакет, начинающий соединение, или пакет, связанный с соединением, которое ещё не видело трафика в обе стороны. ESTABLISHED означает, что трекер видел пакеты в обе стороны. Ни одно из определений не говорит, что пакет был SYN, и не говорит, что он пришёл без истории.
Трекер, который начинает наблюдать поток с середины, классифицирует следующий пакет по тому, что знает, а это может быть ничего. Это утверждение о памяти трекера, а не о намерении удалённого хоста.
Свободное отслеживание объясняет большинство сюрпризов с ACK
Ядро документирует nf_conntrack_tcp_loose, что позволяет трекеру подхватывать TCP-соединения, начало которых он не видел. При значении по умолчанию ACK из середины потока может быть принят как установившийся поток. Отключите это, и тот же пакет с большей вероятностью будет классифицирован как INVALID, а не NEW. Оба результата описывают правила трекера, а не историю приложения.
Поэтому проверьте эту настройку, прежде чем строить теорию на метке.
Исключите скучные причины в этом порядке
Большинство событий NEW-на-ACK, за которыми я следил, закончились одной из этих причин, и все они дёшевы в проверке:
- Таблица conntrack была очищена, или трекер был перезапущен.
- Хост был перезагружен, или поток перешёл в другой namespace или на другое устройство.
- Асимметричная маршрутизация вывела SYN по пути, который вы не захватываете.
- NAT переписал tuple, поэтому запись больше не соответствует прочитанному.
- Захват начался поздно и так и не увидел начала.
Каждая из них убирает более ранние пакеты из поля зрения трекера, оставляя более поздние нетронутыми. Перезагрузку или очистку таблицы проще всего подтвердить по uptime и журналам. Асимметричная маршрутизация выглядит как односторонний захват. NAT — самая коварная, потому что tuple, который сохранил трекер, не тот tuple, что напечатан в журнале.
Запишите, какие из них вы исключили и как, прежде чем идти дальше.
Прочитайте tuple, интерфейс и hook
Запись conntrack ключуется адресами, портами и протоколом, поэтому любой перевод меняет, какая запись совпадает. Запишите также интерфейс и hook, потому что пакет, увиденный на неверном интерфейсе или после другой цепочки, говорит, что путь не тот, что на схеме. Когда событие связано с VPN, решите, смотрите ли вы на внутренний пакет или на внешний носитель. Затем сравните с тем, что шлюз записал для того же tuple из пяти частей.
Два противоречащих взгляда на один поток информативнее любого из них по отдельности.
Когда стоит эскалировать
Эскалируйте, когда можете показать доступный сервис, которого не должно быть, вместе с потоком, политикой, которая это разрешила, и доказательствами с обеих сторон. Не сообщайте об ошибке провайдера на основании одной метки состояния или одного частичного захвата, потому что такое сообщение будет закрыто именно тем объяснением, которое вы только что прочитали. Если сервис действительно открыт, владелец этой границы — правильный человек, чтобы это исправить, и делегированное сопоставление портов или случайный слушатель вероятнее, чем ошибка.
Затем закройте пробел в видимости, из-за которого один пакет выглядел как целый сеанс.