Igor Sviridov:
Я прежде всего говорил об использовании WireGuard для site-to-site. ssh -D aka Socks сюда слабо относится.
Для клиентского VPN тоже есть отличия:
- нужно конфигурить socks на клиентах, если они его вообще поддерживают, и часто по-разному; Proxy Auto-config с неестественным интеллектом конечно может помочь, но не везде.
- при смене адреса клиента (Wired -> WiFi -> Mobile) нужно пересоединять SSH-сессию; может в каких клиентах есть auto-reconnect? для *nix конечно можно автоматизировать. Wireguard, Pulse etc поддерживают смену адреса клиента без разрыва сесии
- много-факторную аунтентификацию привинтить можно, но она будет скорее всего мешать auto-reconnect-у; для примера - у меня используется для Pulse конфигурация с 3-factor (AD auth + Okta или RSA + certificate auth).
- в некоторых индустриях требуется верификация клиента (OS patchlevel, антивирусы, etc); тут это не привинтишь.
В общем для админа или разработчика на Mac/Linux "ssh -D" вполне работает. Как только возникает зоопарк, как с видами клиентов так и требованиями - его удобнее переложить на специалистов.
Посмотрел, спасибо за тезисы. Пожалуй, таки не для меня. - Шифровальщик какой-то непроверенный. Более того, самописный, что вдвойне плохо. Значит, строгий аудит на каждую версию, и причём аудит этот - только для данного продукта. Это накладно. - Ставит что-то в ядро, да ещё и дёргает iptables при каждом рытье туннеля. Ядро, чай, не процесс, который убил - и всё вернулось не круги своя. Опять же, конфликты с чем-то, что не из коробки, у ядерного модуля более вероятны. Да, оно есть неядерное, но поскольку это не мейнстрим, уверенности в нём меньше. - Набор секретных артефактов для аутентификации у него свой. Значит, по умолчанию два ID: стандартный и евойный. За двумя бумажниками тяжелее уследить. - UDP transport. А значит сильно отличающийся от стандартного домохозяйского траффика. То есть не отовсюду работать будет, да и внимание нездоровое привлекать. Допускаю, что своя ниша у него есть, и даже понятно какая. -- Олег