Для описанной вами проблемы уже придуман esni (encrypted sni) и медленно, но верно идёт к успеху. Осталось залатать dns, чтобы любителям пассивного мониторинга и активных блокировок по DNS стало жить сложнее
Всё правильно вы написали, но к CRM ваша статья не имеет никакого отношения. Это относится к любому ПО… и не ПО тоже, вообще к закупке и внедрению любых систем, например сигнализации.
Так в заголовке же написано, что речь про сборку. Очевидно, что никто в здравом уме не будет заниматься высокотехнологичной разработкой для российского рынка.
Самая важная мысль в заключении. Собирать в РФ имеет смысл, чтобы быстро сделать партию приставок с логотипом оператора (небольшого урюпинск-телекома), китайцы это делают долго + доставка
ни в коем случае не хочу кого-то оправдывать или обвинять, но саппорт (в общем случае) это вовсе не обновления, тем более видимые. обычно, это исправление багов и секьюрити фиксы
например, покупая саппорт на какие-нибудь сервера hp и платя за это кучу тысяч долларов, возможно вы даже ни разу не обратитесь туда (обычно так и происходят. саппорт на железо это по большей части как страховка)
почему 5млн в год в российских реалиях, это вопрос, на первый взгляд кажется много, нужно понимать состав этой услуги
Статейка уровня булшит-презентаций, когда рассказывают о космических кораблях на волне хайпа.
Где ваши истории успеха?
Где lessons learned? (Не знаю как это перевести на русский, сорри)
Где ограничения применимости методологии?
Прослушивать трафик таким образом вы не сможете, т.е. вы не увидите трафик между клиентом и настоящим сервером. Просто часть клиентов будут ходить на ваш поддельный сервер.
Вы можете из своего поддельного сервера сделать реверс-прокси и писать трафик.
Т. е. один лишь hijacking не даёт возможности "просматривать"
"Захватив" чужие ip адреса, теоретически и в некоторых случаях практически, можно выписать себе валидный сертификат и воровать пароли и прочее. Но по факту есть ограничения на такие атаки. Если интересно, то можете почитать у меня в статейке https://habr.com/ru/post/442784/
Это всё до первого ддос и прочих атак, а потом вы начинаете прятаться за антиддос сервис (что вносит огромные коррективы ко всей схеме) или уходите на публичные провайдеры типа Microsoft (office365)
Просто писать про vpn в статье про почту это жуткий оверкилл.
В РФ нативно даёт Эртелеком и МТС (на мобильной сети), т.е. получить нативный ipv6 не так уж и сложно.
Ну ладно, допустим у вашего isp его нет. Но есть же туннельные брокеры https://en.m.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers (для тестов это более чем достаточно)
Допустим, по какой-то причине и это не вариант. Тогда берёте самую дешёвую vps под это дело (рекомендую использовать lowendbox/lowendtalk для поиска) и тестирует с неё, а то у вас даже тест не совсем честный, по сути внутри хоста тестируете часть вещей.
Почитайте RFC 5737, 3849. Не очень удобно читать howto, когда ip-адреса имеют вид xx.xx.xx.xx
Зря вы добавили openvpn в статью. К почте он отношения не имеет. В итоге получалась какая-то каша из настройки маршрутизации, vpn-а и почты. Хотя бы пометьте какие настройки не нужны, если не нужен vpn.
Дело в том, что теперь понятие успеха размыто. Если взять кастомную разработку для внешнего заказчика, то там с успехом всё это понятно — это пройденные тесты, подписанные акты и полученные деньги.
Если же речь идёт про другую крайность — компании (типа Яндекса), которые сами разрабатывают, сами обслуживают и сами продают свои сервисы, то здесь измерять успех команды разработки почти невозможно когда это уже действующий сервис, приносящий доход/прибыль. Владелец видит, что за год доход(другие показатели) сервиса увеличился на столько, сколько хотелось. Но успех ли это команды разработки? Может быть это удачное стечение обстоятельств, успешные маркетинговые акции или что-то ещё, а разработчики лишь сделали кучу непонятных неудобных фич, из-за которых пользователи раздражены и готовы уйти от сервиса, но пользуются по инерции.
Вот люди и развлекаются с методологиями, перераспределением обязанностей, коллективной безответственностью (я никогда не поверю в коллективную ответственность — это либо банкрот компании, либо поиск козла отпущения). Но ведь кто-то же должен это пробовать? Компания 10-100 человек не может себе позволить так рисковать, Яндекс может.
Это всё просто переименовывание ролей и перераспределение обязаннсостей. Есть множество функций, есть множество людей, обладающие различными скилл-сетами и люди просто делят функции между собой. «overhead»-люди (PM,SA,SM), делающие грязную работу, которую не хотят или не могут делать разработчики, придумывают себе новые названия, перераспределяют эту грязную работу между собой, но суть не меняется. если ты умеешь организовывать работу людей, то какая разница как ты называешься — PM или SM?
Гугл, амазон и Ко зарабатывают на сервисах, им нужно чтобы транспорт (Интернет) был почти бесплатным. Их интересы противоречат интересам ISP, которые как раз зарабатывают на траспортировке трафика. Удешевляя трафик и создавая альтернативные пути его хождения, гугл и Ко предотвращают риски, которые могут исходить от ISP (внезапное задирание цен на транспорт данных из точки А в точку Б)
>Тогда зачем тут упоминание ClickHouse в негативном ключе?
Это намёк на претензию к тем, кто опакечивает софт. К примеру, ставим mysql под ubuntu/debian, там с вас просят пароль root. Ставим clickhouse (из оф.репы) — после инсталляции имеем пустой пароль на дефолтном пользователем. Неопытные администраторы/девопсы его оставляют и имеем то, что имеем
Это обзорная статья или вы что-то новое предлагаете?
Надеюсь, что вы не внедряете что-либо в реальной жизни вашей манерой изложения.
Для описанной вами проблемы уже придуман esni (encrypted sni) и медленно, но верно идёт к успеху. Осталось залатать dns, чтобы любителям пассивного мониторинга и активных блокировок по DNS стало жить сложнее
Я в ад или рай не верю, но надеюсь, что вендоры dpi будут гореть в аду за их деятельность по помощи правительствам в борьбе с неугодными
Надеюсь что из-за шифрования вендоры dpi станут ненужными
Всё правильно вы написали, но к CRM ваша статья не имеет никакого отношения. Это относится к любому ПО… и не ПО тоже, вообще к закупке и внедрению любых систем, например сигнализации.
Так в заголовке же написано, что речь про сборку. Очевидно, что никто в здравом уме не будет заниматься высокотехнологичной разработкой для российского рынка.
Самая важная мысль в заключении. Собирать в РФ имеет смысл, чтобы быстро сделать партию приставок с логотипом оператора (небольшого урюпинск-телекома), китайцы это делают долго + доставка
10 лет работаю в ИТ, узнал что в РФ есть клон линкедина. Ваша аудитория мало имеет отношения к ИТ, все сидят на линке, у вас разве что 1С-ники
например, покупая саппорт на какие-нибудь сервера hp и платя за это кучу тысяч долларов, возможно вы даже ни разу не обратитесь туда (обычно так и происходят. саппорт на железо это по большей части как страховка)
почему 5млн в год в российских реалиях, это вопрос, на первый взгляд кажется много, нужно понимать состав этой услуги
Спасибо за статью, но самое главное в практическом смысле это не статья на хабре, а багрепорты и/или пуллреквесты
Статейка уровня булшит-презентаций, когда рассказывают о космических кораблях на волне хайпа.
Где ваши истории успеха?
Где lessons learned? (Не знаю как это перевести на русский, сорри)
Где ограничения применимости методологии?
Прослушивать трафик таким образом вы не сможете, т.е. вы не увидите трафик между клиентом и настоящим сервером. Просто часть клиентов будут ходить на ваш поддельный сервер.
Вы можете из своего поддельного сервера сделать реверс-прокси и писать трафик.
Т. е. один лишь hijacking не даёт возможности "просматривать"
"Захватив" чужие ip адреса, теоретически и в некоторых случаях практически, можно выписать себе валидный сертификат и воровать пароли и прочее. Но по факту есть ограничения на такие атаки. Если интересно, то можете почитать у меня в статейке https://habr.com/ru/post/442784/
Это всё до первого ддос и прочих атак, а потом вы начинаете прятаться за антиддос сервис (что вносит огромные коррективы ко всей схеме) или уходите на публичные провайдеры типа Microsoft (office365)
Просто писать про vpn в статье про почту это жуткий оверкилл.
В РФ нативно даёт Эртелеком и МТС (на мобильной сети), т.е. получить нативный ipv6 не так уж и сложно.
Ну ладно, допустим у вашего isp его нет. Но есть же туннельные брокеры https://en.m.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers (для тестов это более чем достаточно)
Допустим, по какой-то причине и это не вариант. Тогда берёте самую дешёвую vps под это дело (рекомендую использовать lowendbox/lowendtalk для поиска) и тестирует с неё, а то у вас даже тест не совсем честный, по сути внутри хоста тестируете часть вещей.
Почитайте RFC 5737, 3849. Не очень удобно читать howto, когда ip-адреса имеют вид xx.xx.xx.xx
Зря вы добавили openvpn в статью. К почте он отношения не имеет. В итоге получалась какая-то каша из настройки маршрутизации, vpn-а и почты. Хотя бы пометьте какие настройки не нужны, если не нужен vpn.
Дело в том, что теперь понятие успеха размыто. Если взять кастомную разработку для внешнего заказчика, то там с успехом всё это понятно — это пройденные тесты, подписанные акты и полученные деньги.
Если же речь идёт про другую крайность — компании (типа Яндекса), которые сами разрабатывают, сами обслуживают и сами продают свои сервисы, то здесь измерять успех команды разработки почти невозможно когда это уже действующий сервис, приносящий доход/прибыль. Владелец видит, что за год доход(другие показатели) сервиса увеличился на столько, сколько хотелось. Но успех ли это команды разработки? Может быть это удачное стечение обстоятельств, успешные маркетинговые акции или что-то ещё, а разработчики лишь сделали кучу непонятных неудобных фич, из-за которых пользователи раздражены и готовы уйти от сервиса, но пользуются по инерции.
Вот люди и развлекаются с методологиями, перераспределением обязанностей, коллективной безответственностью (я никогда не поверю в коллективную ответственность — это либо банкрот компании, либо поиск козла отпущения). Но ведь кто-то же должен это пробовать? Компания 10-100 человек не может себе позволить так рисковать, Яндекс может.
Это намёк на претензию к тем, кто опакечивает софт. К примеру, ставим mysql под ubuntu/debian, там с вас просят пароль root. Ставим clickhouse (из оф.репы) — после инсталляции имеем пустой пароль на дефолтном пользователем. Неопытные администраторы/девопсы его оставляют и имеем то, что имеем