Как мы написали свой forward-proxy на Go и отказались от VPN для доступа к админкам

[HeOS]

Почему не использовали mutual TLS? Вроде проще и дешевле, чем вот такая развес стая система.

[zapimir]

В основном из-за более сложного онбординга. Там творческие люди зачастую не могли найти куда они сохранили json-файл с конфигом, который прислали по телеге.
Да и mTLS решает вопрос с авторизацией, но не решает вопрос с селективной маршрутизацией. Просто когда-то использовать VPN, пока пару раз не прилетел абуз, из-за того, что кто-то торрент качал при включенном VPN. Потому очень хотелось разделить трафик.

[Shaman_RSHU]

Странно, что в опросе отсутствует PAM (Privileged Access Managers)

[zapimir]

Ну, PAM это уже можно сказать тяжелый энтерпрайз. И больше заточен на доступ к инфраструктуре (SSH, RDP, базы данных). Опять же, как и в случае mTLS более сложный онбоардинг, нужно ставить клиенты. А у нас всё же фокус был на простоте использования, как не техническим юзерам (редакторы, дизайнеры, аудиторы, фрилансеры и т.п.), так и чтобы для выдачи доступа не нужен был специально обученный человек.

[Ewssewa105]

Как называется это

[Granulex]

VPN для выдачи доступа редакторам – это как выдать ключ от всего офиса человеку, которому нужно только полить цветы. Удивительно, что стандартная связка nginx + openresty с JWT-авторизацией закрывает ту же задачу без написания своего прокси на Go – но зато своя реализация даёт нужную гибкость.

[zapimir]

это как выдать ключ от всего офиса человеку

Ну не всё так страшно, это просто была нода на Vultr с OpenVPN.
Что касается nginx + openresty с JWT. Nginx как reverse прокси работает, для доступа к ресурсам на том же сервере нормально, но для доступа к условно рандомным доменам на других серверах не очень удобно. C JWT весьма проблемно сделать отзыв доступа.

[Granulex]

Согласен – пока один сервер. Но редакторский «доступ к ресурсам» обычно расширяется быстрее, чем ожидаешь :)))

[aytugan]

Огонь, молодцы что делаете нестандартные решения, но в тоже время без костылестроений.

[Dagor]

ну а маршруты в openvpn прописать конечно религия не позволяет, и acl на пользователей его тоже…

[zapimir]

А как прописать маршруты на OpenVPN, если на одном сервере (т.е. один IP) десяток клиентов, как их разделись по SNI? Тут же дело не только в технической возможности, что-то сделать, а и в удобстве. Вы будете настраивать новый конфиг OpenVPN (и объяснять, что с ним делать) для фрилансера, которому нужно дать доступ на пару часов?

[Dagor]

Сервер просто пришлет пуш клиенту, с условными только 192.168.100.0/24 ко мне, остальное сам, клиенту присваивать статический ип внутри впн, на впн сервере ограничивать этой статике доступ необходимым сервером фаирволом. И никаких тебе абузов от прова и шляющихся по локалке удаленщиков.

Все это настраивпется на сервере.

[zapimir]

Не совсем понял, как это поможет с разными доменами на одном IP?

[Xelld]

Утверждение про весь трафик в VPN из статьи конечно такое себе, да.

Тем не менее, проблема ZTNA для веб ресурсов за всякими балансировщиками или ingress есть: за одним IP могут находиться множество ресурсов. Рано или поздно сегментировать их станет больно и бессмысленно.

[Xelld]

Интересный способ, выглядит заманчиво.

А что с аутентификацией?

У вас есть roadmap? Планы на on-prem? Open source? :)

[zapimir]

С аутентификацией, типа SSO пока не прикручивали (в личном кабинете уже есть Google, Github, Microsoft, Telegram). Токен можно сделать персональным (вплоть до того, что ограничить количество регистраций, даже если токен кому-то отдадут - то он не будет работать), также есть защищенные токены, где дополнительно мастер-пароль можно задать (конфиг зашифрован AES-GCM, расшифровка на клиенте).

Что касается Roadmap, то как раз добавить SSO (поскольку мы при регистрации генерим dev_id, то SSO будет привязывать аутентификацию к dev_id). Более глобально в планах сделать ещё такую штуку, как TCP-over-HTTPS (MySQL, Redis, ClickHouse, SSH,...).
Как это будет работать: Легкий Go-клиент на Wails с WebUI скачивает конфиги по токену и создает локальные алиасы (например, mysql.grafana). Вы подключаетесь к ним через любой софт (IDE, HeidiSQL, DBeaver) как к локалхосту, а клиент сам строит туннель через наш шлюз. Профит: Проксируем даже те программы, которые не умеют в прокси. Бонус - работа через 443 порт, плюс для текстовых протоколов (MySQL, Redis и т.п.) можно использовать Zstd сжатие. Мы даже реализовали Encrypted Client Hello (ECH), но браузеры пока его не поддерживают для прокси подключения.

