Комментарии 14
3X-UI проще в настройке, я использую haproxy как для reality так и для xhttp, перешёл с портов на сокеты, и ушёл от докера ставлю 3x ui на железо, не от рута. Инсталляция не самая простая за счёт выставления прав доступа и тд. В докере только adguardhome для doh.
А как adguard с 3xui скрестить? Или это просто сервис не для клиентов прокси?
Через обратный прокси, у меня есть статья. Добавляете перед dns-query строку, получаете путь ввиде example.com/mydnspath/dns-query, в при передачи его на бекенд adguardhome стираете путь. Об этом я напишу, как установить 3xui не от рут, как разрешить работу с сокетами получение сертификатов и тд, в одной большой статье.
Разраб XTLS прямо на гитхабе не рекомендует пользоваться 3X-UI, так как подозревает их в сотрудничестве с иранскими службами.
К сожалению, его мнение мало чего стоит. Я в данном случае поддерживаю разработчиков панелек, так как разраб XTLS предлагал ставить свой самоподписанный сертификат в панельки - и мало ли чего он хотел добиться своими целями. Очень похоже на работу спецслужб. Так как после такого PR'а alireza0 просто решил заархивировать XRay и перешёл на Sing-Box. Чего и всем советую!
Его мнение не играет никакой роли. Я вижу факт. За прямым и простым вопросом, почему при установке 3X-UI панели по умолчанию идет голый http, следует невнятный бред про свободу выбора, хотя для таких вещей TLS должен быть включен принудительно.
Про сертификат не очень понял. Он хочет свой собственный ставить? Есть пруфы, хочу ознакомиться?
А можете подробнее пояснить про подписки (subscriptions), видел эту настройку много раз но так и не понял как ей пользоваться. При обновлении настроек на сервере - все клиенты отваливались.
И да, для iOS я использую клиент Streisand, бесплатный, удобен тем что есть виджет, чтобы включать/выключать впн в один клик по рабочему столу.
Виджет не обязателен, с этим отлично справляются «команды»
Это просто URL, с которого клиент построчно забирает конфиги для настройки. Если меняются настройки сервера, то должно меняться и содержимое файла. Вот так выглядит мой, за вычетом ключей:
vless://<URL>?security=reality&encryption=none&pbk=<pubkey>&headerType=none&fp=chrome&type=tcp&flow=xtls-rprx-vision&sni=example.com&sid=aabbccdd#Name_for_client
ss://<base64config>#Name_for_client
Я правильно понимаю, если этот урл где-то засветится, то всякие составители черных списков впн смогут однозначно забанить мой сервер? Так же если этот урл станет доступен широким массам, то моим впн все смогут бесплатно пользоваться?
Да, так и есть. Как и с любым другим утекшим конфигом. На самом деле пользователю ничего не мешает сдампить настройки с клиента и точно так же слить их в сеть.
Я, когда делал конфиг для nginx, советовался с коллегами, и если на этот URL не ведут ссылки, то пауки не смогут до него добраться. А рандомность адреса спасет от подборщиков. Так что в теории все более-менее секьюрно.
Насчет блокировки сложно сказать. На нашу улицу явно приходит некоторая оттепель, так уж жестить, что по слитым конфигам вручную банить, мне кажется, уже не будут. В худшем случае подрежут SS в период обострений.
Вообще, были бы деньги, я бы по другому сделал. Поднял сервак здесь, в России и раскидал всем VPN, по типу wireguard. А уже оттуда проксировал дальше. В таком виде и юзер менеджмент был бы проще, и всякие 2FA можно прикрутить. Заодно спрятать истинного виновника торжества от глаз пользователей.
Ого, у нас тут настройка внеочередная? Ну, давайте изучать.
Автор с самого начала признает, что готов положить на безопасность сервера поставив на него SS2022 на порт отдельный. Т.е. мы буквально убиваем весь смысл создания реалити, ведь теперь у нас торчит протокол, который уязвим к Active probing, а также TLS-in-TLS(в один день выстрелит по всем). Про проблемы с Discord и VLESS впервые слышу, так как сам сижу и все работает.
Docker это круто, когда понимаешь зачем. В нашем случае масштабирование так не работает, так как мы не ставим панель, которая позволяет синхронизировать юзеров и имеет отдельную систему подписки. Я сам ставлю голое ядро в Docker, но не оправдывайте это масштабированием, у вас ничего такого нет.
Зачем перед Nginx ставить Traefik, когда можно поставить один Angie или Caddy и достаточно иметь один веб-сервер, который сам получит серты? И даже без домена своего вполне реально оставить подписку, так как утечка ссылки VLESS-Reality не приводит к тому, что трафик сервера можно дешифровать. Это вам не VMess.
Выбор доменных регистраторов ОЧЕНЬ интересный, хостеров тоже.
Создание отдельного пользователя, чтобы понизить права - круто. Давать ему возможность использовать sudo без пароля - не очень круто.
Так как немалая доля хостеров используют cloud-init, то стоит смотреть не только sshd_config, но и файлы дальше, для этого можно делать так:
grep -r PasswordAuthentication /etc/ssh -l | xargs -n 1 sed -i -e "/PasswordAuthentication /c\PasswordAuthentication no"
grep -r PermitRootLogin /etc/ssh -l | xargs -n 1 sed -i -e "/PermitRootLogin /c\PermitRootLogin no"Вопрос еще к самой "системе подписок". Просто здесь это не более чем ссылки с конфигом, это просто бесполезно и не дает ничего для масштабирования. Вы бы могли хотя бы доработать Nginx и добавить там настоящую систему подписок.
Также система подписок описывается как "упрощение для друга", но по факту друг встречается с NEKOBOX, который не то что не поддерживается, он ничего полезного в последней версии 4.0.1 не ввел. Представьте лицо друга, который должен сделать все то, что вы описали? Вот, кстати, от меня упрощение. Айпи дискорда для войса нет у вас в списке и, вроде как, в антизапрете тоже их нет, поэтому и не работало, надо руками добавлять.
Короче, гайд хз для кого.
Отвечу, с Вашего позволения, с конца.
Гайд хз для кого, потому что это не гайд. Я решил написать статью, потому что кто-то в комментах интересовался настройкой ОС в контексте ssh ключей и доп.безопасности. Ну и реализацией своей поделиться. Блог таки.
Друг получит от меня готовый архив с настроенной прогой и инструкцией на три строчки "что делать если поломалось". А он взамен угостит меня пивом в баре. На то он и друг, в общем то. Дальше я эту систему не развивал, ибо работает.
Если это не масштабирование, то хочу узнать, что есть тогда. Больше серверов, меньше серверов, новые настройки и т.д - все это я могу динамически держать в файле без всякой необходимости как то взаимодействовать с конечными пользователями. Я не дока Nginx, мне не нужно было с ним работать, поэтому чему научился, то и получилось.
Выбор реально не очень, грешен.
Я единоличный владелец и пользователь сервера, рут, не рут - мне нет никакого дела. Но я использую единый скрипт настройки ОС под конкретно мои SSH ключи и иметь для этого отдельного пользователя необходимо. Остальное это банальное удобство. За наводку на cloud-init благодарю, не знал как нему подобраться. Возьму на вооружение.
Я не умею в Angie или Caddy, к сожалению. Но немного умею в Traefik, поэтому решил не изобретать велосипед и просто подрезал с моего рабочего проекта.
Речь шла не о масштабировании через Docker, а через подписки. Кстати не вижу проблем применить и на нем. Я пробовал сделать что-то кластероподобное через Swarm, но с ним много проблем надо походу решать. Мои юзеры все свои, родные, разграничивать ничего не надо. У меня как-то раз упал один сервак, надолго, так я просто выкинул его из подписки вручную. Один рефреш на клиенте и летим дальше. А Docker взял просто потому что захотел, надеюсь это достаточный аргумент.
Да, я готов положить на безопасность сервера и вот почему: Во-первых, я не видел пока, что банят серваки с торчащим SS. Режут на ТСПУ, это могут. Для этого у меня есть VLESS. Во-вторых, поднять и настроить новый сервак занимает 15 минут (засекал пока писал статью). В-третьих, я бедный, у меня нет денег держать парк виртуалок под каждый чих.
А вообще спасибо за толковый коммент
XTLS Reality Steal + Shadowsocks2022. Настройка Ubuntu, Docker и масштабирование с помощью Subcriptions