• Потери сетевых пакетов внутри зашифрованного IPsec туннеля под высокой нагрузкой (1+ Гбит/с).
• В системных журналах Cisco/strongSwan/MikroTik появляются ошибки: IPsec: Replay Check Failed или packet rejected by anti-replay check.
• Резкое падение пропускной способности при включении многопоточной передачи данных.
• Ошибки возникают при наличии параллельных каналов передачи данных (ECMP/LACP) у интернет-провайдера.

1. Механизм защиты IPsec Anti-Replay (RFC 4303)

Для защиты от атак повторного воспроизведения (Replay Attacks) протокол ESP присваивает каждому пакету монотонно возрастающий 64-битный порядковый номер (Sequence Number). Принимающая сторона ведет битовую маску — Anti-Replay Window. Если пакет приходит с номером, который меньше левой границы окна или уже был принят ранее, ядро отбрасывает его как вредоносный.

2. Причина ложных срабатываний: Packet Reordering

В современных высокоскоростных сетях пакеты одного потока могут идти разными физическими путями у оператора (ECMP) или обрабатываться разными ядрами CPU. В результате пакет №1005 может обогнать пакет №950. Если разрыв между ними превышает размер окна Anti-Replay, отставший пакет уничтожается.

3. Увеличение размера окна Anti-Replay на Cisco IOS-XE

! Просмотр счетчика отброшенных пакетов
Router# show crypto ipsec sa | include replay
! Вывод: replay detection support: Y   replay window size: 64
!        pkts replay failed: 45012

! Расширение размера окна до максимального (1024 пакета)
crypto ipsec security-association replay window-size 1024

! Полное отключение проверки (только для изолированных L2 каналов, не рекомендуется)
! crypto ipsec security-association replay disable

4. Конфигурация strongSwan (Linux XFRM)

В конфигурационном файле /etc/swanctl/swanctl.conf задайте размер окна:

connections {
    SiteToSite {
        children {
            net {
                # Увеличение размера окна Anti-Replay (по умолчанию 32/64)
                replay_window = 128
                esp = aes256gcm128-modp2048!
            }
        }
    }
}

5. Настройка очередей и RSS на сетевых картах Linux

Чтобы пакеты одного VPN-потока всегда обрабатывались одним и тем же ядром CPU (устранение переупорядочивания внутри ОС):

# Включение аппаратного хэширования Symmetric Toeplitz
ethtool -K eth0 rxhash on

# Фиксация очередей RSS
ethtool -N eth0 rx-flow-hash udp4 fn