И снова про свою почту
В комментариях к нашей заметке про проблемы самохостинга почты были высказаны несколько мнений, начиная от «вы просто не умеете» до «ну ничего сложного и нерешаемого там нет».
И мы, в общем и целом, с ними согласны. Проблемы поднять свою почту сейчас нет, есть куча продуктов, в том числе абсолютно бесплатных, которые буквально за 15 минут поднимут вам готовый почтовый сервер. Причем он будет сделан технически грамотно и, если вы также грамотно настроите все остальное, что у вас будет идеальный почтовый сервер… в вакууме.
Почему? Потому что ваш сервер будет вынужден функционировать с другими почтовыми серверами, в т.ч. с крупными почтовыми хостингами. А это высшая лига, где свои правила, т.е. все почтовые сервера равны, но некоторые равнее.
Это как раз про них, доставка почты с этих серверов априори доверенная, как на другие крупные хостинги, так и на мелкие частные сервера, которые используют сторонние базы антиспама. Да, там может быть контроль по содержимому и т.д., но такое письмо уже по факту отправителя получает положительные баллы.
А со своим сервером все наоборот, адрес, с которого раньше не посылалась почта автоматически получает отрицательные баллы и его нужно прогревать письмами, которые ни в коей мере не похожи на спам.
Если ваш адрес входит в пул адресов для выдачи обычным пользователям (не хостинги и датацентры), то вы сразу получаете еще больше отрицательных баллов, потому что у обычных пользователей почтовых серверов быть не должно.
Но даже если вы раскачали свой адрес, и он теперь считается валидным, то все могут испортить соседи, если из вашей подсети зараженные машины обычных пользователей начали слать спам, то в блок попадет целая подсеть, если не вся AS. Ходи потом, рассказывай, что ты не верблюд.
Постойте, скажет иной читатель, но это же обычные технические проблемы, которые должен уметь решать и умеет любой администратор почтовых систем. Все решаемо, зачем сгущать краски.
А затем, что почта для бизнеса является основным и максимально критичным каналом коммуникаций. Хотя бы даже потому, что почтовая переписка принимается судами как юридически значимая, в отличие от переписки в мессенджерах.
И проблемы с доставкой или приемом могут нести очень серьезные последствия, такие как срывы сроков, сорвавшиеся сделки, пропуск сроков давности и т.д.
Но вся беда заключается в том, что о таких проблемах невозможно узнать, читая логи, о них вам не сообщит система мониторинга и вы будете пребывать в блаженной уверенности, что все хорошо до тех пор, пока не произойдет событие, связанное с недоставкой.
О том, что поставщик перестал получать ваши письма вы узнаете уже после того, как письмо было отправлено, но не доставлено. И это произойдет не сразу, а только при выходе за рамки бизнес-процессов.
Скажем менеджер скинул заявку в пятницу, сроки поставки вторник-среда. Поэтому до этих пор никто и не почешется. А все начнется примерно в среду, когда поставщику зададут вопрос: а чего вы вчера ничего не привезли, не успели, сегодня привезете?
А поставщик честно скажет, что заявки не было. Как не было? Почему? Мы отсылали!
Пока проблема дойдет до IT-отдела пройдет еще половина дня. Еще сколько-то времени понадобиться на разбор ситуации.
Но письмо должно было быть доставлено еще в пятницу, а еще вчера торговая точка должна была получить товар. Но ничего этого не случилось и проблемы не только на почтовом сервере, проблемы у всего бизнеса – нарушилась цепочка поставки.
Бизнес стоит без товара, несет убытки. И что толку от того, что админы завтра разберутся и все уладят? Проблемы уже возникли и принесли реальный материальный ущерб.
И хорошо, если вы просто отделались малой кровью, потому что там мог быть и важный контракт и переписка с контролирующими органами, да и просто ваши маркетологи запустили очередную акцию.
Да, вы разобрались, связались, настроили, подстроили и снова все как часы, но бизнес уже раз обжегся и посматривает на вас и вашу почту косо.
В комментариях к нашей заметке про проблемы самохостинга почты были высказаны несколько мнений, начиная от «вы просто не умеете» до «ну ничего сложного и нерешаемого там нет».
И мы, в общем и целом, с ними согласны. Проблемы поднять свою почту сейчас нет, есть куча продуктов, в том числе абсолютно бесплатных, которые буквально за 15 минут поднимут вам готовый почтовый сервер. Причем он будет сделан технически грамотно и, если вы также грамотно настроите все остальное, что у вас будет идеальный почтовый сервер… в вакууме.
Почему? Потому что ваш сервер будет вынужден функционировать с другими почтовыми серверами, в т.ч. с крупными почтовыми хостингами. А это высшая лига, где свои правила, т.е. все почтовые сервера равны, но некоторые равнее.
Это как раз про них, доставка почты с этих серверов априори доверенная, как на другие крупные хостинги, так и на мелкие частные сервера, которые используют сторонние базы антиспама. Да, там может быть контроль по содержимому и т.д., но такое письмо уже по факту отправителя получает положительные баллы.
А со своим сервером все наоборот, адрес, с которого раньше не посылалась почта автоматически получает отрицательные баллы и его нужно прогревать письмами, которые ни в коей мере не похожи на спам.
Если ваш адрес входит в пул адресов для выдачи обычным пользователям (не хостинги и датацентры), то вы сразу получаете еще больше отрицательных баллов, потому что у обычных пользователей почтовых серверов быть не должно.
Но даже если вы раскачали свой адрес, и он теперь считается валидным, то все могут испортить соседи, если из вашей подсети зараженные машины обычных пользователей начали слать спам, то в блок попадет целая подсеть, если не вся AS. Ходи потом, рассказывай, что ты не верблюд.
Постойте, скажет иной читатель, но это же обычные технические проблемы, которые должен уметь решать и умеет любой администратор почтовых систем. Все решаемо, зачем сгущать краски.
А затем, что почта для бизнеса является основным и максимально критичным каналом коммуникаций. Хотя бы даже потому, что почтовая переписка принимается судами как юридически значимая, в отличие от переписки в мессенджерах.
И проблемы с доставкой или приемом могут нести очень серьезные последствия, такие как срывы сроков, сорвавшиеся сделки, пропуск сроков давности и т.д.
Но вся беда заключается в том, что о таких проблемах невозможно узнать, читая логи, о них вам не сообщит система мониторинга и вы будете пребывать в блаженной уверенности, что все хорошо до тех пор, пока не произойдет событие, связанное с недоставкой.
О том, что поставщик перестал получать ваши письма вы узнаете уже после того, как письмо было отправлено, но не доставлено. И это произойдет не сразу, а только при выходе за рамки бизнес-процессов.
Скажем менеджер скинул заявку в пятницу, сроки поставки вторник-среда. Поэтому до этих пор никто и не почешется. А все начнется примерно в среду, когда поставщику зададут вопрос: а чего вы вчера ничего не привезли, не успели, сегодня привезете?
А поставщик честно скажет, что заявки не было. Как не было? Почему? Мы отсылали!
Пока проблема дойдет до IT-отдела пройдет еще половина дня. Еще сколько-то времени понадобиться на разбор ситуации.
Но письмо должно было быть доставлено еще в пятницу, а еще вчера торговая точка должна была получить товар. Но ничего этого не случилось и проблемы не только на почтовом сервере, проблемы у всего бизнеса – нарушилась цепочка поставки.
Бизнес стоит без товара, несет убытки. И что толку от того, что админы завтра разберутся и все уладят? Проблемы уже возникли и принесли реальный материальный ущерб.
И хорошо, если вы просто отделались малой кровью, потому что там мог быть и важный контракт и переписка с контролирующими органами, да и просто ваши маркетологи запустили очередную акцию.
Да, вы разобрались, связались, настроили, подстроили и снова все как часы, но бизнес уже раз обжегся и посматривает на вас и вашу почту косо.
💯18🤡6🤔5👍3❤1
Своя почта, что говорит статистика?
Обсуждать достоинства и недостатки того или иного способа хостинга почты можно бесконечно, приводя самые различные доводы и контрдоводы. Но лучше всего обратиться к статистике, которая беспристрастно покажет текущий расклад и тенденции.
Такая статистика существует и основана она на реальном анализе интернет-трафика, мы будем опираться на академическое исследование IMC 2025 (Internet Measurement Conference). В его рамках были проанализированы реальные пути прохождения почтового трафика и собрана статистика по используемой участниками переписке инфраструктуре.
Статистика распределилась следующим образом:
🔹 Облака и публичные сервисы: 82,7% всех писем полностью используют облачные инфраструктуры
🔹Полный самохостинг: 14,3% писем отправляются и принимаются через полностью собственные сервера доменов
🔹Гибридные схемы: 3,0% писем
👉 Однако исследователи отдельно выявили некоторые региональные феномены, так, например, в России и Беларуси около 30% почтовых путей являются самохостинговыми.
При этом общий тренд показывает отход от самостоятельного хостинга в пользу облаков и публичных сервисов, так по сравнению с исследованием IMC 2021 доля доменов использующих самохостинг почты снизилось с 11,7% до 7,9%.
Также интересна статистика распределения аккаунтов по типам. Потребительская почта (аккаунты на публичных серверах, не имеющие собственного домена) составляют 74-75% от общего числа почтовых аккаунтов, но более 80% трафика генерируют не они, а корпоративные аккаунты.
Теперь перейдем к распределению трафика по типам бизнес-пользователей, данная часть отчета основана на маркетинговых исследованиях и в основном отражает ситуацию на общемировом/западном рынке.
🔸 Малый бизнес – практически 100% использование облачных сервисов, причем львиная доля использует именно потребительские аккаунты.
Мотивация тут проста – содержание собственного сервера обходится дорого. И речь тут не только о прямых затратах, а о совокупной стоимости владения.
🔸 Средний бизнес – основная опора самохостинга, количество собственных серверов в этом сегменте находится на уровне 32% и принадлежит компаниям, имеющим штат IT от 5 человек и более.
Здесь складывается достаточно интересная картина, бизнес уже вырос до состояния позволяющего самостоятельно поддерживать сложные инфраструктуры, но все еще неустойчив финансово. Поэтому покупка облачных решений на выросшее количество пользователей может стать серьезной расходной статьей бюджета.
Поэтому самохостинг почты для многих выглядит достаточно привлекательно, но почта пока не входит в стратегически важный инструмент и допускает перебои в предоставлении услуг.
🔸 Крупный бизнес – с дальнейшим ростом снова все меняется, и почта из отдельной службы превращается в целый департамент с собственной инфраструктурой, которая требует значительных затрат на поддержку и обеспечение высокой доступности.
К этому добавляются различные требования регуляторов, например, в области защиты персональных данных, финансовой информации и т.д. и т.п. Это требует дополнительной экспертизы, аудита и сертификации. Крупные облачные провайдеры имеют сертифицированные услуги разом снимая с бизнеса этот пласт проблем.
А в последнее время собственная почта стала сильным тормозом цифровой трансформации и технологического развития в основном связанным с внедрением ИИ. Согласно данным AWS использование ИИ бизнесом выросло с 55% в 2023 году до 78% в 2025.
Крупные провайдеры сейчас предлагают ИИ бесплатно, в рамках существующих тарифных планов, в то время как самостоятельное внедрение его в собственные системы требует привлечения серьезных инвестиций.
👉 Таким образом ситуация сегодня такова ,что малый бизнес преимущественно поголовно сидит на публичной пользовательской почте, а крупный давно мигрировал в корпоративные облака. А основной нишей самохостинга был и остается средний бизнес или специфические ниши, требующие именно собственного контроля над почтой.
Обсуждать достоинства и недостатки того или иного способа хостинга почты можно бесконечно, приводя самые различные доводы и контрдоводы. Но лучше всего обратиться к статистике, которая беспристрастно покажет текущий расклад и тенденции.
Такая статистика существует и основана она на реальном анализе интернет-трафика, мы будем опираться на академическое исследование IMC 2025 (Internet Measurement Conference). В его рамках были проанализированы реальные пути прохождения почтового трафика и собрана статистика по используемой участниками переписке инфраструктуре.
Статистика распределилась следующим образом:
🔹 Облака и публичные сервисы: 82,7% всех писем полностью используют облачные инфраструктуры
🔹Полный самохостинг: 14,3% писем отправляются и принимаются через полностью собственные сервера доменов
🔹Гибридные схемы: 3,0% писем
👉 Однако исследователи отдельно выявили некоторые региональные феномены, так, например, в России и Беларуси около 30% почтовых путей являются самохостинговыми.
При этом общий тренд показывает отход от самостоятельного хостинга в пользу облаков и публичных сервисов, так по сравнению с исследованием IMC 2021 доля доменов использующих самохостинг почты снизилось с 11,7% до 7,9%.
Также интересна статистика распределения аккаунтов по типам. Потребительская почта (аккаунты на публичных серверах, не имеющие собственного домена) составляют 74-75% от общего числа почтовых аккаунтов, но более 80% трафика генерируют не они, а корпоративные аккаунты.
Теперь перейдем к распределению трафика по типам бизнес-пользователей, данная часть отчета основана на маркетинговых исследованиях и в основном отражает ситуацию на общемировом/западном рынке.
🔸 Малый бизнес – практически 100% использование облачных сервисов, причем львиная доля использует именно потребительские аккаунты.
Мотивация тут проста – содержание собственного сервера обходится дорого. И речь тут не только о прямых затратах, а о совокупной стоимости владения.
🔸 Средний бизнес – основная опора самохостинга, количество собственных серверов в этом сегменте находится на уровне 32% и принадлежит компаниям, имеющим штат IT от 5 человек и более.
Здесь складывается достаточно интересная картина, бизнес уже вырос до состояния позволяющего самостоятельно поддерживать сложные инфраструктуры, но все еще неустойчив финансово. Поэтому покупка облачных решений на выросшее количество пользователей может стать серьезной расходной статьей бюджета.
Поэтому самохостинг почты для многих выглядит достаточно привлекательно, но почта пока не входит в стратегически важный инструмент и допускает перебои в предоставлении услуг.
🔸 Крупный бизнес – с дальнейшим ростом снова все меняется, и почта из отдельной службы превращается в целый департамент с собственной инфраструктурой, которая требует значительных затрат на поддержку и обеспечение высокой доступности.
К этому добавляются различные требования регуляторов, например, в области защиты персональных данных, финансовой информации и т.д. и т.п. Это требует дополнительной экспертизы, аудита и сертификации. Крупные облачные провайдеры имеют сертифицированные услуги разом снимая с бизнеса этот пласт проблем.
А в последнее время собственная почта стала сильным тормозом цифровой трансформации и технологического развития в основном связанным с внедрением ИИ. Согласно данным AWS использование ИИ бизнесом выросло с 55% в 2023 году до 78% в 2025.
Крупные провайдеры сейчас предлагают ИИ бесплатно, в рамках существующих тарифных планов, в то время как самостоятельное внедрение его в собственные системы требует привлечения серьезных инвестиций.
👉 Таким образом ситуация сегодня такова ,что малый бизнес преимущественно поголовно сидит на публичной пользовательской почте, а крупный давно мигрировал в корпоративные облака. А основной нишей самохостинга был и остается средний бизнес или специфические ниши, требующие именно собственного контроля над почтой.
👍13👎4😁2
Бренды
Очень часто в обсуждениях железа можно встретить категоричные заявления – мол только бренд NAME и больше ничего, потому что они … далее сами подставьте список достоинств, а остальные… точно также подставляем список недостатков.
Я и сам когда-то давно был таким и предпочитал видеть в своем домашнем ПК продукты именно определенного бренда, ну или нескольких.
Работа на сисадминских должностях в обычных фирмах тоже только лишь укрепляла в этом мнении и покупать даже на работу я старался продукцию любимого бренда, хотя это и было дороже. Но я считал, что покупаю надежность и стабильность бренда в пику разному дешману.
Все изменилось, когда я пошел работать в компьютерную фирму, в те времена в провинции работали в основном под заказ и по приходу машины из Москвы все, от мала до велика, невзирая на основную специальность, становились на сборку.
В те годы основной сборкой была материнская плата Acorp на 478 сокете и Celeron 1.7 ГГц на ней. Платка была бюджетная и, мягко скажем, убогонькая. Не блистала ни возможностями расширения, ни производительностью. Но отличалась вполне приличным качеством, гарантийных случаев с ней было не много.
Это был хит продаж, мы собирали их десятками и уже сразу могли сказать, если что-то шло не так. А вот брендовых сборок было немного, а когда они были, то я стремился взять их себе, мол это же бренд. Коллеги посмеивались и ничего не имели против.
И очень скоро пришло первое разочарование, брендовые и, следовательно, более дорогие платы ничего нового не показывали, работали они примерно также как бюджетный Acorp и ничем таким не выделялись.
Зато добавляли заморочки при сборке и настройке. Там могли быть нестандартные пин-панели, нестандартные наборы DIP переключателей, нестандартные режимы памяти.
Все это было интересно, но требовало времени и пока ты собирал одну сборку, твой коллега успевал скрутить полторы или две. А оплата труда шла сдельная.
Попутно с этим приходило понимание, что в масс-сегменте бренды не способны предложить ничего принципиально нового, все тоже самое, только дороже. И когда меня знакомые начинали спрашивать, а что бы нам купить для учебы или в офис, то я отвечал Acorp + Celeron 1.7.
Недорого и сердито. Надежность на уровне, а в случае чего сразу можно поменять по месту, возили этих плат много, запас всегда был. В тоже время брендовые материнки для замены уходили в Москву и человек вынужден был ждать две недели.
Кто-то сейчас скажет, мол автор ничего не понимает и любая, даже недорогая плата бренда лучше означенного Acorp так как может поддерживать более новое, более быстрое, лучше работает в каких-либо режимах и т.д. и т.п.
Да, все это так. Но кому это нужно? Обычный пользователь ПК он и слов таких не знает. Ему нужно включить и работать: писать реферат, слушать музыку, убирать красные глаза с фоточек или считать бухгалтерию.
Работает? Не глючит? И хорошо. Максимум, что потом сделают с этим ПК – это поменяют диск или добавят память. А цена часто становится одним из важнейших факторов.
Другое дело если вы энтузиаст, любите поковыряться с железом, покупаете топовые комплектующие, тогда да – ваш выбор бренды, причем бренды первого эшелона и их топовые линейки.
Там много всего интересного, но вы должны прекрасно понимать для чего и зачем вы платите те деньги, которые за них просят. И что вы потом со всеми этими гигагерцами и гигабайтами будете делать.
А становиться в позицию, что в линейные офисные станции закупаем только SSD Samsung – это глупость и снобизм, а также необоснованный расход средств работодателя. Так как можно спокойно взять немного более медленные, но гораздо более дешевые Kingston или ADATA. С надежностью у которых дела обстоят ничуть не хуже.
А провалы, скажем так, потому что на язык просилось совсем другое слово, бывают у всех. В свое время IBM, признанный лидер рынка жестких дисков, эпично сел в лужу со своими DTLA.
Относительно недавно Samsung выпустил крайне неудачную серию пятисоток 870 EVO.
Поэтому – не создаем кумиров, а просто работаем с тем, что недорого и доступно.
Очень часто в обсуждениях железа можно встретить категоричные заявления – мол только бренд NAME и больше ничего, потому что они … далее сами подставьте список достоинств, а остальные… точно также подставляем список недостатков.
Я и сам когда-то давно был таким и предпочитал видеть в своем домашнем ПК продукты именно определенного бренда, ну или нескольких.
Работа на сисадминских должностях в обычных фирмах тоже только лишь укрепляла в этом мнении и покупать даже на работу я старался продукцию любимого бренда, хотя это и было дороже. Но я считал, что покупаю надежность и стабильность бренда в пику разному дешману.
Все изменилось, когда я пошел работать в компьютерную фирму, в те времена в провинции работали в основном под заказ и по приходу машины из Москвы все, от мала до велика, невзирая на основную специальность, становились на сборку.
В те годы основной сборкой была материнская плата Acorp на 478 сокете и Celeron 1.7 ГГц на ней. Платка была бюджетная и, мягко скажем, убогонькая. Не блистала ни возможностями расширения, ни производительностью. Но отличалась вполне приличным качеством, гарантийных случаев с ней было не много.
Это был хит продаж, мы собирали их десятками и уже сразу могли сказать, если что-то шло не так. А вот брендовых сборок было немного, а когда они были, то я стремился взять их себе, мол это же бренд. Коллеги посмеивались и ничего не имели против.
И очень скоро пришло первое разочарование, брендовые и, следовательно, более дорогие платы ничего нового не показывали, работали они примерно также как бюджетный Acorp и ничем таким не выделялись.
Зато добавляли заморочки при сборке и настройке. Там могли быть нестандартные пин-панели, нестандартные наборы DIP переключателей, нестандартные режимы памяти.
Все это было интересно, но требовало времени и пока ты собирал одну сборку, твой коллега успевал скрутить полторы или две. А оплата труда шла сдельная.
Попутно с этим приходило понимание, что в масс-сегменте бренды не способны предложить ничего принципиально нового, все тоже самое, только дороже. И когда меня знакомые начинали спрашивать, а что бы нам купить для учебы или в офис, то я отвечал Acorp + Celeron 1.7.
Недорого и сердито. Надежность на уровне, а в случае чего сразу можно поменять по месту, возили этих плат много, запас всегда был. В тоже время брендовые материнки для замены уходили в Москву и человек вынужден был ждать две недели.
Кто-то сейчас скажет, мол автор ничего не понимает и любая, даже недорогая плата бренда лучше означенного Acorp так как может поддерживать более новое, более быстрое, лучше работает в каких-либо режимах и т.д. и т.п.
Да, все это так. Но кому это нужно? Обычный пользователь ПК он и слов таких не знает. Ему нужно включить и работать: писать реферат, слушать музыку, убирать красные глаза с фоточек или считать бухгалтерию.
Работает? Не глючит? И хорошо. Максимум, что потом сделают с этим ПК – это поменяют диск или добавят память. А цена часто становится одним из важнейших факторов.
Другое дело если вы энтузиаст, любите поковыряться с железом, покупаете топовые комплектующие, тогда да – ваш выбор бренды, причем бренды первого эшелона и их топовые линейки.
Там много всего интересного, но вы должны прекрасно понимать для чего и зачем вы платите те деньги, которые за них просят. И что вы потом со всеми этими гигагерцами и гигабайтами будете делать.
А становиться в позицию, что в линейные офисные станции закупаем только SSD Samsung – это глупость и снобизм, а также необоснованный расход средств работодателя. Так как можно спокойно взять немного более медленные, но гораздо более дешевые Kingston или ADATA. С надежностью у которых дела обстоят ничуть не хуже.
А провалы, скажем так, потому что на язык просилось совсем другое слово, бывают у всех. В свое время IBM, признанный лидер рынка жестких дисков, эпично сел в лужу со своими DTLA.
Относительно недавно Samsung выпустил крайне неудачную серию пятисоток 870 EVO.
Поэтому – не создаем кумиров, а просто работаем с тем, что недорого и доступно.
👍16⚡3❤3🤣3💯2
Еще раз про «соединения» WireGuard
Очень часто от коллег, да и в материалах в сети можно встретить упоминания о «соединениях», «подключениях» или «переподключениях» относительно WireGuard, что создает неправильное и искаженное восприятие происходящих процессов.
Это сильно мешает пониманию работы протокола, отладке и поиску неисправностей. Поэтому давайте разберемся как работает WireGuard на самом деле.
Протокол изначально разрабатывался с прицелом на простоту и эффективность, поэтому он делает одно дело, но делает его хорошо – а именно устанавливает защищенный туннель между двумя узлами.
Туннель WireGuard относится к туннелям без сохранения состояния (stateless), так же, как и туннели GRE или IP-IP. Это означает, что он не запоминает предыдущего состояния и не имеет никакого представления о состоянии противоположного узла.
Тем более, что в качестве транспорта используется UDP – транспортный протокол без подтверждения доставки.
В момент запуска службы WireGuard читает конфигурационные файлы и создает туннельные интерфейсы, если конфигурация не содержит ошибок, то интерфейс переходит в состояние Активен (UP) вне зависимости от состояние противоположной стороны.
И это произойдет даже в том случае, если противоположный узел выключен или недоступен. Косвенно о работе туннеля можно судить по времени с последнего рукопожатия (handshake), однако это очень и очень косвенный признак.
Например, при блокировках данного протокола у операторов связи рукопожатия могут проходить, но сам трафик в туннеле не ходит, но сам интерфейс будет показывать вам что все отлично и с точки зрения WireGuard это действительно так.
Его задача получить пакет, попадающий под одно из правил криптографической маршрутизации (не путать с маршрутизацией пакетов L3), зашифровать нужным ключом и отправить противоположному узлу (peer).
А дойдет пакет или не дойдет локальный экземпляр WireGuard не волнует, у него все хорошо, он работает. Точно также и с входящими пакетами, если пакет подпадает под правила – расшифровываем, нет – отбрасываем.
Погодите, погодите, а как же «WireGuard-сервер», адрес которого мы указываем в настройках «клиента»?
Мы не даром взяли эти термины в кавычки, на самом деле их использование некорректно. Все узлы WireGuard равнозначны и самодостаточны. Тот узел, который инициирует подключение называется инициатором, тот, который его принимает – ответчиком или респондером.
Один и тот же узел может быть и ответчиком и респондером одновременно. Но классического соединения в понимании сеанса связи не устанавливается.
Инициатор и ответчик выполняют рукопожатие, формируют общий ключ и забывают друг о друге.
Затем, получив пакет попадающий под правила криптографической маршрутизации узел проверяет срок действия ключа, при необходимости выполняет повторное рукопожатие и формирование нового ключа и отправляет пакет противоположному узлу, после чего полностью забывает про него.
Получили ответ хорошо, нет – тоже хорошо. WireGuard это не волнует, эти вопросы должно решать сетевое ПО, которое использует туннель.
А как же опция persistent-keepalive? Но она также никак не связана с «поддержанием» соединения. Ее задача совсем в ином. Если инициатор находится за NAT, то при первом обращении к ответчику в брандмауэре создается установленное соединение (ESTABLISHED) и формируются таблицы трансляции NAT.
Если после этого в туннеле не было активности, то соединение в брандмауэре будет закрыто по истечению таймаута, также будет очищена таблица трансляции и все входящие пакеты от ответчика будут отброшены, также ответчик не сможет инициировать новое рукопожатие.
Внешне это будет выглядеть как отвал пира инициатора со стороны ответчика. При первом же пакете от инициатора к ответчику связь снова будет восстановлена.
Для сохранения состояния брандмауэра и таблиц трансляции WireGuard может отправлять ответчику нулевой пакет через промежуток времени указанный в опции persistent-keepalive.
Очень часто от коллег, да и в материалах в сети можно встретить упоминания о «соединениях», «подключениях» или «переподключениях» относительно WireGuard, что создает неправильное и искаженное восприятие происходящих процессов.
Это сильно мешает пониманию работы протокола, отладке и поиску неисправностей. Поэтому давайте разберемся как работает WireGuard на самом деле.
Протокол изначально разрабатывался с прицелом на простоту и эффективность, поэтому он делает одно дело, но делает его хорошо – а именно устанавливает защищенный туннель между двумя узлами.
Туннель WireGuard относится к туннелям без сохранения состояния (stateless), так же, как и туннели GRE или IP-IP. Это означает, что он не запоминает предыдущего состояния и не имеет никакого представления о состоянии противоположного узла.
Тем более, что в качестве транспорта используется UDP – транспортный протокол без подтверждения доставки.
В момент запуска службы WireGuard читает конфигурационные файлы и создает туннельные интерфейсы, если конфигурация не содержит ошибок, то интерфейс переходит в состояние Активен (UP) вне зависимости от состояние противоположной стороны.
И это произойдет даже в том случае, если противоположный узел выключен или недоступен. Косвенно о работе туннеля можно судить по времени с последнего рукопожатия (handshake), однако это очень и очень косвенный признак.
Например, при блокировках данного протокола у операторов связи рукопожатия могут проходить, но сам трафик в туннеле не ходит, но сам интерфейс будет показывать вам что все отлично и с точки зрения WireGuard это действительно так.
Его задача получить пакет, попадающий под одно из правил криптографической маршрутизации (не путать с маршрутизацией пакетов L3), зашифровать нужным ключом и отправить противоположному узлу (peer).
А дойдет пакет или не дойдет локальный экземпляр WireGuard не волнует, у него все хорошо, он работает. Точно также и с входящими пакетами, если пакет подпадает под правила – расшифровываем, нет – отбрасываем.
Погодите, погодите, а как же «WireGuard-сервер», адрес которого мы указываем в настройках «клиента»?
Мы не даром взяли эти термины в кавычки, на самом деле их использование некорректно. Все узлы WireGuard равнозначны и самодостаточны. Тот узел, который инициирует подключение называется инициатором, тот, который его принимает – ответчиком или респондером.
Один и тот же узел может быть и ответчиком и респондером одновременно. Но классического соединения в понимании сеанса связи не устанавливается.
Инициатор и ответчик выполняют рукопожатие, формируют общий ключ и забывают друг о друге.
Затем, получив пакет попадающий под правила криптографической маршрутизации узел проверяет срок действия ключа, при необходимости выполняет повторное рукопожатие и формирование нового ключа и отправляет пакет противоположному узлу, после чего полностью забывает про него.
Получили ответ хорошо, нет – тоже хорошо. WireGuard это не волнует, эти вопросы должно решать сетевое ПО, которое использует туннель.
А как же опция persistent-keepalive? Но она также никак не связана с «поддержанием» соединения. Ее задача совсем в ином. Если инициатор находится за NAT, то при первом обращении к ответчику в брандмауэре создается установленное соединение (ESTABLISHED) и формируются таблицы трансляции NAT.
Если после этого в туннеле не было активности, то соединение в брандмауэре будет закрыто по истечению таймаута, также будет очищена таблица трансляции и все входящие пакеты от ответчика будут отброшены, также ответчик не сможет инициировать новое рукопожатие.
Внешне это будет выглядеть как отвал пира инициатора со стороны ответчика. При первом же пакете от инициатора к ответчику связь снова будет восстановлена.
Для сохранения состояния брандмауэра и таблиц трансляции WireGuard может отправлять ответчику нулевой пакет через промежуток времени указанный в опции persistent-keepalive.
👍24❤4⚡2
Настраиваем сервер Pure-FTPd в контейнере Docker
FTP-протокол, несмотря на преклонный возраст, продолжает активно использоваться, преимущественно для разных обменов: товароучетным ПО, торговым и промышленным оборудованием, оргтехникой.
В большинстве случаев клиенты не поддерживают шифрование и протокол используется в открытом виде, что, конечно же, по современным меркам небезопасно, но тут выбирать не приходится.
В нашем случае возникла потребность быстро настроить новый сервер для сети розничных магазинов, работающих на базе 1С:Предприятие. Проанализировав все за и против мы выбрали вариант с Docker.
Основных аргументов два: изоляция небезопасного сервера от хоста и независимость от пакетной базы дистрибутива, что дает возможность гибко управлять жизненным циклом ПО.
Нами был выбран образ stilliard/pure-ftpd:hardened, это популярный, поддерживаемый образ с уже внесенными из коробки настройками безопасности.
Допустим наш проект будет располагаться в
Сразу установим на них нужные права:
Затем создадим docker-compose.yml следующего содержимого:
После запуска контейнера создадим пользователей командой:
Создав всех пользователей, скомпилируем базу паролей:
Теперь сервер полностью готов принимать соединения.
Сразу поясним несколько моментов. Кроме управляющего порта 21 мы указываем порты для передачи данных в пассивном режиме 60000-60499, активный режим работы сервера не предусмотрен.
Количество портов выбирайте исходя из количества активных клиентов, по умолчанию сервер допускает до пяти одновременных соединений. Таким образом указав диапазон в 500 портов, мы можем полноценно обслуживать до 100 клиентов.
Флаг -d включает режим визуализиции лога в режиме отладки, вы будете видеть все команды клиента, пароль в целях безопасности заменяется в логе звездочкой. Если вы хотите видеть еще и ответы сервера – добавьте второй флаг -d.
Переменная окружения PUBLICHOST: exch.example.com указывает на публичное имя сервера (или его IP-адрес), который будет передаваться клиенту для подключения, используйте для этого реальное внешнее имя или адрес хоста.
Переменная FTP_PASSIVE_PORTS: 60000:60499 и флаг -p 60000:60499 на первый взгляд дублируют друг друга, но на самом деле это разные опции. Флаг запускает службу на прослушивание указанных портов, а переменная говорит службе какой диапазон портов можно сообщать клиентам для подключения. Для нормальной работы их значения должны совпадать.
FTP-протокол, несмотря на преклонный возраст, продолжает активно использоваться, преимущественно для разных обменов: товароучетным ПО, торговым и промышленным оборудованием, оргтехникой.
В большинстве случаев клиенты не поддерживают шифрование и протокол используется в открытом виде, что, конечно же, по современным меркам небезопасно, но тут выбирать не приходится.
В нашем случае возникла потребность быстро настроить новый сервер для сети розничных магазинов, работающих на базе 1С:Предприятие. Проанализировав все за и против мы выбрали вариант с Docker.
Основных аргументов два: изоляция небезопасного сервера от хоста и независимость от пакетной базы дистрибутива, что дает возможность гибко управлять жизненным циклом ПО.
Нами был выбран образ stilliard/pure-ftpd:hardened, это популярный, поддерживаемый образ с уже внесенными из коробки настройками безопасности.
Допустим наш проект будет располагаться в
/opt/exch, поэтому первым делом создадим папки пользователей и служебный каталог для хранения базы паролей:mkdir -p /opt/exch/data/{user1,user2,user3,user4,user5}
mkdir -p /opt/exch/pure-ftpdСразу установим на них нужные права:
chown -R 1000:1000 /opt/exch/data /opt/exch/pure-ftpd
Затем создадим docker-compose.yml следующего содержимого:
services:
pure-ftpd:
image: stilliard/pure-ftpd:hardened
container_name: pure-ftpd
restart: unless-stopped
ports:
- "21:21"
- "60000-60499:60000-60499"
environment:
PUBLICHOST: exch.example.com
FTP_PASSIVE_PORTS: 60000:60499
ADDED_FLAGS: "-d -p 60000:60499"
TZ: "Europe/Moscow"
volumes:
- /opt/exch/data:/home/ftpusers
- /opt/exch/pure-ftpd:/etc/pure-ftpd
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"
После запуска контейнера создадим пользователей командой:
docker exec -it pure-ftpd pure-pw useradd user1 \
-u ftpuser -d /home/ftpusers/user1
Создав всех пользователей, скомпилируем базу паролей:
docker exec pure-ftpd pure-pw mkdb
Теперь сервер полностью готов принимать соединения.
Сразу поясним несколько моментов. Кроме управляющего порта 21 мы указываем порты для передачи данных в пассивном режиме 60000-60499, активный режим работы сервера не предусмотрен.
Количество портов выбирайте исходя из количества активных клиентов, по умолчанию сервер допускает до пяти одновременных соединений. Таким образом указав диапазон в 500 портов, мы можем полноценно обслуживать до 100 клиентов.
Флаг -d включает режим визуализиции лога в режиме отладки, вы будете видеть все команды клиента, пароль в целях безопасности заменяется в логе звездочкой. Если вы хотите видеть еще и ответы сервера – добавьте второй флаг -d.
Переменная окружения PUBLICHOST: exch.example.com указывает на публичное имя сервера (или его IP-адрес), который будет передаваться клиенту для подключения, используйте для этого реальное внешнее имя или адрес хоста.
Переменная FTP_PASSIVE_PORTS: 60000:60499 и флаг -p 60000:60499 на первый взгляд дублируют друг друга, но на самом деле это разные опции. Флаг запускает службу на прослушивание указанных портов, а переменная говорит службе какой диапазон портов можно сообщать клиентам для подключения. Для нормальной работы их значения должны совпадать.
👍14❤2
Coreutils for Windows
Компания Microsoft представила порт набора утилит Coreutils для платформы Windows. В состав входит несколько десятков утилит, включая sort, cat, chmod, chown, cp, find, sleep, sort, tee, echo, uptime и ls. Инструментарий позволяет напрямую использовать в Windows типовые утилиты, доступные в Linux и macOS, без использования прослойки WSL.
Целью проекта заявлено упрощение перехода между Unix-подобными системами, WSL, контейнерами и Windows, и предоставление единого набора команд, флагов и методов, позволяющих переносить существующие скрипты из других систем без переписывания. Код написан на Rust и PowerShell, и распространяется под лицензией MIT.
Реализация основана на коде проекта uutils (Rust Coreutils), развивающего вариант GNU Coreutils на языке Rust, а также реализациях утилит find и grep на Rust. Утилиты собраны в виде одного универсального исполняемого файла "C:\Program Files\coreutils\coreutils.exe", отдельные команды к которому привязаны при помощи жёстких ссылок в NTFS.
Из-за конфликта с имеющимися штатными утилитами Windows или привязки к специфичным возможностям из поставки исключены утилиты dd, dir, dircolors, shred, sync, uname, expand, kill, more, paste, timeout и whoami. Из состава также исключены утилиты, завязанные на не поддерживаемые в Windows концепции POSIX: chcon, chgrp, chmod, chown, chroot, groups, hostid, id, install, logname, mkfifo, mknod, nice, nohup, pathchk, pinky, runcon, stdbuf, stty, tty, users, who.
Из ограничений и особенностей отмечается необходимость использовать NUL вместо /dev/null, отсутствие поддержки сигналов (SIGHUP, SIGPIPE, SIGUSR), возможность создания символических ссылок только после включения режима для разработчика, недоступность некоторых операций с правами доступа. При работе с каталогами принимаются как пути с символом "/", так и c "\".
✅ По материалам: https://www.opennet.ru/opennews/art.shtml?num=65609
Компания Microsoft представила порт набора утилит Coreutils для платформы Windows. В состав входит несколько десятков утилит, включая sort, cat, chmod, chown, cp, find, sleep, sort, tee, echo, uptime и ls. Инструментарий позволяет напрямую использовать в Windows типовые утилиты, доступные в Linux и macOS, без использования прослойки WSL.
Целью проекта заявлено упрощение перехода между Unix-подобными системами, WSL, контейнерами и Windows, и предоставление единого набора команд, флагов и методов, позволяющих переносить существующие скрипты из других систем без переписывания. Код написан на Rust и PowerShell, и распространяется под лицензией MIT.
Реализация основана на коде проекта uutils (Rust Coreutils), развивающего вариант GNU Coreutils на языке Rust, а также реализациях утилит find и grep на Rust. Утилиты собраны в виде одного универсального исполняемого файла "C:\Program Files\coreutils\coreutils.exe", отдельные команды к которому привязаны при помощи жёстких ссылок в NTFS.
Из-за конфликта с имеющимися штатными утилитами Windows или привязки к специфичным возможностям из поставки исключены утилиты dd, dir, dircolors, shred, sync, uname, expand, kill, more, paste, timeout и whoami. Из состава также исключены утилиты, завязанные на не поддерживаемые в Windows концепции POSIX: chcon, chgrp, chmod, chown, chroot, groups, hostid, id, install, logname, mkfifo, mknod, nice, nohup, pathchk, pinky, runcon, stdbuf, stty, tty, users, who.
Из ограничений и особенностей отмечается необходимость использовать NUL вместо /dev/null, отсутствие поддержки сигналов (SIGHUP, SIGPIPE, SIGUSR), возможность создания символических ссылок только после включения режима для разработчика, недоступность некоторых операций с правами доступа. При работе с каталогами принимаются как пути с символом "/", так и c "\".
✅ По материалам: https://www.opennet.ru/opennews/art.shtml?num=65609
👍16🤮6🤣3🤔2❤1
Записки IT специалиста
По этой теме не утихают холивары, поэтому повторим данный материал. Папка, каталог или директория? Данный вопрос давно занимает умы коллег и является предметом частых споров на счет того, какой из этих терминов является единственно правильным. Сегодня…
Папка, каталог или директория?
Данный вопрос давно занимает умы коллег и является предметом частых споров на счет того, какой из этих терминов является единственно правильным.
Сегодня в очередной раз пришлось столкнуться с измышлениями на данную тему, что и послужило поводом для написания данной заметки.
Начнем с языковых трудностей. В английском языке есть два слова: directory и catalog, которые переводятся на русский как каталог.
Но имеют различный смысл, directory, по сути, ближе к справочнику, это список однотипных данных, предназначенный для поиска по нему. Например: телефонный или адресный справочник.
Но встречаются и варианты со словом каталог, скажем, каталог запчастей. Хотя на английском все это будет directory (Parts Directory).
Слово catalog применяется для коллекций однотипных элементов предполагающий их более широкий выбор и обработку. Например, каталог марок, монет, книг. Каталог интернет-магазина и т.д. и т.п. Т.е. каталог не предназначен только для поиска, а содержит исчерпывающие данные о каждом элементе, позволяя подробно ознакомиться с ним.
Но вернемся к файловым системам, первоначально файловые системы были плоские, т.е. все файлы находились в единственном корневом каталоге. Потом возникла иерархия на основе тех самых каталогов.
Каталог представлял и представляет специальный файл с набором записей о принадлежащих ему файлах и подкаталогах, которые содержат имя объекта и ссылку на место файловой системы (кластер, inode) где он хранится.
В английском языке данная структура однозначно попадает под понятие directory и на русский переводится как каталог. И литературно правильно использовать именно этот термин.
Слово директория возникло в любительских переводах 90-х, когда этим занимались различные энтузиасты и представляет обычную транслитерацию слова directory. По подобному принципу возникли флоппи и хард диски вместо гибких и жестких.
Но данный термин плотно вошел сначала в компьютерный сленг, а после и в русский язык и также обрел массовое употребление.
В настоящий момент слово директория употребляется в том числе и серьезной компьютерной литературе в качестве синонима слова каталог и их можно считать полностью равнозначными.
За рубежом же никакого разночтения не было и повсеместно использовался термин directory, что нашло отражение в командах: cd, dir, mkdir и т.д.
Иногда встречается ошибочное мнение, что директории – это в UNIX/Linux, а каталоги в DOS/Windows, однако это не так. Достаточно взять англоязычные версии и убедиться, что кроме directory никаких иных терминов не используется.
Шло время, компьютеры становились все более распространенными и все чаще работать с ними начинали обычные пользователи, далекие от всех этих технических терминов.
Чтобы облегчить им работу была придумана концепция рабочего стола, который логически повторял обычный рабочий стол. Файлы представлялись как документы, а каталоги как папки (folder) с этими документами.
С тех пор повелось файлы изображать преимущественно в виде близком бумажным документам, а каталоги в виде канцелярских папок. Такой подход впервые был внедрен в Apple в Mac System Software, предшественнице Mac OS.
Начиная с Windows 95 папки стали использоваться в ОС Microsoft, а также перекочевали в графические оболочки Linux, первоначально в KDE и GNOME.
Со временем термин стал общеупотребительным и стал употребляться наравне с directory (каталогом). В русском языке появилось сразу три термина обозначающие одно и то же: каталог, папка и директория.
Существует еще одно заблуждение, что термин папка можно применять только в графической среде. Однако это не так. Каталог – это объект файловой системы и его свойства не меняются в зависимости от наличия или отсутствия графической оболочки. И поэтому мы можем называть его любым из этих трех терминов.
Данный вопрос давно занимает умы коллег и является предметом частых споров на счет того, какой из этих терминов является единственно правильным.
Сегодня в очередной раз пришлось столкнуться с измышлениями на данную тему, что и послужило поводом для написания данной заметки.
Начнем с языковых трудностей. В английском языке есть два слова: directory и catalog, которые переводятся на русский как каталог.
Но имеют различный смысл, directory, по сути, ближе к справочнику, это список однотипных данных, предназначенный для поиска по нему. Например: телефонный или адресный справочник.
Но встречаются и варианты со словом каталог, скажем, каталог запчастей. Хотя на английском все это будет directory (Parts Directory).
Слово catalog применяется для коллекций однотипных элементов предполагающий их более широкий выбор и обработку. Например, каталог марок, монет, книг. Каталог интернет-магазина и т.д. и т.п. Т.е. каталог не предназначен только для поиска, а содержит исчерпывающие данные о каждом элементе, позволяя подробно ознакомиться с ним.
Но вернемся к файловым системам, первоначально файловые системы были плоские, т.е. все файлы находились в единственном корневом каталоге. Потом возникла иерархия на основе тех самых каталогов.
Каталог представлял и представляет специальный файл с набором записей о принадлежащих ему файлах и подкаталогах, которые содержат имя объекта и ссылку на место файловой системы (кластер, inode) где он хранится.
В английском языке данная структура однозначно попадает под понятие directory и на русский переводится как каталог. И литературно правильно использовать именно этот термин.
Слово директория возникло в любительских переводах 90-х, когда этим занимались различные энтузиасты и представляет обычную транслитерацию слова directory. По подобному принципу возникли флоппи и хард диски вместо гибких и жестких.
Но данный термин плотно вошел сначала в компьютерный сленг, а после и в русский язык и также обрел массовое употребление.
В настоящий момент слово директория употребляется в том числе и серьезной компьютерной литературе в качестве синонима слова каталог и их можно считать полностью равнозначными.
За рубежом же никакого разночтения не было и повсеместно использовался термин directory, что нашло отражение в командах: cd, dir, mkdir и т.д.
Иногда встречается ошибочное мнение, что директории – это в UNIX/Linux, а каталоги в DOS/Windows, однако это не так. Достаточно взять англоязычные версии и убедиться, что кроме directory никаких иных терминов не используется.
Шло время, компьютеры становились все более распространенными и все чаще работать с ними начинали обычные пользователи, далекие от всех этих технических терминов.
Чтобы облегчить им работу была придумана концепция рабочего стола, который логически повторял обычный рабочий стол. Файлы представлялись как документы, а каталоги как папки (folder) с этими документами.
С тех пор повелось файлы изображать преимущественно в виде близком бумажным документам, а каталоги в виде канцелярских папок. Такой подход впервые был внедрен в Apple в Mac System Software, предшественнице Mac OS.
Начиная с Windows 95 папки стали использоваться в ОС Microsoft, а также перекочевали в графические оболочки Linux, первоначально в KDE и GNOME.
Со временем термин стал общеупотребительным и стал употребляться наравне с directory (каталогом). В русском языке появилось сразу три термина обозначающие одно и то же: каталог, папка и директория.
Существует еще одно заблуждение, что термин папка можно применять только в графической среде. Однако это не так. Каталог – это объект файловой системы и его свойства не меняются в зависимости от наличия или отсутствия графической оболочки. И поэтому мы можем называть его любым из этих трех терминов.
👍27❤2👀2
Squid - жив, курилка
Кто из нас не знает Squid? Ну из админов старшего поколения Squid знают все и многие его ставили и настраивали. На нашем сайте был большой цикл статей, посвященный этому продукту и пользовавшийся непременной популярностью.
Squid тогда был не просто кеширующий прокси-сервер, хотя на медленных каналах кеш тоже неплохо выручал, особенно если много пользователей работали с одними и теми же ресурсами.
Squid позволял осуществлять инспекцию и фильтрацию трафика, показывая кто куда ходил, когда и зачем. А также мог управлять аутентификацией и ограничением скорости. В общем универсальный солдат, который должен был быть на каждом шлюзе.
А что же сейчас? А сейчас Squid все еще жив, заметив в новостях заметку о выходе новой версии 7.6 я решил посмотреть, чем живет и дышит популярный проект.
Сегодня былой популярности уже нет, разработка ведется силами 4-5 человек и особой активности в ней не наблюдается. Можно сказать, что эпоха бурного развития прошла и сегодня проект больше держится на ряде старожилов, притока молодой крови в нем нет.
Активный спад разработки начался в конце 2017 года и выглядит как достаточно резкое охлаждение проекта, как будто он внезапно перестал быть интересен или возникли какие-то иные сложности.
На самом деле тако оно и было, потому что именно с января 2017 Google стал помечать сайты без HTTPS как небезопасные в браузере и понижать их в поисковой выдаче, что завершило переход сайтов на HTTPS и практически не оставило незащищенных сайтов, на работу с которыми был ориентирован Squid.
К этому добавилось внедрение HTTP/2 и более сложных криптографических алгоритмов, что сделало инспекцию и контроль трафика сложной и дорогостоящей задачей. Да, Squid научился расшифровывать и проверять HTTPS-трафик, то технически это был совсем уже иной элемент инфраструктуры.
А сложностей там было порядочно, как технических, так и организационных, поэтому сама идея инспекции и контроля трафика для многих отошла на второй план, потому что не являлась насущной задачей и начинала стоить несоизмеримо дорого.
После чего сама потребность в Squid сошла на ноль, так как остальные задачи вполне успешно решались без его помощи.
Все это отразилось на популярности проекта и активности разработки. А из популярного продукта, который знали все Squid превратился во что-то нишевое, о котором молодое поколение даже и не слышало.
Кто из нас не знает Squid? Ну из админов старшего поколения Squid знают все и многие его ставили и настраивали. На нашем сайте был большой цикл статей, посвященный этому продукту и пользовавшийся непременной популярностью.
Squid тогда был не просто кеширующий прокси-сервер, хотя на медленных каналах кеш тоже неплохо выручал, особенно если много пользователей работали с одними и теми же ресурсами.
Squid позволял осуществлять инспекцию и фильтрацию трафика, показывая кто куда ходил, когда и зачем. А также мог управлять аутентификацией и ограничением скорости. В общем универсальный солдат, который должен был быть на каждом шлюзе.
А что же сейчас? А сейчас Squid все еще жив, заметив в новостях заметку о выходе новой версии 7.6 я решил посмотреть, чем живет и дышит популярный проект.
Сегодня былой популярности уже нет, разработка ведется силами 4-5 человек и особой активности в ней не наблюдается. Можно сказать, что эпоха бурного развития прошла и сегодня проект больше держится на ряде старожилов, притока молодой крови в нем нет.
Активный спад разработки начался в конце 2017 года и выглядит как достаточно резкое охлаждение проекта, как будто он внезапно перестал быть интересен или возникли какие-то иные сложности.
На самом деле тако оно и было, потому что именно с января 2017 Google стал помечать сайты без HTTPS как небезопасные в браузере и понижать их в поисковой выдаче, что завершило переход сайтов на HTTPS и практически не оставило незащищенных сайтов, на работу с которыми был ориентирован Squid.
К этому добавилось внедрение HTTP/2 и более сложных криптографических алгоритмов, что сделало инспекцию и контроль трафика сложной и дорогостоящей задачей. Да, Squid научился расшифровывать и проверять HTTPS-трафик, то технически это был совсем уже иной элемент инфраструктуры.
А сложностей там было порядочно, как технических, так и организационных, поэтому сама идея инспекции и контроля трафика для многих отошла на второй план, потому что не являлась насущной задачей и начинала стоить несоизмеримо дорого.
После чего сама потребность в Squid сошла на ноль, так как остальные задачи вполне успешно решались без его помощи.
Все это отразилось на популярности проекта и активности разработки. А из популярного продукта, который знали все Squid превратился во что-то нишевое, о котором молодое поколение даже и не слышало.
👍7💯7❤5🤮1
А теперь давайте все сломаем!
Такое предложение часто ставит в тупик как заказчиков, так и внешних подрядчиков, но мы регулярно это делаем, особенно перед вводом в эксплуатацию или принятии решения о внедрении.
Смысл его прост, берем новый чистый компьютер или виртуальную машину и пытаемся восстановить систему из бекапа, а заодно смотрим как легко или не очень это сделать и какие подводные камни при этом всплывают.
Заодно отсекаются различные нежизнеспособные конфигурации, которые могут красиво выглядеть на бумаге, но не позволяющие выполнить восстановление в необходимые сроки в необходимом объеме.
Заодно становится понятно, как именно надо бекапить и какие ресурсы для этого иметь.
В общем – задача непростая, но необходимая, как и учения подобного рода. Без такого тестирования вводить в эксплуатацию что-то серьезное – это очень сильно рисковать.
Но бывают и интересные случаи. У одного заказчика закончилась опытная эксплуатация новой системы. Внешний подрядчик все установил, настроил, они месяц тестировали – вроде все хорошо. Надо принимать решение.
Предлагаем подрядчикам последний тест. Все сломать и поднять систему из бекапов. Молчание, консультации с руководством, потом, вроде как, с разработчиками и вердикт – мы такое не делаем.
Ок, дайте нам инструкцию, мы сделаем сами. Ответ – подобные инструкции это в техподдержку, а для этого сначала купите сам продукт и поддержку к нему. Занавес.
Заказчик в раздумье, вроде и продукт хороший, вроде все нравится, но мы его сразу предупредили, что, взяв его на обслуживание обложим дополнительным соглашением, по которому вообще ничего не гарантируем, кроме работоспособности ОС и железа.
А вообще, подход крайне странный. Что секретного в способах резервного копирования и восстановления продукта? Разве в том, что их нет?
Такое предложение часто ставит в тупик как заказчиков, так и внешних подрядчиков, но мы регулярно это делаем, особенно перед вводом в эксплуатацию или принятии решения о внедрении.
Смысл его прост, берем новый чистый компьютер или виртуальную машину и пытаемся восстановить систему из бекапа, а заодно смотрим как легко или не очень это сделать и какие подводные камни при этом всплывают.
Заодно отсекаются различные нежизнеспособные конфигурации, которые могут красиво выглядеть на бумаге, но не позволяющие выполнить восстановление в необходимые сроки в необходимом объеме.
Заодно становится понятно, как именно надо бекапить и какие ресурсы для этого иметь.
В общем – задача непростая, но необходимая, как и учения подобного рода. Без такого тестирования вводить в эксплуатацию что-то серьезное – это очень сильно рисковать.
Но бывают и интересные случаи. У одного заказчика закончилась опытная эксплуатация новой системы. Внешний подрядчик все установил, настроил, они месяц тестировали – вроде все хорошо. Надо принимать решение.
Предлагаем подрядчикам последний тест. Все сломать и поднять систему из бекапов. Молчание, консультации с руководством, потом, вроде как, с разработчиками и вердикт – мы такое не делаем.
Ок, дайте нам инструкцию, мы сделаем сами. Ответ – подобные инструкции это в техподдержку, а для этого сначала купите сам продукт и поддержку к нему. Занавес.
Заказчик в раздумье, вроде и продукт хороший, вроде все нравится, но мы его сразу предупредили, что, взяв его на обслуживание обложим дополнительным соглашением, по которому вообще ничего не гарантируем, кроме работоспособности ОС и железа.
А вообще, подход крайне странный. Что секретного в способах резервного копирования и восстановления продукта? Разве в том, что их нет?
👍24🔥7❤4🤔2🤮1
SRE тут? Нашли для вас подкаст, который вполне может пополнить ряд любимых.
Коллеги из Авито создали «В SREду на кухне», периодически собираются, зовут на запись гостей и обсуждают то, о чём не принято говорить в опенспейсе. Например, вот темы недавних выпусков:
— GitOps не волшебная таблетка;
— Зачем продукту бюджет ошибок;
— Роняем прод, чтобы стать сильнее: всё о Chaos Engineering;
— SRE больше не нужны. AI переписал правила.
Отвечая на вопрос «А при чём здесь комьюнити?» — все дополнительные инсайты, статьи и мысли на темы выпусков ребята выкладывают в канал «Avito SREда». И там уже собралась активная аудитория коллег-инженеров.
Коллеги из Авито создали «В SREду на кухне», периодически собираются, зовут на запись гостей и обсуждают то, о чём не принято говорить в опенспейсе. Например, вот темы недавних выпусков:
— GitOps не волшебная таблетка;
— Зачем продукту бюджет ошибок;
— Роняем прод, чтобы стать сильнее: всё о Chaos Engineering;
— SRE больше не нужны. AI переписал правила.
Отвечая на вопрос «А при чём здесь комьюнити?» — все дополнительные инсайты, статьи и мысли на темы выпусков ребята выкладывают в канал «Avito SREда». И там уже собралась активная аудитория коллег-инженеров.
🤮2❤1👍1
Как узнать зашитый в BIOS/UEFI ключ Windows?
Последние годы ноутбуки, моноблоки и часть системных блоков идет без лицензионных OEM-наклеек на корпусе, так как ключ производитель зашивает в BIOS.
Как узнать этот ключ или хотя бы подтвердить его наличие? Все просто, достаточно одной команды, которую следует выполнить с правами администратора:
Если ключ есть, то вы его увидите, если вывод содержит пустую строку, то OEM-ключа на устройстве нет.
Последние годы ноутбуки, моноблоки и часть системных блоков идет без лицензионных OEM-наклеек на корпусе, так как ключ производитель зашивает в BIOS.
Как узнать этот ключ или хотя бы подтвердить его наличие? Все просто, достаточно одной команды, которую следует выполнить с правами администратора:
wmic path softwarelicensingservice get OA3xOriginalProductKey
Если ключ есть, то вы его увидите, если вывод содержит пустую строку, то OEM-ключа на устройстве нет.
👍35👌3❤1
Установка KMS сервера активации Microsoft на базе vlmcsd
Непростые времена требуют непростых решений. На фоне блокировок вендора даже легальные пользователи начинают испытывать затруднения.
Но есть хорошая альтернатива – пакет vlmcsd эмулирующий KMS-сервер и позволяющий активировать продукты Microsoft.
Напомним, мы крайне негативно относимся к использованию нелицензионного ПО, данный материал ни в коем случае не призывает и не поощряет его использование.
Приведенное решение полностью базируется на открытом ПО и не преследует цели нарушения норм действующего законодательства и правил лицензирования ПО.
При этом мы не просто рассказываем, как установить пакет vlmcsd, но и помогаем собрать его правильно, чтобы после установки не пришлось дорабатывать инсталляцию напильником
✅ Читать далее: https://interface31.ru/post/ustanovka-kms-servera-aktivacii-microsoft-na-baze-vlmcsd-v-debian-ili-ubuntu/
Непростые времена требуют непростых решений. На фоне блокировок вендора даже легальные пользователи начинают испытывать затруднения.
Но есть хорошая альтернатива – пакет vlmcsd эмулирующий KMS-сервер и позволяющий активировать продукты Microsoft.
Напомним, мы крайне негативно относимся к использованию нелицензионного ПО, данный материал ни в коем случае не призывает и не поощряет его использование.
Приведенное решение полностью базируется на открытом ПО и не преследует цели нарушения норм действующего законодательства и правил лицензирования ПО.
При этом мы не просто рассказываем, как установить пакет vlmcsd, но и помогаем собрать его правильно, чтобы после установки не пришлось дорабатывать инсталляцию напильником
✅ Читать далее: https://interface31.ru/post/ustanovka-kms-servera-aktivacii-microsoft-na-baze-vlmcsd-v-debian-ili-ubuntu/
👍28❤3
Установка Aspia в Docker
Система удаленного доступа Aspia пользуется заслуженной популярностью, но при ее развертывании есть некоторые особенности – пакеты собраны для Ubuntu 20.04 или Debian 11, которые на сегодня являются устаревшими.
Также, по нашим временам, для подобного ПО хочется большей переносимости, чтобы в случае чего можно было быстро мигрировать на новое место.
Для этих целей удобно использовать контейнеры, но официального Docker-образа для Aspia нет, есть неофициальный, созданный одним из участников сообщества, который сам активно использует этот продукт.
Допустим мы разместим проект в /opt/aspia, сразу создадим там две служебные директории для хранения базы данных и конфигов:
Затем создадим docker-compose.yml со следующим содержимым:
Где вам потребуется указать имя хоста узла Aspia и внешний IP-адрес, по которому вы будете принимать внешние подключения.
Если вы переносите уже существующую инсталляцию сразу разместите в папках конфиги и публичный ключ в ./data/config и базу данных в
Сразу после запуска контейнер готов к работе, хотя вы можете произвести более тонкие настройки через конфигурационные файлы.
Наиболее популярный тюнинг – это изменение диапазона ID клиентов, которые по умолчанию начинаются с единицы. Но это не сложно исправить.
Останавливаем службу:
Устанавливаем sqlite:
Подключаемся к базе и правим нужную запись:
В нашем случае мы установили начальное значение 3000. Обратите внимание, что это нужно сделать до того, как вы начали подключать клиентов.
После чего снова запускаем службу, сервер Aspia готов к работе.
Система удаленного доступа Aspia пользуется заслуженной популярностью, но при ее развертывании есть некоторые особенности – пакеты собраны для Ubuntu 20.04 или Debian 11, которые на сегодня являются устаревшими.
Также, по нашим временам, для подобного ПО хочется большей переносимости, чтобы в случае чего можно было быстро мигрировать на новое место.
Для этих целей удобно использовать контейнеры, но официального Docker-образа для Aspia нет, есть неофициальный, созданный одним из участников сообщества, который сам активно использует этот продукт.
Допустим мы разместим проект в /opt/aspia, сразу создадим там две служебные директории для хранения базы данных и конфигов:
mkdir -p /opt/aspia/data/{database,config}Затем создадим docker-compose.yml со следующим содержимым:
services:
aspia-server:
image: paprikkafox/aspia-server:latest
container_name: aspia-server
hostname: aspia.example.com
environment:
- EXTERNAL_IP=203.0.113.6
ports:
- "8070:8070"
- "8060:8060"
volumes:
- ./data/database:/var/lib/aspia:rw
- ./data/config:/etc/aspia:rw
restart: always
Где вам потребуется указать имя хоста узла Aspia и внешний IP-адрес, по которому вы будете принимать внешние подключения.
Если вы переносите уже существующую инсталляцию сразу разместите в папках конфиги и публичный ключ в ./data/config и базу данных в
./data/database, в противном случае они будут автоматически созданы при первом запуске.Сразу после запуска контейнер готов к работе, хотя вы можете произвести более тонкие настройки через конфигурационные файлы.
Наиболее популярный тюнинг – это изменение диапазона ID клиентов, которые по умолчанию начинаются с единицы. Но это не сложно исправить.
Останавливаем службу:
docker compose down
Устанавливаем sqlite:
apt install -y sqlite3
Подключаемся к базе и правим нужную запись:
sudo sqlite3 ./data/database/router.db3 "INSERT INTO hosts (id, key) VALUES (3000, 0x53544152544b4559);"
В нашем случае мы установили начальное значение 3000. Обратите внимание, что это нужно сделать до того, как вы начали подключать клиентов.
После чего снова запускаем службу, сервер Aspia готов к работе.
👍12❤1
Как создать копию драйверов текущего ПК не прибегая к сторонним инструментам
Задача по сохранению текущего набора драйверов является достаточно актуальной, скажем при переустановке системы, особенно если у вас портативное устройство с многочисленным количеством датчиков и дополнительных устройств.
Для этих задач есть специализированные утилиты, которые можно найти на просторах сети интернет, но не нужно ничего искать, система сама прекрасно справляется с данным вопросом.
Начнем с PowerShell, для выполнения данной задачи выполните с правами Администратора:
Кроме PowerShell вы также можете использовать DISM:
Или pnputil, что актуально для старых систем, начиная с Windows 7:
Все три команды дадут одинаковый результат, все драйвера текущей машины будут скопированы в указанную папку (должна существовать на момент экспорта) с разбитием по подпапкам по числу драйверов.
Далее можете делать с ними все что хотите: использовать как резервную копию, внедрить в образ или выборочно забрать нужные драйвера.
Задача по сохранению текущего набора драйверов является достаточно актуальной, скажем при переустановке системы, особенно если у вас портативное устройство с многочисленным количеством датчиков и дополнительных устройств.
Для этих задач есть специализированные утилиты, которые можно найти на просторах сети интернет, но не нужно ничего искать, система сама прекрасно справляется с данным вопросом.
Начнем с PowerShell, для выполнения данной задачи выполните с правами Администратора:
Export-WindowsDriver —Online —Destination F:\Drivers
Кроме PowerShell вы также можете использовать DISM:
dism /online /export-driver /destination: F:\Drivers
Или pnputil, что актуально для старых систем, начиная с Windows 7:
pnputil.exe /export-driver * F:\Drivers
Все три команды дадут одинаковый результат, все драйвера текущей машины будут скопированы в указанную папку (должна существовать на момент экспорта) с разбитием по подпапкам по числу драйверов.
Далее можете делать с ними все что хотите: использовать как резервную копию, внедрить в образ или выборочно забрать нужные драйвера.
👍34❤5⚡2