Про On-prem (Self-hosted)

На самом деле, базовый On-prem у нас уже есть (в статье есть блок "Модели изоляции"). Мы используем популярную сейчас гибридную архитектуру (как у Tailscale или Cloudflare Tunnels):

• Data Plane (Сам шлюз): Вы можете развернуть полностью на своих серверах (через тот самый curl | sh или автодеплой в личном кабинете). Весь ваш трафик пойдет только через ваши серверы, мы его не видим и не пропускаем через себя.

• Control Plane (Управление): Админка, генерация токенов, API для расширения, оркестрация сертификатов - остаются на нашей SaaS-стороне.

Делать 100% On-prem (когда клиент хостит у себя еще и наш бэкенд, UI, базу данных) мы пока не планируем.

Про OpenSource

Сейчас таких планов нет. Мы находимся на стадии валидации бизнес-модели и строим коммерческий SaaS. Сделать код открытым - это же не просто нажать кнопку "Make Public" на GitHub. Это огромная работа по написанию документации, разбору issue, ревью чужих пулл-реквестов и поддержке комьюнити. Сейчас мы физически направляем все ресурсы команды в разработку фич и стабильность.

[Xelld]

Спасибо за развернутый ответ!

Делать 100% On-prem (когда клиент хостит у себя еще и наш бэкенд, UI, базу данных) мы пока не планируем.

Ну... Я бы все же подумал об этом, тем более с вашими планами на TCP tunneling. Это уже ближе к Teleport или Boundary, такой софт чаще (по моему опыту) хотят контролировать и не зависеть от паблика.

[zapimir]

Подумаем конечно, но пока главное запуститься :) А то интересные идеи приходят каждый день, а запуск всё откладывается.

[edo1h]

3 неочевидных юзкейса (например, как мы навсегда убили необходимость

Скорость и TTFB: почему прокси работает быстрее прямого подключения

Знакомые обороты llm‘ок

Непонятно почему, но раздражает

[tarkhil]

Если вы не умеете настраивать vpn так, чтобы он не заворачивать в себя весь трафик - просто отойдите от сервера и наймите специалиста

[zapimir]

Ок, как настроить vpn, чтобы разные клиенты на одном сервере (один IP) имели доступ только к своему сайту (только свой домен/SNI), а к сайтам других клиентов не имели?

[tarkhil]

Админку во внутреннюю сеть. VPNу пишем роутинг. Только на внутреннюю сеть.

Если вы не умеете писать роутинг, обратитесь к своему системному администратору.

UPD. Если нужно, чтобы клиент не мог намеренно руками вписать роутинг, делайте еще настройку файрвола.

Если нужно - обращайтесь.

[zapimir]

Админку WordPress во внутреннюю сеть, это какую внутреннюю сеть? Web-хостинга?

И как на VPN сделать роутинг site-a.com -> 3.3.3.3 и site-b.com -> 3.3.3.3. Но чтобы клиент A имел доступ только к своему сайту site-a.com, а к сайту site-b.com не имел?

[tarkhil]

Это вы создаете на сервере сетку 10.61.223.0 и в нее - все админки. В VPN роутинг только на эту сетку.

Очевидно, что роутинг - это только для IP. Доступ на админки - по SSL-сертификатам.

[tarkhil]

В общем, вы сделали очень интересный и даже местами красивый велосипед. Но у вас фундаментальные знания состоят в основном из пробелов.

[POPSuL]

Тут уже напихали про рутинг, но я допихну в панамку ещё про обрыв коннектов. nginx всё же умеет в graceful-reload, и всё прекрасно релоадится и ничего не рвётся :)

[zapimir]

graceful-reload это применение конфига для следующих соединений, а не текущих. Если у вас кто-то, что-то качает и у него заканчивается трафик/время, то вы не сможете их изменить в процессе скачивания. В моём случае так работает самообновление шлюза, он умеет себя обновить с плавным перетеканием коннектов со старой версии на новую. Для всего остального рестарты не нужны.

Вы как и многие не правильно посыл статьи воспринимаете. Плюс концентрируетесь на какой-то одном аспекте, ну типа роутинг в VPN, или как у вас рестарт Nginx. Тогда как у меня задача решается комплексно, это и удобство создания самих конфигов для админа, и доставка этих конфигов до конечного юзера, и мгновенная доставка всех изменений на все шлюзы.

Я же не говорю, что что это нельзя физически сделать с другими инструментами. Можно, вопрос в затрачиваемых усилиях, и удобстве и простоте управления всем этим. Если для того что в моём случае может выполнить любой менеджер, в глаза не видевший конфиги nginx или вообще linux и ssh. То в других инструментах может потребоваться наём специального человека для той же задачи. Вы ещё вспомните, что для nginx можно собственный модуль написать.