Если на сервере стоит только панель (фаерволов нету), оно же не будет работать, нужно сделать чтобы серв этот порт слушал ? По дефолту панель только 443 порт смотрит, не ?
Сделал по вашему гайду предварительно открыв порт, не фурычит
По дефолту панель только 443 порт смотрит, не ?
Я не эксперт в панелях, никогда их не использовал. Вы сейчас говорите про саму панель или про сервер xray или sing-box, которые конфигурируются через эту панель?
Ситуация такая - есть свой vps, на котором установлена только панель.
Смотрел на открытые порты, был открыт только 443, который сама панель открывает по дефолту для своих нужд.
Прочитал ваш гайд о переброске, почекал сайт под который маскируюсь - на нём открыт 80 порт.
Поэтому с помощью iptables настроил сначала открытый порт 80, потом по указанной команде написал прероут. Но порт так и показывался закрытым. На мой вопрос чат жпт ответил что не достаточно просто открыть порт, нужно заставить веб панель его слушать (3x / nhginx/ кади и тд). Поэтому в самой панели в джейсоне указал открытый 80 порт. После этого порт показывался открытым (проверял веб сервисами), но прероут всё так же не работает по какой-то причине. Возможно нужно FORWARD вместо INPUT, прошу прощения я не особо шарю за сети (вообще не шарю)
Уберите prerouting. Если вы повесили панель на 80 порт, то она и так должна быть доступна, т.к. внешний ip находится на вашем сервере.
В xray или sing-box указывайте 443 порт, и домен для маскировки.
iptables вам нужен только для того, чтобы прикрыть лишние доступы, желательно ssh и панель.
Цель этих махинаций - отправлять все запросы по 80 порту на сервер под который маскируюсь, тут нужен прероутинг ?
Подскажите пожалуйста как протестировать что запросы по 80 порту уходят на сервер под который маскируюсь.
Мое мнение, открывать такие же порты как и на подставном сайте, бессмысленная затея. Если например сайт в кластере, и на каждом сервере открыты разные порты, это нормально, и ещё не повод подозревать что за каким-то адресом находится прокси. К тому же, active probing’ом ркн пока не занимается.
Если вам так сильно хочется заморочится, то вашу панель нужно перевесить на другой порт, т.к. 80 вы редиректите. Считайте, что он занят.
Если вы хотите как у оригинала 80 порт, то вам нужен именно HTTP редирект 301/302, а не просто ловля на этом порту или редиректы. То есть вам нужен nginx/haproxy на этом порту.
А так вы только пропалитесь больше, т.к. на 80 порт будет литься шифрованный трафик и нет редиректов, что нетипично для этого порта вообще.
Если не хотите париться - забейте на 80 порт. Он один фиг используется только для редиректа http>https, не более.
Если есть цель сделать хорошую маскировку, то так как раз делать нельзя. Потому что если вы поставите nginx/haproxy на этом порту который будет отдавать 301/302, то его поведение весьма вероятно будет отличаться от 80 порта оригинала (разные версии веб-сервера, разные заголовки, и т.д.).
Выше предложили единственный правильный вариант - просто переадресовывать все входящие соединения с порта 80 прокси-сервера на порт 80 оригинала с помощью правила фаервола. И никаких nginx/haproxy не нужно.
То есть у провайдера есть мощностя, чтобы сдетектировать кейс с http редиректом, сравнив заголовки и, в целом, ответ с оригиналом по всем портам (зная\понимая оригинал, sic!)
… но нет мощностя для того, чтобы не спалить редирект на сетевом уровне, абсолютно втупую сравнив параметры отрезолвенного sni (IP, подсеть, страна, провайдер)?
К тому же, мы вот вспомнили в http редиректе о заголовках. А тут почему-то вдруг забыли про существование хост заголовка, который нас и пропалит… И, тадам, это как раз можно решить именно с реверс-прокси. Он позволит нам сделать абсолютно прозрачный редирект для стороннего наблюдателя ( в том числе, полностью копируя заголовки ), в отличии от редиректа по tcp на iptables.
Пысы. Давайте вернемся в реальность, если актив пробинг с подобным поведением это пока лишь теория (больно требовательно по ресурсам для пров-ра), то вот за сравнением IP назначения с резолвом sni провайдеры уже были замечены, да и это проще по ресурсам, с широкими возможностями оптимизации такого метода пробинга.
… Так что, на мой взгляд, вообще нет смысла заморачиваться с такой маскировой, если делаем для себя\узкого круга людей.
Так это делается элементарно и с минимумом ресурсов - достаточно вычислить и запомнить хэш значений из Location, Server и еще пары заголовков.
Так поэтому уже не первый год говорят про золотое правило Reality-маскировки - маскироваться под балансер CDN из той же подсети того же хостера, а не под какой-нибудь там Гугл.
В одном правиле фаервола «заморочек» гораздо меньше, чем в установке и конфигурировании реверс-прокси.
А так, много лет борьбы с блокировками (еще даже не в России) научили простым правилам: 1. никогда не недооценивай соперника 2. никогда не надейся на авось 3. готовься к худшему сильно заранее 4. то, что все думают «да это маловероятно, наврядли оно случится» обычно случается а первую очередь.
Как именно? Давайте подробно опишите вектор детектирования (речь, я так понимаю о том, что домен в поле host в голом http и в sni для tls будет резолвиться в другой адрес отличный от адреса сервера?) как вы его представляете и как в этом случае реверс-прокси выступит волшебной пилюлей, а потом вместе проанализируем так оно или не так.