Чому самого лише шифрування недостатньо проти повторно надісланого пакета

Захищені пакети не спливають криптографічно, тому пакет, дійсний п'ять хвилин тому, дійсний і зараз, адже шифрування й захист цілісності нічого не кажуть про те, коли були створені байти. Нападнику, який може перехопити й повторно надіслати трафік, не потрібно зламувати шифр. Тому кожен серйозний тунельний протокол несе стан послідовності поруч зі своїми ключами.

Механізм невеликий, і його відмови легко сплутати з втратою пакетів.

Дійсний шифротекст — не свіжий шифротекст

Автентифікація відповідає на одне питання: чи прийшли ці байти незмінними від власника ключа. Вона не відповідає, чи бачить їх отримувач уперше. Повторно надісланий пакет бездоганно проходить першу перевірку, і саме тому сама перевірка цілісності не може зупинити повтор, і тому протоколу потрібне друге правило про приймання. Отримувач, який лише автентифікує, не має захисту від нападника із записом.

Це правило дешево реалізувати й дешево сформулювати: прийняти даний захищений пакет один раз, під даним ключем. Усе інше в цій галузі випливає з того, як реалізація відстежує цей один раз.

Читання відкидання через повтор як помилки розшифрування веде вас зовсім не в ту підсистему.

Номер послідовності та вікно

IPsec ESP несе номер послідовності, а отримувач тримає ковзне вікно нещодавно прийнятих значень, причому специфікація ESP описує типовий розмір вікна та можливість його розширити. WireGuard іде іншим шляхом: лічильник на кожен ключ і явна перевірка проти нього. Жодна зі схем не припускає, що пакети приходять по порядку, бо реальні мережі їх перевпорядковують. Обидві терплять перевпорядкування, і жодна не терпить повторення.

Саме вікно робить таку терпимість можливою. Пакет трохи позаду найбільшого побаченого значення ще може бути прийнятий, якщо його не приймали раніше; пакет далеко позаду або той, чиє місце вже позначене, відкидається. Збільште вікно — і ви терпите більше перевпорядкування ціною більшого стану на асоціацію.

Діагностичні лічильники показують, у якому ви випадку. Відкидання через повтор збільшують певний лічильник, а не загальну помилку, і читання цього лічильника — перше корисне спостереження.

nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer

Стан належить ключу, а не хосту

Стан лічильника прив'язаний до асоціації безпеки або до епохи ключа, тому зміна ключа створює новий контекст і власний простір послідовності. Очищення лічильника без заміни ключа або повторне використання асоціації після ручного скидання ламає припущення, на яке спирається вікно отримувача. Тому існує зміна ключів під керуванням протоколу, а не видима оператору кнопка скидання.

Коли тунель поводиться неправильно після ручного втручання, запитайте, чи втручання зачепило стан послідовності. Конфігурація, що виглядає однаково, може поводитися інакше, бо успадкований стан — не той, якого вона очікує.

Діагностуйте причину, перш ніж щось вимикати

Втрати, перевпорядкування, дубльований трафік і дефект реалізації проявляються як повторні передачі, і лише одна з них — проблема повтору. Вимкнення перевірки, щоб заглушити шум, прибирає властивість, на яку ви покладалися, і ускладнює пошук початкової причини, бо тепер повторні передачі взагалі не мають пояснення.

Збирайте обмежені докази: ідентифікатори асоціації, номери послідовності й лічильники, без корисного навантаження. Цього достатньо, щоб відрізнити дублікат від перевпорядкованого приходу, і це не перетворює ваш діагностичний файл на копію трафіку користувача.

Чого перевірка не обіцяє

Захист від повтору — властивість обробки пакетів у межах одного протоколу. Він не означає, що оператор не веде журналів, що сайт не може розпізнати обліковий запис або що сеанс анонімний. Це окремі питання про окремі системи, і надійна схема захисту від повтору не відповідає на жодне з них.

Підтримуване програмне забезпечення з підтримуваними налаштуваннями — це практичний контроль, доступний користувачу. Пакет обробляє протокол; усе інше залишається операційним рішенням.