From 05f8202714d7fe00a274635e1ece13652ac4899b Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Mon, 9 Nov 2020 15:33:18 +0300 Subject: [PATCH] =?utf8?q?=D0=9F=D0=BE=D1=87=D0=B5=D0=BC=D1=83=20IPsec=20?= =?utf8?q?=D0=B2=D0=BC=D0=B5=D1=81=D1=82=D0=BE=20WireGuard=3F?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit В 1d5bc1731a1e8f77fed6e7c60bbdeb9db421a87d написал что всё равно использую IPsec по возможности. Если забыть про то, что IPsec тесно интегрирован в ОС/ядро и позволяет делать далеко не только VPN туннели, то всё равно остаётся вопрос эффективности. IPsec ESP это отдельный тип IP-пакета, в котором (для AES-GCM) : SPI (4B) + SEQ (4B) + IV (8B) + padLen (1B) + PAD (0-3B) + NextHdr (1B) = 18 + 0-3 байта overhead. Причём от IV (вместо него использовать ESN) или SEQ можно было бы для AEAD-ов где это всё счётчики и избавиться уж, но стандарты гласят вот так. WireGuard (из его whitepaper): type+reserved (4B) + counter (8B) + I_m (4B) + UDP заголовок (8B) = 24 байта. В любом случае чуть больше ESP. Но, при этом ещё и CRC надо считать в UDP заголовке! Хотя он и не нужен, ибо и так данные аутентифицируются. Так что даже в теории он любом случае чуть менее эффективен. На практике парсинг ESP возможно отъедает и больше CPU из-за if-ов всяких, но это уже вопрос конкретной реализации, которую можно и упростить/ускорить. Ну а ChaCha20+Poly1305 для ESP уже есть: https://tools.ietf.org/html/rfc7634 И если мне нужно обеспечить защиту только между двумя IP-адресами, двумя хостями, то в WireGuard-е пришлось бы шифровать IP-пакеты -- это же VPN, а в IPsec использовать транспортный режим где внутри ESP будет лежать сразу же TCP/UDP/SCTP/whatever. Но это конечно вопрос решаемых задач. Но вот у меня по факту нигде нет туннельного режима IPsec, хотя есть пара туннелей gif-туннелей между двумя хостами, а в остальном только транспортные между хостами, чтобы не городить между ними никаких костылей в виде TLS. -- 2.50.0