Поиск

Всем привет Давно напрашивается тема по искусству ФэнШуя для использования и реализации МэрцБана. 1. Начнем с того, что ВАМ нужно понять "Чего вы хотите от панели Marzban?" Варианты: Для себя и друзей (до 20-25 человек) Только для себя (1-5 человек) Для пассивного дохода + "сарафан-радио" со стабильным и надежным доступом (до 100 человек с перспективой роста) Аггрессивный лоу-прайс сервис VPN с рекламой по всем щелям и ботом для продажи (500+ человек за год) СуперКрутой VPN сервис с премиальными скоростями. Любые другие вариации и комбинации.. Начнем с конца. СуперКрутойVPN сервис И это точно не Marzban. Для СуперКрутогоVPN сервиса, вам Marzban не нужен. Вам нужны деньги и Dedicated сервер с гарантированным каналом. Вам нужна своя разработка софта (программ для каждой платформы), бота по продаже, и в идеале адаптированный под себя протокол (например обфусцированный мусорными пакетами WG). Аггрессивный лоу-прайс сервис VPN Этот вариант для Marzban + SHM. Я про него не писал еще, но о нем можно много говорить. Это готовый билинг с поддержкой ТГ-бота, который может просто подключаться к Marzban и заниматься пассивными продажами вашего VPN. Под тему SHM с очень детальными инструкциями планировался отдельный, закрытый (платный) клуб, но человек который планировал это писать и вести клуб (это не Я) - сейчас перегружен.. Надеюсь он доберется до нас Для себя и друзей и для пассивного дохода около 100+ человек - мы объединим, и рассмотрим их в этой мини статье. Это наш вариант на Marzban. Конечно, не исключено также применение SHM, или написание своего бота-продажника, но тем не менее, это отдельный разговор. Только для себя Вам не нужен Marzban. Проще обойтись установкой чего то простого: Amnezia VPN или vpnbot (телеграм решение, удобное для соло-использования где можно настроить разные типы подключений) 2. Выбор варианта реализации. Под выбором реализации, я понимаю проработку архитектуры решения в техническом плане. Варианты: 1 сервер Мэйн (подключение на Мэйн) 1 сервер Мэйн + Ноды (подкдючение на Мэйн и Ноды) количество нод не важно 1 сервер Мэйн + Ноды (подключение только на Ноды) количество нод не важно 1 сервер Мэйн + Ноды + сервер под страницу подписки (подключение на Мэйн и Ноды) Несколько Мэйн серверов + несколько Нод (с подключением на каждый Мэйн) 2.1. Приоритетным решением для организации доступа малого круга лиц (которых вы потенциально знаете - что исключает варианты саботажа среди клиентов), можно ограничиться 1 мэйн сервером и 1-2 водой Нода будет выполнять функцию резервного сервера для подключений. Мэйн будет также доступен для подключения. Это самый просто и очевидный вариант. Здесь вам не требуется много ресурсов ни в скорости доступа, ни в производительности. Минимальные тарифы на 4vps (как вариант) легко потянут эту реализацию. 2.2 При выборе для размещения небольшого VPN проекта 100+ человек, лучше рассмотреть вариант: сервер Мэйн + Ноды (подключение только на Ноды) Почему именно так? Мэйн сервер будет спрятан за CDN CloudFlare Подписка будет спрятана за CDN CloudFlare Люди будут подключаться только на ноды. 3. Требования к серверам. 3.1. Как я уже написал выше, для малого количества людей, супер производительные сервера и широкие каналы связи - не нужны, они излишни. Для круга лиц 20 человек, хватит конфигурации: 1 ядро (3.3 GHz) 2GB RAM 20 GB NVMe 2Gbit/s Но 20-30 активных пользователей потребуют чуть лучшей: 2 ядра (3.3 GHz) 4GB RAM 25 GB NVMe 2Gbit/s Это связано с тем, что загружая свою сеть, вы автоматически загружаете процессор. И в пике загрузке сети, у вас процессор загрузится на 100% на 1 ядре, и связь пропадет. К нодам, требования могут чуть ниже (на позицию) либо равноценны. И зависит это снова от того сколько людей активных ими будут пользоваться. По опыту могу сказать, что почти все используют 1й в списке сервер (80% людей) 3.2. Для реализации варианта сервер Мэйн + Ноды (подключение только на Ноды) нам потребуется несколько другая конфигурация. Требования к мэйну: Надежный провайдер. Под надежностью я понимаю максимальный SLA (доступность). Так как этот сервер будет отвечать за все подключения и будет хранить нашу базу данных. Провайдер может быть российским (может быть даже сервером на VK или Yandex Cloud Почему так? Просто потому что по сути, о нем никто не узнает. Адрес будет скрыт за CDN Cloudflare и останется анонимным. Заблокировать или проследить что мэйн у вас работает на РУ сервере - крайне сложно (в этом и смысл существования CDN) Высокая доступность сетевая - сервер должен уверено и быстро подключаться ко всем вашим нодам Сервер должен быть максимально защищен от ДДОС атак. Еще один плюс в пользу надежных провайдеров. Желательно hiCPU реализация сервера. Да, это может показаться излишним, но иногда 0.5 секунды решают многое. На HiCPU серверах обычно значительно лучше диски (1гб/с+ скорость у них) У них выше частота процессора, а значит все операции I/O будут выполняться стабильнее и быстрее. Требования к Нодам: Высокая скорость доступа (от 1гб/с), а лучше 5-10Гб/с Надежный провайдер Диверсификация серверов Это когда все Ноды (2-3) взяты у разных провайдеров. Это важно для обеспечения стабильности работы вашего сервиса, если на одного провайдера будет проходить ДДОС атака, вы пользователей попросите перключиться на другие сервера) Сервера в разных странах. Это тоже диверсификация, но здесь именно решается вопрос доступности контента (это во-первых) А во-вторых решается доступность и скорость работы пользователей из разных регионов Мира или России. Первый сервер в списке - должен быть достаточно мощным (2+ ядра / 4гб+ оперативы) У серверов должна быть хорошая связангость по регионам 4. Требования к протоколам и настройкам ядра. Здесь много расписывать нечего. Самым стабильным и неприметным остается VLESS+REALITY+Xtls-rprx-vision (другие добавлять даже не вижу смысла) Для реалити SNI-сервер следует выбирать искать в подсети провайдера, либо выбирать менее блокируемые, универсальным является Дискорд. (будет отдельная статья как подобрать) Каждая нода должна быть отдельным inbound-ом Все подключения должны быть через 443 порт (либо его производные 8443/2443/3443 и т.д.) - Задача этого порта - не привлекать внимание, когда вы по нему будете обращаться и маскировать. Желательно использовать haProxy - чтобы подключать все на 443 порт если у вас несколько типов подключений/инбаундов. (статьи по haProxy пока нет, но надеюсь напишу как появится время) Если все работает - не лезь Стабильно обновляй панель, ноды и ядро. Пока на этом все. Продолжение следует. Если вы с чем то не согласны, можете отобразить и обосновать в комментариях. Я расписал свою позицию и свой опыт. Если вам понравилась статья, и хотите услышать продолжение, то напишите в комментариях, о чем рассказать еще по понятию "ФэнШуя".

