Тоже никогда не понимал, почему Lua считается простым языком. Можно относительно быстро объяснить человеку, что такое классы, экземпляры, и как ими пользоваться для моделирования реальных объектов. А вот чтобы дать ему этот же инструмент в Lua, ему сначала придется рассказать про метатаблицы и прототипное наследование.
Плюсую. Таким образом можно также использовать совершенно любой VPN-провайдер (и любую его локацию) как выходную ноду, а свой VPS как входную. Т.е. явно разделяются две функции: 1. обход блокировки VPN; 2. замена IP/скрытие трафика/обход блокировки ресурсов.
Еще добавлю, что если вы не доверяете своему VPS-провайдеру (особенно, если он российский), но доверяете VPN-провайдеру (который находится в другой юрисдикции и для которого вполне нормально вести no-logs политику), то можно не терминировать VPN-трафик на VPS, а просто перенаправлять его с дополнительной обфускацией. Таким образом данные шифруются на клиенте и дешифруются VPN-провайдером, а VPS уже в чистом виде занимается только обходом блокировки VPN-провайдера.
С другой стороны, выпуск нового сертификата рано или поздно раскроют мониторингом или через CT. А вот если терминировать трафик сертификатом самого же сервера (любезно украденного с ВМ, как предлагают выше), то, чтобы такое запалить, владельцу сайта нужно при мониторинге сверять согласованные ключи соединения как со стороны клиента, так и сервера. Возможно, в редких случаях, такая игра с кражей сертификата стоит свеч.
А у меня вот капча от Cloudflare всегда проходит одним нажатием кнопки. Иногда даже складывается ощущение, будто бы оно ничего и не делает, а просто выжидает. И это при VPN и куче включенных настроек по сопротивлению фингерпринтингу в Firefox. По сравнению с гуглокапчей, где нужно минуту выбирать пешеходные переходы, это выглядит как подарок.
P.S. Аналогично комментарию выше про WARP, рискну предположить, что Cloudflare просто по-разному относится к айпишникам разных VPN-провайдеров.
Хорошее замечание, но это скорее политическое ограничение, чем техническое.
Как вы уже сказали, сам по себе PKI вполне себе может работать автономно. Единственное, что делает необходимым глобальные CA, это глобальность браузеров/ОС, в которые эти CA должны быть встроены.
По поводу доверия к сертификатам тащ майора Минцифры, Яндекс что-то мутил с Certificate Transparency. Это конечно не блокчейн, но технически тоже распределенный реестр.
А вообще, если говорить про технические ограничения PKI, то похоже нельзя (поправьте, если я не прав) назначить ограничения на корневые сертификаты, чтобы те же национальные CA могли выпускать сертификаты только для собственных зон. Подобная гарантия позволила бы пользователям с меньшими колебаниями добавить их в доверенные, полагая, что конечная инфраструктура сайтов в этих зонах и так контролируется тащ майором.
Но все-таки по поводу страшных диалоговых окон - вообще не использовать HTTPS это точно не выход. Шифровать надо в любом случае, в том числе и статику, такое время.
Но стоит отметить, что подмена DNS для конечного пользователя и подмена DNS для проверяющей инфраструктуры LE - это не одно и то же.
В первом случае у нас большинство устройств по-прежнему делают нешифрованные DNS запросы сначала на роутер, а затем на DNS-серверы провайдера, который успешно пользуется этим для того же ограничения доступа к заблокированным ресурсам. Впрочем, учитывая, что DNS-трафик не шифруется, по большей части даже не важно куда он направляется.
Во втором случае я ожидаю, что арбитр с властью выдавать сертификаты практически без ограничений, будет как минимум шифровать трафик до резолверов и использовать различные источники для получения более достоверной информации.
Но если пользователь способен закрыть подобное предупреждение двумя не очень очевидными кликами, то, наверное, ему уже не помочь)
Скрытый текст
Касательно красных замочков, имхо, давно следовало бы сделать, чтобы все сайты по HTTP открывались так, как на скрине выше. Кроме прямых обращений по приватным айпи для всяких админок у роутеров.
А теперь представьте: заходите на «свой» банковский сайт, а это лишь идеальная копия, созданная мошенниками.
В эпоху HTTPS конечно сложно такое представить (в контексте подмены DNS). Даже если браузер по какой-то причине решит не обращаться к сайту по HTTPS, то неужели пользователя не смутит страшный красный замочек?
До ArgoCD еще руки не дошли, но когда я "примерял" его в качестве кандидата на какую-нибудь роль в этом проекте, мне показалось, что он выполняет несколько иную функцию - непрерывное развертывание приложений на большом флоте машин.
допускаю, что кластер не на один день
В данном случае, допущение верно лишь отчасти. Данная система скорее была спроектирована, чтобы как таракан перемещаться между серверами в практически автоматическом режиме. Это делалось с благой целью - избежать vendor-lock'a, но по факту периодически пересоздавать серверы чаще приходится в угоду разного рода экспериментам :D. Но, справедливости ради, случаи переезда серверов между разными провайдерами тоже были.
Плюс в том, что мы не просто разово создаем ресурсы, мы наблюдает их состояние в процессе жизни и можем обновлять версии сразу везде
Ну эта способность есть во всех IaC-инструментах. И Pulumi это скорее альтернатива Terraform, нежели ArgoCD. Хотя пересечения в их функциональности конечно тоже есть.
И немного не понял про nixos (даже почитав у них на сайте). Что в итоге она дала тут и что дает в принципе?
NixOS в данном случае - это альтернатива SaltStack и Ansible. Можно было автоматизировать развертывание кластера поверх той же Ubuntu с помощью этих инструментов. С рядом оговорок это тоже позволило бы получить воспроизводимую установку.
В целом NixOS дает новый подход к построению воспроизводимых Linux-систем. Ansible и SaltStack способны гарантировать выполнение определенных стейтов в определенном порядке, которые за счет различных мутаций (поставить пакет, записать файл) приводят систему в искомое состояние. В NixOS же система изначально существует в искомом состоянии и атомарно (с рядом оговорок) переходит от одного состояния к другому. Она практически не способна меняться за счет императивных действий, что одновременно можно рассматривать как плюс и как минус.
нежели учить новый язык, выдуманный отдельным вендором?
Лично мне этот язык показался гораздо приятнее YML-файликов в Ansible и SLS-стейтов в SaltStack. И уж всяко приятнее старого доброго Bash. А отдельного вендора тут нет: NixOS это Linux-дистрибутив, такой же как Ubuntu со всеми вытекающими.
В чем-то вроде k3d необходимости просто не возникло, готовый в NixOS модуль прекрасно справился с этой задачей.
Про микс TF + Pulumi ответил в предпоследнем разделе - в первом просто были нужные провайдеры, которых еще не было в Pulumi. В планах оставить только один инструмент.
Размышления над per-node кластерами тоже есть в статье. Прямо сейчас у меня нету таких масштабов нагрузки, над которыми имел бы смысл кластер с несколькими нодами. Зато есть потребность в нескольких серверах, развернутых в разных окружениях с разными приложениями. А для этого наиболее оптимальны single-node кластеры. Если в будущем у меня появится небходимость в одном из таких окружений масштабировать нагрузку, то я смогу в существующий кластер добавить worker-ноды.
Cloudflare, очевидно, не способен выполнять TLS-терминацию в приватных сетях, а публичные TLS-сертификаты там все равно нужны, чтобы всегда из коробки были зеленые замочки. + проксирование от Cloudflare мне нужно не везде, а еще я опасаюсь, что это создаст еще одну серьезную внешнюю зависимость по аналогии с Tailscale. DNS-провайдеров, поддерживающих ACME DNS-01 достаточно много, а вот бесплатное проксирование трафика как в Cloudflare, вероятно, предлагают единицы.
Дополню лишь, что подобные эксперименты становятся очень эффективными при наличии реальной цели. Пусть она не такая реальная, как сервер какой-то организации, которым пользуется большое количество человек, но все же это гораздо лучше, чем строить какие-то абстрактные системы в вакууме.
Вы правы. Более того, предложенные вами технологии я в различных комбинациях продолжительное время использовал. Но слишком много неизведанных технологий не давало мне покоя и аппетиты непреклонно росли.
Вероятно, имеется ввиду совместное использование докера с docker-compose . Несколько стеков + два отдельных прокси сервера для публичных и приватных приложений, в которых прописаны нужные домены. Можно использовать caddy и делегировать ему управление сертификатами.
Вопрос лишь: как в докере обеспечить сетевые политики безопасности? Верю, что вполне возможно на L3, но на L7 - сомневаюсь. Не то, чтобы это сильно принципиально, конечно, но внутреннему параноику гораздо спокойнее, когда недавно поднятое опенсорсное приложение ходит только туда, куда должно.
Что касается традиционных VPN, то непонятна их судьба в ближайшем будущем в России. У меня периодически возникали проблемы с WireGuard-ом, особенно в мобильных сетях, при том, что клиент и сервер были внутри страны. OpenVPN мне показался очень сложным в понимании и настройке - попытки настроить его для перенаправления трафика в другой VPN-сервис оканчивались неудачей.
Динамические VPN же способны самостоятельно определять какой маршрут между устройствами лучше всего проложить. Часто у меня Tailscale строил прямой вайргард тунель до сервера, когда обычный wireguard блокировался. Подозреваю, что первый использует какие-то нестандартные заголовки, чтобы прорубить NAT, которые DPI не могут отследить. В крайних случаях оно также способно тунелировать трафик через TCP/TLS.
Я допускаю, что в итоге могу просто настроить своим друзьям VLESS/VMESS на пк и телефонах как ультимативное решение, но пока динамические VPN мне интереснее, как минимум в исследовательских целях.
Тоже никогда не понимал, почему Lua считается простым языком. Можно относительно быстро объяснить человеку, что такое классы, экземпляры, и как ими пользоваться для моделирования реальных объектов. А вот чтобы дать ему этот же инструмент в Lua, ему сначала придется рассказать про метатаблицы и прототипное наследование.
Плюсую. Таким образом можно также использовать совершенно любой VPN-провайдер (и любую его локацию) как выходную ноду, а свой VPS как входную. Т.е. явно разделяются две функции:
1. обход блокировки VPN;
2. замена IP/скрытие трафика/обход блокировки ресурсов.
Еще добавлю, что если вы не доверяете своему VPS-провайдеру (особенно, если он российский), но доверяете VPN-провайдеру (который находится в другой юрисдикции и для которого вполне нормально вести no-logs политику), то можно не терминировать VPN-трафик на VPS, а просто перенаправлять его с дополнительной обфускацией. Таким образом данные шифруются на клиенте и дешифруются VPN-провайдером, а VPS уже в чистом виде занимается только обходом блокировки VPN-провайдера.
С другой стороны, выпуск нового сертификата рано или поздно раскроют мониторингом или через CT. А вот если терминировать трафик сертификатом самого же сервера (любезно украденного с ВМ, как предлагают выше), то, чтобы такое запалить, владельцу сайта нужно при мониторинге сверять согласованные ключи соединения как со стороны клиента, так и сервера. Возможно, в редких случаях, такая игра с кражей сертификата стоит свеч.
А у меня вот капча от Cloudflare всегда проходит одним нажатием кнопки. Иногда даже складывается ощущение, будто бы оно ничего и не делает, а просто выжидает. И это при VPN и куче включенных настроек по сопротивлению фингерпринтингу в Firefox. По сравнению с гуглокапчей, где нужно минуту выбирать пешеходные переходы, это выглядит как подарок.
P.S. Аналогично комментарию выше про WARP, рискну предположить, что Cloudflare просто по-разному относится к айпишникам разных VPN-провайдеров.
Хорошее замечание, но это скорее политическое ограничение, чем техническое.
Как вы уже сказали, сам по себе PKI вполне себе может работать автономно. Единственное, что делает необходимым глобальные CA, это глобальность браузеров/ОС, в которые эти CA должны быть встроены.
По поводу доверия к сертификатам
тащ майораМинцифры, Яндекс что-то мутил с Certificate Transparency. Это конечно не блокчейн, но технически тоже распределенный реестр.А вообще, если говорить про технические ограничения PKI, то похоже нельзя (поправьте, если я не прав) назначить ограничения на корневые сертификаты, чтобы те же национальные CA могли выпускать сертификаты только для собственных зон. Подобная гарантия позволила бы пользователям с меньшими колебаниями добавить их в доверенные, полагая, что конечная инфраструктура сайтов в этих зонах и так контролируется тащ майором.
Но все-таки по поводу страшных диалоговых окон - вообще не использовать HTTPS это точно не выход. Шифровать надо в любом случае, в том числе и статику, такое время.
Да, хорошее замечание.
Но стоит отметить, что подмена DNS для конечного пользователя и подмена DNS для проверяющей инфраструктуры LE - это не одно и то же.
В первом случае у нас большинство устройств по-прежнему делают нешифрованные DNS запросы сначала на роутер, а затем на DNS-серверы провайдера, который успешно пользуется этим для того же ограничения доступа к заблокированным ресурсам. Впрочем, учитывая, что DNS-трафик не шифруется, по большей части даже не важно куда он направляется.
Во втором случае я ожидаю, что арбитр с властью выдавать сертификаты практически без ограничений, будет как минимум шифровать трафик до резолверов и использовать различные источники для получения более достоверной информации.
Страшная ситуация, однако.
Но если пользователь способен закрыть подобное предупреждение двумя не очень очевидными кликами, то, наверное, ему уже не помочь)
Скрытый текст
Касательно красных замочков, имхо, давно следовало бы сделать, чтобы все сайты по HTTP открывались так, как на скрине выше. Кроме прямых обращений по приватным айпи для всяких админок у роутеров.
В эпоху HTTPS конечно сложно такое представить (в контексте подмены DNS). Даже если браузер по какой-то причине решит не обращаться к сайту по HTTPS, то неужели пользователя не смутит страшный красный замочек?
Спасибо! Кажется, что ArgoCD теперь тоже войдет в план моих ближайших экспериментов.
До ArgoCD еще руки не дошли, но когда я "примерял" его в качестве кандидата на какую-нибудь роль в этом проекте, мне показалось, что он выполняет несколько иную функцию - непрерывное развертывание приложений на большом флоте машин.
В данном случае, допущение верно лишь отчасти. Данная система скорее была спроектирована, чтобы как таракан перемещаться между серверами в практически автоматическом режиме. Это делалось с благой целью - избежать vendor-lock'a, но по факту периодически пересоздавать серверы чаще приходится в угоду разного рода экспериментам :D. Но, справедливости ради, случаи переезда серверов между разными провайдерами тоже были.
Ну эта способность есть во всех IaC-инструментах. И Pulumi это скорее альтернатива Terraform, нежели ArgoCD. Хотя пересечения в их функциональности конечно тоже есть.
NixOS в данном случае - это альтернатива SaltStack и Ansible. Можно было автоматизировать развертывание кластера поверх той же Ubuntu с помощью этих инструментов. С рядом оговорок это тоже позволило бы получить воспроизводимую установку.
В целом NixOS дает новый подход к построению воспроизводимых Linux-систем. Ansible и SaltStack способны гарантировать выполнение определенных стейтов в определенном порядке, которые за счет различных мутаций (поставить пакет, записать файл) приводят систему в искомое состояние. В NixOS же система изначально существует в искомом состоянии и атомарно (с рядом оговорок) переходит от одного состояния к другому. Она практически не способна меняться за счет императивных действий, что одновременно можно рассматривать как плюс и как минус.
Лично мне этот язык показался гораздо приятнее YML-файликов в Ansible и SLS-стейтов в SaltStack. И уж всяко приятнее старого доброго Bash. А отдельного вендора тут нет: NixOS это Linux-дистрибутив, такой же как Ubuntu со всеми вытекающими.
Спасибо за вопросы!
В чем-то вроде k3d необходимости просто не возникло, готовый в NixOS модуль прекрасно справился с этой задачей.
Про микс TF + Pulumi ответил в предпоследнем разделе - в первом просто были нужные провайдеры, которых еще не было в Pulumi. В планах оставить только один инструмент.
Размышления над per-node кластерами тоже есть в статье. Прямо сейчас у меня нету таких масштабов нагрузки, над которыми имел бы смысл кластер с несколькими нодами. Зато есть потребность в нескольких серверах, развернутых в разных окружениях с разными приложениями. А для этого наиболее оптимальны single-node кластеры. Если в будущем у меня появится небходимость в одном из таких окружений масштабировать нагрузку, то я смогу в существующий кластер добавить worker-ноды.
Cloudflare, очевидно, не способен выполнять TLS-терминацию в приватных сетях, а публичные TLS-сертификаты там все равно нужны, чтобы всегда из коробки были зеленые замочки. + проксирование от Cloudflare мне нужно не везде, а еще я опасаюсь, что это создаст еще одну серьезную внешнюю зависимость по аналогии с Tailscale. DNS-провайдеров, поддерживающих ACME DNS-01 достаточно много, а вот бесплатное проксирование трафика как в Cloudflare, вероятно, предлагают единицы.
Дополню лишь, что подобные эксперименты становятся очень эффективными при наличии реальной цели. Пусть она не такая реальная, как сервер какой-то организации, которым пользуется большое количество человек, но все же это гораздо лучше, чем строить какие-то абстрактные системы в вакууме.
Вы правы. Более того, предложенные вами технологии я в различных комбинациях продолжительное время использовал. Но слишком много неизведанных технологий не давало мне покоя и аппетиты непреклонно росли.
Вероятно, имеется ввиду совместное использование докера с
docker-compose. Несколько стеков + два отдельных прокси сервера для публичных и приватных приложений, в которых прописаны нужные домены. Можно использовать caddy и делегировать ему управление сертификатами.Вопрос лишь: как в докере обеспечить сетевые политики безопасности? Верю, что вполне возможно на L3, но на L7 - сомневаюсь. Не то, чтобы это сильно принципиально, конечно, но внутреннему параноику гораздо спокойнее, когда недавно поднятое опенсорсное приложение ходит только туда, куда должно.
Что касается традиционных VPN, то непонятна их судьба в ближайшем будущем в России. У меня периодически возникали проблемы с WireGuard-ом, особенно в мобильных сетях, при том, что клиент и сервер были внутри страны. OpenVPN мне показался очень сложным в понимании и настройке - попытки настроить его для перенаправления трафика в другой VPN-сервис оканчивались неудачей.
Динамические VPN же способны самостоятельно определять какой маршрут между устройствами лучше всего проложить. Часто у меня Tailscale строил прямой вайргард тунель до сервера, когда обычный wireguard блокировался. Подозреваю, что первый использует какие-то нестандартные заголовки, чтобы прорубить NAT, которые DPI не могут отследить. В крайних случаях оно также способно тунелировать трафик через TCP/TLS.
Я допускаю, что в итоге могу просто настроить своим друзьям VLESS/VMESS на пк и телефонах как ультимативное решение, но пока динамические VPN мне интереснее, как минимум в исследовательских целях.