Появилась идея маскироваться под собственный сайт, но для этого хотелось бы понять, имеет ли значение контент этого самого сайта и насколько велика вероятность, что цензор пойдет напрямую его проверять.
Условно говоря, будет ли практическая разница между маскировкой под пустую страницу и полноценно оформленный сайт? Или можно ли, например, всем, кто пытается открыть сайт просто выдавать 401/403?
В доках по Xray приводят пример с закосом под блог-галерею. Может для Китая это актуально. У нас вроде как пока нет практики active probing, но всё может быть.
Мне кажется вообще без разницы какой должен быть контент на маскировочном сайте. Ну допустим выдаешь 403. Откуда цензорам знать, что там? Может у тебя своя логика авторизации, а цензоры вряд ли могут прочитать Authorization хедер допустим. Ну в качестве перестраховки можно сделать непалевный домен типа “mysmarthome.example.com”, и заглушку что доступ запрещен. Имхо.
Дополнительно советуют сайт держать только на http2, и tls 1.3.
Спасибо за ответ. В таком случае просто ограничусь сайтом-заглушкой без лишних ухищрений.
Поставь вместо сайта auth-basic, пусть пароль просит)
Кстати когда маскируются под левые сайты, советуют же выбирать сайты без форм авторизации? А если свой сайт, и если это auth basic?
Что может не понравиться експертам ркн вам никто не скажет. Сайт есть? Есть. Вернёт он там роботу authorization request ну и чтож теперь? Банить его сразу?
Ну поставьте там рилм разумный, типа “My minio” ))
< HTTP/2 401
< server: nginx/1.24.0 (Ubuntu)
< date: Sat, 02 Nov 2024 10:37:34 GMT
< content-type: text/html
< content-length: 188
< www-authenticate: Basic realm="Resilio Sync"
<
<html>
<head><title>401 Authorization Required</title></head>
<body>
<center><h1>401 Authorization Required</h1></center>
В таком случае для беспалевности нужно выбирать контент который соотвествует частоте запросов ведь провайдер будет видеть в логах что юзер каждый день по сотне раз посещает один и тот же сайт. И если там висит basic auth то это вызовет сомнения. Какой нибудь блог типа кулинарии, новости шоу биза, it новости, speedtest, блог об автомобилях и т.д. вызовет меньше сомнений.
А может там идёт постоянный обмен файлами. Плюс айпишник один и тот же, т.е блог на одного человека получается, что тоже странно
Если это своя файлопомойка с синхронизацией типа Seafile, например, какие к ней претензии? )
Или галерея типа photoprism, immich? Да мало ли зачем я туда лазаю
Из тех случаев, когда я сталкивался с банами, привлекают внимание большой трафик, много сессий, использование udp (тёмные носки), нетиповые порты а-ля прокси: 80xx и т.п. Но точно критериев никто не знает и не узнает. А может они меняются даже
Ну сделайте порт 10050, включите UoT, раз там постоянный трафик. Пусть это будет zabbix-agent )
Ещё, как вариант, можно сделать простую переадресацию на сайт под который маскируешься, тогда и с контентом не надо париться 
Какой-нибудь NextCloud хорошо подойдёт, он тяжелый в том числе и по функционалу но и большой трафик на него не будет выглядеть подозрительно как по мне.
Попробовал поставить Seafile. Помимо танцев с бубном вокруг протухших официальных гайдов по установке с версиями библитек Питона, вышедших при царе Горохе, выяснилось, что он достаточно тяжеловесен для VPS тарифов “Мне самый простой”: 1GB RAM / 10GB SSD в моем случае. На пустую Ubuntu через docker еле влазит, установка то и дело ругается на исчерпание диска. Как-то запихал его, чистя все после каждой команды. Но он страничку с паролем через ВПНы грузит секунд 15-30. Напрямую нормально. 1/10 это его минимальные требования. Короче, как эмуляция сайта для домашнего прокси - так себе вариант. Что-то полегче надо.
Ставить целый некстклауд или seafile ради маскировки - безумие какое-то. Просто возьмите отдельно его страничку авторизации в виде html, и в нжиксе ее поднимите, как статичный сайт.
Посмотрите из этого GitHub - awesome-selfhosted/awesome-selfhosted: A list of Free Software network services and web applications which can be hosted on your own servers
Я как-то filegator юзал. Выглядит не плохо.
А не подскажет кто, как это технически правильно огранизауется? У меня щас 3X-UI панель, настроена, все работает. Поставил сервер на Nginx, прикрутил домен, получил TLS сертификат Let’s Encypt. На сервере flat-file мини-блог развернул Grav (всего 18МБ). А как их увязать друг с другом?
Тут пишут.
Чтобы добавить прокси, вам надо перевесить веб‑сервер на какой‑нибудь другой порт, например 8443, и сделать так, чтобы он слушал не на всех IP‑адресах (0.0.0.0), а только на localhost (127.0.0.1).
Я попробовал так. Открыл порт 8443. В конфиге сайта на Nginx, который в его папке sites-available, прописал listen 127.0.0.1:8443; И в Inbound соединении Xray панели Dest (Target) тоже выставил 127.0.0.1:8443. Не работает, кофнликтуют. То Xray ругается, что не может слушать 443, то Nginx отказывается рестартовать, если в панели соединение поднято. Что я делаю неправильно?
У вас скорее всего в /etc/nginx/sites-enabled есть default, в котором есть приветственная страница, которая на 443 порту висит. Удалите default. А так вы правильно сделали всё. В вашем сайте в nginx listen 127.0.0.1:8000 ssl; и путь к сертификатам от lets encrypt, в xray listen - на публичном адресе с 443 портом, dest на 127.0.0.1:8000. Уточните правильно ли у вас адрес в DNS. Советую ещё посмотреть нету ли в процессах какого-нибудь заплутавшего nginxa или xray.
lrlunin - спасибо! Завелаcь шарманка! У меня в Nginx конфиге было
listen 127.0.0.1:8443;
а надо именно
listen 127.0.0.1:8443 ssl;
Еще вопрос. У меня в Nginx конфиге была в разделе про сертификаты прослушка 443, это для Certbot’а какое-то окно, я так понимаю. Я, разумеется закомментил 443, иначе ничего не работает. Но оставил 80. Я правильно понимаю, что это как бы резервный канал и сертификат таки будет обновляться?
# listen 443 ssl; # managed by Certbot
listen 80;
Еще одно интересное решение подсмотрел у этого китайца.
В конфиге Nginx сервера слушаем такое.
listen unix:/dev/shm/nginx.sock ssl;
В Dest (Target) 3X-UI панели прописываем:
/dev/shm/nginx.sock
На первый взгяд какая-то эзотерическая линуксятина, но почитал, все довольно просто. /dev/shm/ это Shadow Memory, типа виртуального диска в оперативной памяти. А юникс-сокеты это интерфейс обмена данными между процессами в ОС. Для домашнего прокси пофиг, можно и через прослушку портов организовать, разницы не заметите, но для крупных коммерческих ВПН с сотнями и тысячами пользователей будет выигрыш в скорости и снизиться нагрузка на сервер, посколько Nginх и Xray так быстрее общаются. И меньше путаницы в портах.