Комментарии 23
Обожаю pfsense. Тоже его использую в такой связке с vpn, только без Gateway Groups.
Обернули бы в Wireguard скорость бы была еще больше.
Именно. Оптимизированная под x86_64 реализация Salsa20 вдвое быстрее RC4, что какбы намекает.
Основной выигрыш там за счёт того что он не user-space, а не за счёт скорости шифрования.
В Windows, Android и iOS?
От того, что в Linux он работает в виде модуля ядра — снижаются задержки, но потоковое вместо блочного шифрования даёт основную разницу, можете на вполне юзерспейсном SSH проверить.
От того, что в Linux он работает в виде модуля ядра — снижаются задержки, но потоковое вместо блочного шифрования даёт основную разницу, можете на вполне юзерспейсном SSH проверить.
Я говорил про Linux. Как дела обстоят в Windows я не в курсе, а в Android WG точно не в ядре (если без рута).
Несколько некорректно сравнивать ssh с туннелем — потому что ssh может себе позволить шифровать длинные блоки и отправлять их одним syscall, в то время как для туннеля приходится каждый блок (обычно один пакет) обрабатывать и собирать отдельно (речь про туннель поверх UDP).
Если очень грубо — OpenVPN вынужден каждый (почти) пакет получать из ядра (а это переключение контекста), потому что-то с ним делать и отдавать обратно в ядро (tun/tap) — итого имеем минимум два syscall на пакет не считая дополнительного копирования данных (в память процесса и из неё). Можно оптимизировать вторую часть, т.е. накапливать принятые пакеты и отдавать в tun/tap пачками после обработки, но это не всегда оптимально и возможно. Можно даже оптимизировать первую часть, получая пакеты пачками (есть для этого фишки в линухе), но всё равно оверхед будет ощутим.
Таким образом, нагрузка на процессор очень сильно возрастает, и мы получаем естественное ограничение скорости передачи с привязкой к мощности процессора — дополнительно к скорости шифрования.
Wireguard может позволить себе делать всё это в самом ядре, без переключения контекста, сильно сокращая накладные расходы — никаких лишних копий, никаких переключений контекста в процессе обработки потоков, не говоря уже о прямом доступе к буферам сокетов/адаптеров, таким образом значительно более эффективно используя процессор.
Проверьте скорость шифрования AES256 (openssl speed aes) и сравните со скоростью передачи openvpn с этим же шифром — первый покажет явно не меньше 100MB/s даже на средненьком интеле (даже RPi4 дает > 60 MB/s), а вот второй загнется где-то уже в районе 10-20 MB/s (т.е. выдаст не больше 100-200 мегабит на гигабитном линке, при этом загружая процессор на 100%).
Несколько некорректно сравнивать ssh с туннелем — потому что ssh может себе позволить шифровать длинные блоки и отправлять их одним syscall, в то время как для туннеля приходится каждый блок (обычно один пакет) обрабатывать и собирать отдельно (речь про туннель поверх UDP).
Если очень грубо — OpenVPN вынужден каждый (почти) пакет получать из ядра (а это переключение контекста), потому что-то с ним делать и отдавать обратно в ядро (tun/tap) — итого имеем минимум два syscall на пакет не считая дополнительного копирования данных (в память процесса и из неё). Можно оптимизировать вторую часть, т.е. накапливать принятые пакеты и отдавать в tun/tap пачками после обработки, но это не всегда оптимально и возможно. Можно даже оптимизировать первую часть, получая пакеты пачками (есть для этого фишки в линухе), но всё равно оверхед будет ощутим.
Таким образом, нагрузка на процессор очень сильно возрастает, и мы получаем естественное ограничение скорости передачи с привязкой к мощности процессора — дополнительно к скорости шифрования.
Wireguard может позволить себе делать всё это в самом ядре, без переключения контекста, сильно сокращая накладные расходы — никаких лишних копий, никаких переключений контекста в процессе обработки потоков, не говоря уже о прямом доступе к буферам сокетов/адаптеров, таким образом значительно более эффективно используя процессор.
Проверьте скорость шифрования AES256 (openssl speed aes) и сравните со скоростью передачи openvpn с этим же шифром — первый покажет явно не меньше 100MB/s даже на средненьком интеле (даже RPi4 дает > 60 MB/s), а вот второй загнется где-то уже в районе 10-20 MB/s (т.е. выдаст не больше 100-200 мегабит на гигабитном линке, при этом загружая процессор на 100%).
НЛО прилетело и опубликовало эту надпись здесь
Нераскрыт вопрос сохранения сессии при переключении по разным соединениям. Как реагируют на такое ресурсы с авторизацией, с мультимедиа, SPA сайты, интернет банки?
Если dest адрес привязывается к конкретному соединению — то должно быть всё хорошо, но без ускорения. А без привязки — быстро и с багами на сайтах.
Зачем pfSense, когда есть OPNsense?
Это решение на мой взгляд предпочтительнее использовать дня таких целей
Вообще на мой взгяд лучше всего использовать голый пакетный фильтр PF в OpenBSD, без гуев вида pfsense.
Лучше — с какой точки зрения?
Когда настраиваешь pf то начинаешь понимать как все работает, что где запрещено — разрешено, меньше риска что все поломается из за какого то обновления для гуев потому что их нет, рулить двумя или тремя текстовыми конфигами гораздо проще чем перемещаться по 10 вклдакам и еще 10 подвкладкам. Вообще каждому удобнее так как требует ситуация, для быстрого старта работы конечно pfsense или opnsense подойдут лучше всего, но если не пожалеть время и подготовить брандмауэр построенный на pf в ручную, то это время не пройдет зря точно, совсем по другому посмотришь на гуевы решения. В общем нужно только попробовать а понимание что удобнее, безопаснее, стабильнее придет.
С точки зрения повышения своей капитализации как специалиста — да, это лучший вариант.
С точки зрения бизнеса, который хочет результат, за меньшую стоимость и с меньшими накладными расходами — и что еще не маловажно — более «ремонтопригодный», т.е. чтобы его могли обслуживать менее квалифицированные специалисты — этот вариант не лучший, а лучший OPNSense.
Хотя OPNSense и pfSense очень далеко до юзабилити и френдли до того же Kerio.
С точки зрения бизнеса, который хочет результат, за меньшую стоимость и с меньшими накладными расходами — и что еще не маловажно — более «ремонтопригодный», т.е. чтобы его могли обслуживать менее квалифицированные специалисты — этот вариант не лучший, а лучший OPNSense.
Хотя OPNSense и pfSense очень далеко до юзабилити и френдли до того же Kerio.
OpenVPN и "без ограничения скорости" это взаимоисключающие параграфы. Промчались годы, а он до сих пор может только в один поток данные обрабатывать.
Хм… Это же и на сидбокс поставить можно...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Заворачиваем весь трафик локальной сети в vpn без ограничения скорости