Почему одного шифрования недостаточно против повторно отправленного пакета
Старый пакет сохраняет действительный тег аутентификации, поэтому целостность никогда не доказывает свежесть. Состояние последовательности и окно получателя делают эту работу.
Защищённые пакеты не истекают криптографически, поэтому пакет, действительный пять минут назад, действителен и сейчас, ведь шифрование и защита целостности ничего не говорят о том, когда были созданы байты. Атакующему, который может перехватить и повторно отправить трафик, не нужно взламывать шифр. Поэтому каждый серьёзный туннельный протокол несёт состояние последовательности рядом со своими ключами.
Механизм невелик, и его отказы легко спутать с потерей пакетов.
Действительный шифротекст — не свежий шифротекст
Аутентификация отвечает на один вопрос: пришли ли эти байты неизменными от владельца ключа. Она не отвечает, видит ли получатель их впервые. Повторно отправленный пакет безупречно проходит первую проверку, и именно поэтому одна проверка целостности не может остановить повтор, и поэтому протоколу нужно второе правило о приёме. Получатель, который только аутентифицирует, не имеет защиты от атакующего с записью.
Это правило дёшево реализовать и дёшево сформулировать: принять данный защищённый пакет один раз, под данным ключом. Всё остальное в этой области следует из того, как реализация отслеживает этот один раз.
Чтение отбрасывания из-за повтора как ошибки расшифровки уводит вас совершенно не в ту подсистему.
Номер последовательности и окно
IPsec ESP несёт номер последовательности, а получатель держит скользящее окно недавно принятых значений, причём спецификация ESP описывает размер окна по умолчанию и возможность его расширить. WireGuard идёт другим путём: счётчик на каждый ключ и явная проверка против него. Ни одна из схем не предполагает, что пакеты приходят по порядку, потому что реальные сети их переупорядочивают. Обе терпят переупорядочивание, и ни одна не терпит повторения.
Именно окно делает такую терпимость возможной. Пакет чуть позади наибольшего увиденного значения ещё может быть принят, если его не принимали раньше; пакет далеко позади или тот, чьё место уже отмечено, отбрасывается. Увеличьте окно — и вы терпите больше переупорядочивания ценой большего состояния на ассоциацию.
Диагностические счётчики показывают, в каком вы случае. Отбрасывания из-за повтора увеличивают определённый счётчик, а не общую ошибку, и чтение этого счётчика — первое полезное наблюдение.
nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer
Состояние принадлежит ключу, а не хосту
Состояние счётчика привязано к ассоциации безопасности или к эпохе ключа, поэтому смена ключа создаёт новый контекст и собственное пространство последовательности. Очистка счётчика без замены ключа или повторное использование ассоциации после ручного сброса ломает допущение, на которое опирается окно получателя. Поэтому существует смена ключей под управлением протокола, а не видимая оператору кнопка сброса.
Когда туннель ведёт себя неправильно после ручного вмешательства, спросите, затронуло ли вмешательство состояние последовательности. Конфигурация, которая выглядит одинаково, может вести себя иначе, потому что унаследованное состояние — не то, которого она ожидает.
Диагностируйте причину, прежде чем что-то отключать
Потери, переупорядочивание, дублированный трафик и дефект реализации проявляются как повторные передачи, и только одна из них — проблема повтора. Отключение проверки, чтобы заглушить шум, убирает свойство, на которое вы полагались, и затрудняет поиск исходной причины, потому что теперь у повторных передач вообще нет объяснения.
Собирайте ограниченные доказательства: идентификаторы ассоциации, номера последовательности и счётчики, без полезной нагрузки. Этого достаточно, чтобы отличить дубликат от переупорядоченного прихода, и это не превращает ваш диагностический файл в копию трафика пользователя.
Чего проверка не обещает
Защита от повтора — свойство обработки пакетов внутри одного протокола. Она не означает, что оператор не ведёт журналов, что сайт не может распознать учётную запись или что сеанс анонимен. Это отдельные вопросы об отдельных системах, и надёжная схема защиты от повтора не отвечает ни на один из них.
Поддерживаемое программное обеспечение с поддерживаемыми настройками — это практический контроль, доступный пользователю. Пакет обрабатывает протокол; всё остальное остаётся операционным решением.