ноября мир изменился и больше никогда не будет таким же как прежде. В российском интернете появилась цензура — общеизвестный уже список запрещенных сайтов. Для одних это важнейшая политическая тема, для других повод изучить технологии шифрования и защиты анонимности, для третьих просто очередной странный закон, который приходится исполнять на бегу. Мы же поговорим о технологическом аспекте. 
Удивительно, но поиск на Хабре по запросу OpenLiteSpeed не даёт ничего! Спешу исправить эту несправедливость, ведь LSWS – достойный веб-сервер. Я люблю его за скорость и модный веб-интерфейс администрирования:
Несмотря на то, что OpenLiteSpeed наиболее знаменит как «ускоритель» вордпреса, в сегодняшней статье я покажу довольно специфичное его применение. А именно обратное проксирование запросов (reverse proxy). Вы скажете, что для этого привычнее использовать nginx? Я соглашусь. Но больно уж нам полюбился LSWS!
Проксирование ок, но куда? В не менее замечательный сервис – Nextcloud. Мы используем Nextcloud для создания частных «файлообменных облаков». Для каждого клиента мы выделяем отдельную VM с Nextcloud, и не хотим выставлять их «наружу». Вместо этого мы проксируем запросы через общий reverse proxy. Это решение позволяет:
Схема выглядит так:
Понятно, что схема упрощена, т.к. организация инфраструктуры веб-сервисов – не тема сегодняшней статьи.
Также в данной статье я опущу установку и базовую настройку некстклауда, тем более что на Хабре есть посвящённые этой теме материалы. Но обязательно покажу настройки, без которых Nextcloud не будет работать за прокси.
Так уж случилось, что нужно мне было где-то хранить более 1.5тб данных, да еще и обеспечить возможность скачивания их обычными пользователями по прямой ссылке. Поскольку традиционно такие объемы памяти идут уже на VDS, стоимость аренды которых не слишком вкладывается в бюджет проекта из категории «от нечего делать», а из исходных данных у меня был VPS 400GB SSD, куда при всем желании 1.5тб картинок без lossless сжатия поместить не удастся.
За первые два квартала 2020 года количество DDoS-атак выросло почти в три раза, при этом 65% из них приходится на примитивные попытки «нагрузочного тестирования», которые без труда «отключают» беззащитные сайты небольших интернет-магазинов, форумов, блогов, СМИ.
Как выбрать защищенный от DDoS-атак хостинг? На что обратить внимание и к чему подготовиться, чтобы не оказаться в неприятном положении?
(Прививка от «серого» маркетинга внутри)
Zimbra Proxy - очень важный элемент Zimbra OSE, который выполняет целый ряд функций, связанных с безопасностью и быстродействием почтовой инфраструктуры. Именно на узле Zimbra Proxy происходит централизованная аутентификация пользователей и их перенаправление на соответствующий почтовый сервер, а также централизованный сбор логов. Кроме того, Zimbra Proxy выполняет функции балансировщика нагрузки и обратного прокси - скрывает от пользователей топологию и характеристики узлов инфраструктуры Zimbra OSE, что затрудняет проведение разного рода кибератак. Также на узле Zimbra Proxy происходит терминация SSL-соединения, что снижает нагрузку на остальные серверы инфраструктуры Zimbra OSE, и кэширование. Но главная ценность Zimbra Proxy заключается в том, что этот узел позволяет обеспечивать централизованный доступ к другим узлам инфраструктуры Zimbra OSE.
На самом сервере Zimbra Proxy устанавливаются такие компоненты как Nginx и memcached. Также на почтовых серверах Zimbra OSE устанавливаются обработчики маршрутизации запросов, который позволяет Zimbra Proxy корректно находить почтовый сервер при подключении пользователя. Всё это нужно для обеспечения централизованного доступа пользователей к серверам Zimbra OSE. Суть его заключается в том, что при подключении пользователя к узлу Zimbra Proxy он самостоятельно определяет, к какому почтовому серверу относится его учетная запись и перенаправляет подключение на нужный почтовый сервер, чтобы пользователь в итоге попал в свой почтовый ящик. То, что со стороны пользователя работает как магия, на самом деле является довольно сложным механизмом со множеством различных нюансов. О них мы расскажем в данной статье.
Создание общедоступного URL в сети интернет к вашему локальному проекту
Что такое Ngrok, наверное знает каждый разработчик web приложений, и многие им пользуются.
Немного предыстории...
Присоединившись к новому большому проекту, над которым работают десятки разработчиков и QA специалистов, я столкнулся с тем, что разработка ведется удаленно на специально выделенных серверах.
А т.к. я уже несколько лет разработку приложений веду исключительно в докере, я никак не мог адаптироваться к текущему подходу.
Думаю все, кто более менее освоил работу в докере, уже не мыслят как можно разрабатывать без него. Причин на это много. Конечно, как и везде у докера есть своя цена и это тоже уже много раз обсуждалось.
Итак, новый проект не похож на предыдущие. Он имеет много зависимостей с другими сервисами, как внутренними так и внешними.
Большое количество внешних интерграций порождало проблему связи локального приложения с внешним миром. И если объединить внутренние сервисы используя docker netwokr не вызывало каких либо проблем, то необходимость связать внешний сервис уже требовал дополнительных инструментов.
Интеграции платежных систем всегда подразумевает, что будут callback (notification).
При такой необходимости, часто выбирают Ngrok. Хорошее решение, но в удобном варианте - платное. Особенно это ощущается, когда разработчиков много.
Т.к. Ngrok не подходил, первое что пришло в голову, создать виртуалку, на нее завести домен, и создавать ssh туннель с ним.
В статье будет затронут способ с применением ревёрсинга траффика Android-устройства для обнаружения endpoints, по которым можно взять то, что лежит в более приятной форме, нежели получаемое через парсинг HTML-дерева.