Всем привет Давно просят, пишу. 0. Возможная потребность Почему это может пригодится? ДДОС основного сервера и его недоступность Реинжиниринг серверов (это когда вы решаете поменять логику работы и размещения) Переезд на другой сервер (в добровольном порядке) Проблемы на основном сервере - требуется переустановка ОС 1. Условия Главным условиям такого переезда, наличие Дампа файлов. Хорошим инструментом для этого является бот автобэкапа в телеграм. Инструкцию я уже публиковал на эту тему. Бот присылает архив из двух основных папок с сохранением директорий: /opt/marzban и /var/lib/marzban/ /opt/marzban содержит в себе условия запуска Marzban. /var/lib/marzban/ содержит в себе все дополнительно используемые вами файлы. Поэтому есть смысл хранить все именно там. Если у вас старый сервер доступен, то лучше будет скопировать все данные непосредственно с него. (этот вариант мы и будем рассматривать) 2. Порядок переезда. 2.1. Сперва нам нужно взять в аренду новый сервер. 2.2. Обновляем все репозитории: apt update && apt upgrade -yqq 2.3. Устанавливаем Marzban официальным скриптом sudo bash -c "$(curl -sL https://github.com/Gozargah/Marzban-scripts/raw/master/marzban.sh)" @ install А теперь внимание. Версии Marzban должны совпадать с тем сервером с которого вы переезжали. Если вы стабильно обновляете dev ветку, то и на новом сервере должна быть установлена именно она, чтобы не вызвать конфликты с БД. Если вы использовали все время DEV ветку, то делаем следующее. Меняем наш docker-compose.yml nano /opt/marzban/docker-compose.yml Параметр: image: gozargah/marzban:latest на image: gozargah/marzban:dev А затем запускаем обновление: marzban update 2.4. Остановка Marzban на новом сервере. marzban down 2.5. Привязка домена и получение сертификатов. Аналогично прошлой инструкции получаем сертификаты уже на новом сервере (но на старый домен) Перед выпуском сертификатов ОБЯЗАТЕЛЬНО ПРОПИШИТЕ НОВЫЙ IP АДРЕС НОВОГО СЕРВЕРА ВАШЕГО ДОМЕНА/ПОДДОМЕНА на котором запускался Marzban! Пункты 3 и 4 из инструкции: https://openode.xyz/topic/668-ustanovka-marzban-chast-1-obschaya-ustanovka/ На этом подготовка нового сервера завершена. 3. Остановка Marzban на старом сервере. Тормозим наш Marzban командой: marzban down 4. Копируем файлы со старого сервера, на новый с ЗАМЕНОЙ. Как я уже не раз советовал в телеграм, я использую для работы с серверами Termius. И там встроен SFTP клиент. Открываем два сервера на двух разных вкладках И переносим данные с сервера на сервер: (слева старый сервер, справа новый) в папке VAR/LIB/MARZBAN мы НЕ ПЕРЕНОСИМ только папку certs, так как мы уже выпустили новые! 5. Запуск Marzban на новом сервере. marzban up На этом все. Проверяйте ваш доступ. Все должно работать. Клиенты, ноды и все остальное уже должно работать. Не забывайте обеспечить прежние условия безопасности и скопировать параметры UFW в том числе. БОНУС. Скрипт для копирования конфигурации UFW. Выполнять на старом сервере. bash <(wget -qO- dignezzz.github.io/server/ufw-copy.sh) Вывод будет иметь формат: Эту команду можно будет просто выполнить на новом сервере, при условии что будет уже установлен ufw. В случае восстановления из бэкапа телеграм, шаги идентичны. Просто файлы вы копируете не со старого сервера, а из своего архива (игнорируя папку certs)