Что: 05f8202714d7fe00a274635e1ece13652ac4899b Когда: 2020-11-09 15:33:18+03:00 ------------------------------------------------------------------------ Темы: ipsec ------------------------------------------------------------------------ Почему IPsec вместо WireGuard? В 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. ------------------------------------------------------------------------ оставить комментарий: mailto:comment@blog.stargrave.org?subject=Re:%20%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83%20IPsec%20%D0%B2%D0%BC%D0%B5%D1%81%D1%82%D0%BE%20WireGuard%3F%20%2805f8202714d7fe00a274635e1ece13652ac4899b%29 ------------------------------------------------------------------------ комментарий 0: From: David Rabkin Date: 2020-11-13 21:37:19Z Порог вхождения в IPsec высокий. Я ежедневно пользуюсь openvpn, и как пользователь, и как конфигуратор. Зачем мне что-то менять? Кинь ссылкой. ------------------------------------------------------------------------ комментарий 1: From: Sergey Matveev Date: 2020-11-13 21:52:17Z *** David Rabkin [2020-11-13 23:34]: >Порог вхождения в IPsec высокий. У него и круг задач куда более широкий. Это разные весовые категории. В данном посте я всё же имел в виду высоконагруженные системы, LAN-ы, связь между ДЦ, что-то долгоживущее. Пока IPv6 у людей нету массово, то значит есть NAT, значит с IPsec-ом будут проблемы и он не годится. Плюс не согласен что у OpenVPN порог вхождения небольшой. Его man в 1.5 раза больше чем man strongswan.conf. И strongSwan при этом полностью рулит и SA и SP (в отличии от racoon какого-нибудь). Я бы поспорил кто проще. Одно но у OpenVPN: у него, грубо говоря, один клиент и один конфиг, который заработает наверное и на Windows и на Unix-like системах. С IPsec зоопарк большой, с совершенно разными конфигами и подходами настройки в них. Я сейчас однозначно всеми руками за WireGuard (для случаев когда не подходит IPsec). И простота и эффективность. OpenVPN с моей точки зрения это самое сложное и геморройное что есть, в плане администрирования, и самое плохое по производительности/ресурсоёмкости. >Зачем мне что-то менять? Так говорят и пользователи Windows и macOS :-). Мне на это нечего ответить. Но OpenVPN, на мой взгляд -- худшее решение. Я считаю что куда проще и эффективнее (там хотя бы быстрая криптография есть) поднять SSH TUN туннель (что иногда и делал), который в OpenSSH есть. Мне в своё время и Windows95/98 очень нравились и неохота их было менять. >Кинь ссылкой. https://m.habr.com/ru/post/518116/ ------------------------------------------------------------------------ Сгенерирован: SGBlog 0.34.0