Какую чушь вы несете. Какая разница, кто и какие правила протянул, не нравятся правила не участвуйте в соревнованиях, а не придумывайте отмазку, что фальсификация это правильно, потому что злые пиндосы. А не отвечал, потому что не интересно, на всякие высасывания из пальца тратить время. Факт есть факт, 20 лет скрывали, что Гагарин вышел из корабля до посадки, потом признались. Госпропаганда может любое преступление обосновать, как спасение Родины.
если по правилам FAI летчик должен приземлиться, то вся американская программа с приводнением экипажей по вашей же логике не является космической
Ну после таких заявлений, подтверждаете, что с вами говорить не о чем.
Не только продавали, но в лизинг давали, и что ещё более важно запчасти нормально поставляли, и им не нужно было, как суперджету неделями ждать пока запчасть какую-то привезут.
Вы в заморозке были? СССР врал, так как по правилам FAI для фиксации рекорда нужно было, чтобы пилот приземлился в своём летающем аппарате, а не на парашюте отдельно, а аппарат не приземлился, а по сути упал. Какой там был проект без разницы, это лишь говорит, что при таком проекте подача на рекорд - умышленная фальсификация. А кто конкретно врал, мне не интересно, так как это была гос позиция, а не какого-то конкретного человека.
Так про Луну тоже много источников. В том числе советские космонавты подтверждали, что американцы там были. Так и с Австралией, можно договориться до того, что это всё просто придумали и глобальный заговор. Тем более заговор между противниками в Холодной войне.
Так это никак не доказывает, что Гагарин летал. Может по факту в СССР первым летал Титов, а Гагарин чисто фальсификация, чтобы обогнать америкосов. Запустили пустую ракету, а потом Гагарина скинули с самолета с парашютом. Просто в данном случае есть факт фальсификации части фактов, вполне возможно сфальсифицировали больше, чем признались. Тем более советская программа была полностью засекречена, а в американской и ракеты запускали на виду кучи зрителей, и по телеку прямая трансляция была.
Самое смешное, что при этом у этих конспирологов, никаких вопросов к полету Гагарина нет. А там с доказательствами совсем туго. Ни 8000 фоток, ни куска ракеты зависшей на орбите, ни дырки в небесной тверди. Более того Гагарин даже посадку совершал не в спускаемой капсуле, а на парашюте. При этом в СССР 20 лет врали, что он приземлился в капсуле, т.е. сознательно фальсифицировали условия посадки. Но никаких вопросов :)
P.S. Я не ставлю под сомнения оба события, просто удивляет логика конспирологов. P.P.S. Кстати, а хоть один конспиролог пояснил, зачем американцы летали много раз на Луну? Ведь повторные "фальшивые" полеты, только увеличивают шансы разоблачения, при этом не дают никакого пропагандистского профита. За количество полетов никаких бонусов не дают.
graceful-reload это применение конфига для следующих соединений, а не текущих. Если у вас кто-то, что-то качает и у него заканчивается трафик/время, то вы не сможете их изменить в процессе скачивания. В моём случае так работает самообновление шлюза, он умеет себя обновить с плавным перетеканием коннектов со старой версии на новую. Для всего остального рестарты не нужны.
Вы как и многие не правильно посыл статьи воспринимаете. Плюс концентрируетесь на какой-то одном аспекте, ну типа роутинг в VPN, или как у вас рестарт Nginx. Тогда как у меня задача решается комплексно, это и удобство создания самих конфигов для админа, и доставка этих конфигов до конечного юзера, и мгновенная доставка всех изменений на все шлюзы.
Я же не говорю, что что это нельзя физически сделать с другими инструментами. Можно, вопрос в затрачиваемых усилиях, и удобстве и простоте управления всем этим. Если для того что в моём случае может выполнить любой менеджер, в глаза не видевший конфиги nginx или вообще linux и ssh. То в других инструментах может потребоваться наём специального человека для той же задачи. Вы ещё вспомните, что для nginx можно собственный модуль написать.
Админку WordPress во внутреннюю сеть, это какую внутреннюю сеть? Web-хостинга?
И как на VPN сделать роутинг site-a.com -> 3.3.3.3 и site-b.com -> 3.3.3.3. Но чтобы клиент A имел доступ только к своему сайту site-a.com, а к сайту site-b.com не имел?
Ок, как настроить vpn, чтобы разные клиенты на одном сервере (один IP) имели доступ только к своему сайту (только свой домен/SNI), а к сайтам других клиентов не имели?
Что уж говорить о habrastorage.org. У них в домене прямым текстом написано: .org - Организованная Расхитительная Группа. Сами признались! Воруют духовноскрепные картиночки, и небось там в совмещенном центре ЦРУ+МИ6+рептилоиды портят их *ей-пропагандой.
С аутентификацией, типа 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, ревью чужих пулл-реквестов и поддержке комьюнити. Сейчас мы физически направляем все ресурсы команды в разработку фич и стабильность.
А как прописать маршруты на OpenVPN, если на одном сервере (т.е. один IP) десяток клиентов, как их разделись по SNI? Тут же дело не только в технической возможности, что-то сделать, а и в удобстве. Вы будете настраивать новый конфиг OpenVPN (и объяснять, что с ним делать) для фрилансера, которому нужно дать доступ на пару часов?
Ну не всё так страшно, это просто была нода на Vultr с OpenVPN. Что касается nginx + openresty с JWT. Nginx как reverse прокси работает, для доступа к ресурсам на том же сервере нормально, но для доступа к условно рандомным доменам на других серверах не очень удобно. C JWT весьма проблемно сделать отзыв доступа.
Ну, PAM это уже можно сказать тяжелый энтерпрайз. И больше заточен на доступ к инфраструктуре (SSH, RDP, базы данных). Опять же, как и в случае mTLS более сложный онбоардинг, нужно ставить клиенты. А у нас всё же фокус был на простоте использования, как не техническим юзерам (редакторы, дизайнеры, аудиторы, фрилансеры и т.п.), так и чтобы для выдачи доступа не нужен был специально обученный человек.
В основном из-за более сложного онбординга. Там творческие люди зачастую не могли найти куда они сохранили json-файл с конфигом, который прислали по телеге. Да и mTLS решает вопрос с авторизацией, но не решает вопрос с селективной маршрутизацией. Просто когда-то использовать VPN, пока пару раз не прилетел абуз, из-за того, что кто-то торрент качал при включенном VPN. Потому очень хотелось разделить трафик.
Какую чушь вы несете. Какая разница, кто и какие правила протянул, не нравятся правила не участвуйте в соревнованиях, а не придумывайте отмазку, что фальсификация это правильно, потому что злые пиндосы.
А не отвечал, потому что не интересно, на всякие высасывания из пальца тратить время. Факт есть факт, 20 лет скрывали, что Гагарин вышел из корабля до посадки, потом признались. Госпропаганда может любое преступление обосновать, как спасение Родины.
Ну после таких заявлений, подтверждаете, что с вами говорить не о чем.
На любое сообщение, что вот этот Вася Пупкин сидит спокойно в телеге, можно сказать, что он из этих 2-8%.
Не только продавали, но в лизинг давали, и что ещё более важно запчасти нормально поставляли, и им не нужно было, как суперджету неделями ждать пока запчасть какую-то привезут.
Вы в заморозке были? СССР врал, так как по правилам FAI для фиксации рекорда нужно было, чтобы пилот приземлился в своём летающем аппарате, а не на парашюте отдельно, а аппарат не приземлился, а по сути упал. Какой там был проект без разницы, это лишь говорит, что при таком проекте подача на рекорд - умышленная фальсификация. А кто конкретно врал, мне не интересно, так как это была гос позиция, а не какого-то конкретного человека.
Так про Луну тоже много источников. В том числе советские космонавты подтверждали, что американцы там были. Так и с Австралией, можно договориться до того, что это всё просто придумали и глобальный заговор. Тем более заговор между противниками в Холодной войне.
Так это никак не доказывает, что Гагарин летал. Может по факту в СССР первым летал Титов, а Гагарин чисто фальсификация, чтобы обогнать америкосов. Запустили пустую ракету, а потом Гагарина скинули с самолета с парашютом. Просто в данном случае есть факт фальсификации части фактов, вполне возможно сфальсифицировали больше, чем признались. Тем более советская программа была полностью засекречена, а в американской и ракеты запускали на виду кучи зрителей, и по телеку прямая трансляция была.
А разве знание конкретных фактов не равно знаю? Я к примеру, никогда не видел "живьём" Австралию, но я знаю что там кенгуру водятся.
Самое смешное, что при этом у этих конспирологов, никаких вопросов к полету Гагарина нет. А там с доказательствами совсем туго. Ни 8000 фоток, ни куска ракеты зависшей на орбите, ни дырки в небесной тверди. Более того Гагарин даже посадку совершал не в спускаемой капсуле, а на парашюте. При этом в СССР 20 лет врали, что он приземлился в капсуле, т.е. сознательно фальсифицировали условия посадки. Но никаких вопросов :)
P.S. Я не ставлю под сомнения оба события, просто удивляет логика конспирологов.
P.P.S. Кстати, а хоть один конспиролог пояснил, зачем американцы летали много раз на Луну? Ведь повторные "фальшивые" полеты, только увеличивают шансы разоблачения, при этом не дают никакого пропагандистского профита. За количество полетов никаких бонусов не дают.
graceful-reload это применение конфига для следующих соединений, а не текущих. Если у вас кто-то, что-то качает и у него заканчивается трафик/время, то вы не сможете их изменить в процессе скачивания. В моём случае так работает самообновление шлюза, он умеет себя обновить с плавным перетеканием коннектов со старой версии на новую. Для всего остального рестарты не нужны.
Вы как и многие не правильно посыл статьи воспринимаете. Плюс концентрируетесь на какой-то одном аспекте, ну типа роутинг в VPN, или как у вас рестарт Nginx. Тогда как у меня задача решается комплексно, это и удобство создания самих конфигов для админа, и доставка этих конфигов до конечного юзера, и мгновенная доставка всех изменений на все шлюзы.
Я же не говорю, что что это нельзя физически сделать с другими инструментами. Можно, вопрос в затрачиваемых усилиях, и удобстве и простоте управления всем этим. Если для того что в моём случае может выполнить любой менеджер, в глаза не видевший конфиги nginx или вообще linux и ssh. То в других инструментах может потребоваться наём специального человека для той же задачи. Вы ещё вспомните, что для nginx можно собственный модуль написать.
Админку WordPress во внутреннюю сеть, это какую внутреннюю сеть? Web-хостинга?
И как на VPN сделать роутинг site-a.com -> 3.3.3.3 и site-b.com -> 3.3.3.3. Но чтобы клиент A имел доступ только к своему сайту site-a.com, а к сайту site-b.com не имел?
Ок, как настроить vpn, чтобы разные клиенты на одном сервере (один IP) имели доступ только к своему сайту (только свой домен/SNI), а к сайтам других клиентов не имели?
Что уж говорить о habrastorage.org. У них в домене прямым текстом написано: .org - Организованная Расхитительная Группа. Сами признались! Воруют духовноскрепные картиночки, и небось там в совмещенном центре ЦРУ+МИ6+рептилоиды портят их *ей-пропагандой.
Они просто отлично понимают, что "все животные равны, но есть равнее"
Даже у РКН есть свой телеграм канал, как и у остальных ведомств. Там же даже не стесняются госбабло на VPN выписывать :)
Подумаем конечно, но пока главное запуститься :) А то интересные идеи приходят каждый день, а запуск всё откладывается.
С аутентификацией, типа 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, ревью чужих пулл-реквестов и поддержке комьюнити. Сейчас мы физически направляем все ресурсы команды в разработку фич и стабильность.
Не совсем понял, как это поможет с разными доменами на одном IP?
А как прописать маршруты на OpenVPN, если на одном сервере (т.е. один IP) десяток клиентов, как их разделись по SNI? Тут же дело не только в технической возможности, что-то сделать, а и в удобстве. Вы будете настраивать новый конфиг OpenVPN (и объяснять, что с ним делать) для фрилансера, которому нужно дать доступ на пару часов?
Ну не всё так страшно, это просто была нода на Vultr с OpenVPN.
Что касается nginx + openresty с JWT. Nginx как reverse прокси работает, для доступа к ресурсам на том же сервере нормально, но для доступа к условно рандомным доменам на других серверах не очень удобно. C JWT весьма проблемно сделать отзыв доступа.
Ну, PAM это уже можно сказать тяжелый энтерпрайз. И больше заточен на доступ к инфраструктуре (SSH, RDP, базы данных). Опять же, как и в случае mTLS более сложный онбоардинг, нужно ставить клиенты. А у нас всё же фокус был на простоте использования, как не техническим юзерам (редакторы, дизайнеры, аудиторы, фрилансеры и т.п.), так и чтобы для выдачи доступа не нужен был специально обученный человек.
В основном из-за более сложного онбординга. Там творческие люди зачастую не могли найти куда они сохранили json-файл с конфигом, который прислали по телеге.
Да и mTLS решает вопрос с авторизацией, но не решает вопрос с селективной маршрутизацией. Просто когда-то использовать VPN, пока пару раз не прилетел абуз, из-за того, что кто-то торрент качал при включенном VPN. Потому очень хотелось разделить трафик.