Comments 126
Заблочить можно любой IP. Но трафик на сервер внутри страны привлекает меньше внимания, чем прямой канал за границу. А главное, если заблокируют конечный сервер, я чиню это за минуту, не трогая конфиги на телефоне и компе. Цепочка нужна для отказоустойчивости, а не для бессмертия IP.
Так же встречаются еще и комментарии, да у меня работает Амнезия WG - рад, но не далеко не во всех регионах а существенная часть регионов имеет проблемы с доступностью многих протоколов.
Зачем именно вы считаете небходимым промежуточный сервер при использовании vless?
Заблочить можно любой IP. Но трафик на сервер внутри страны привлекает меньше внимания, чем прямой канал за границу. А главное, если заблокируют конечный сервер, я чиню это за минуту, не трогая конфиги на телефоне и компе. Цепочка нужна для отказоустойчивости, а не для бессмертия IP.
Так же встречаются еще и комментарии, да у меня работает Амнезия WG - рад, но не далеко не во всех регионах а существенная часть регионов имеет проблемы с доступностью многих протоколов.
трафик на сервер внутри страны привлекает меньше внимания, чем прямой канал за границу
Но Вы-то как раз и выбрали прямой канал за границу... Вы реально думаете, что РКН делает различия между серверами в "нейтральных" и "недружественных" странах?
Короткий ответ - да, делает. Один и тот же впн-протокол напрямую в Нидерланды не работает, а через Казахстан - работает.
Думаю, это не более чем совпадение.
Во-первых, в этом нет никакой логики, т.к. сервера в "нейтральных" государствах точно так же позволяют обойти блокировки РФ, а борется РКН именно с этим.
Во-вторых, мой собственный опыт постоянно работающих VPN-туннелей (WG и Amnezia-WG) внутри РФ, из РФ в Нидерланды, Швецию и Турцию показывает, что WG внутри РФ блокируется очень эпизодически, а вот трансграничные VPN - довольно часто, но совершенно рандомно. От одного провайдера к одному и тому же зарубежному серверу блок, от другого в то же самое время всё работает отлично, а на следующий день и первый оживает как ни в чём не бывало. Каких-то преимуществ у "нейтральной" Турции при этом я не заметил.
Ну и, кстати, мне кажется мифом существование каких-то вечных чёрных списков IP, попавшихся на использовании VPN. Ровно по той причине, что третий год с полдюжины российских статических IP совершенно в открытую устанавливаю WG-соединения с зарубежными серверами, в случае неудачи откатываюсь на AWG или обходной маршрут (OSPF в mesh-сети из VPN-туннелей "все со всеми" рулит) - и всё продолжает работать (или не работать) совершенно рандомно, как написал выше.
вечных чёрных списков IP
Список точно есть, но не вечный. У меня полностью блокировали IPsec, при этом при выдаче провайдером другого IP, он без проблем работал. Первый IP начал работать только после письма в РКН.
Описываемую здесь схему из двух серверов использую с апреля 22-го года. Я тоже буду утверждать, что у РКН гибкие инструменты в блокировке трафика и не всегда логично объяснимые. Различное поведение ТСПУ в отношении трафика домашних провайдеров и хостингов наблюдал не единожды.
Один из примеров. Две VPS одного хостинга. Протокол "от клиента к серверу" -- wireguard, протокол "между серверами" -- wireguard. В один момент трафик между серверами "заглох", а в качестве решения внезапно выручил ipip совсем без шифрования.
Полагаю дело не в протоколах, а в том, что голландский адрес попал под блокировку, а казахстанский (пока?) нет.
Да, я про это и говорю - сообщений, что европейских хостеров банят просто по диапазонам адресов, довольно много.
Это уже моё предположение - но кажется, что к казахстанскому трафику применяются другие правила в том числе потому, что, например, из КЗ в Европу трафик чаще всего едет транзитом через РФ - и если начать его фильтровать, то отвалится много чего, вообще к рунету отношения не имеющего :)
Дело не в странах. Сейчас временно блокируют по IP если на хост идёт поток UDP пакетов. В диапазонах блокировки все основные хостинги и даже часть амазона.
Из Казахстана РКН блокирует. На практике, 2 сети /29 заблокировал. Сначало были блокировки отдельных ip, туннелей vpn, потом вся сеть в блок уходит. Может от количества траффика ещё зависит.
Подтверждаю, делает: с мобильного и домашнего интернета некоторые из моих VLESS-серверов регулярно недоступны без какого-либо заметного паттерна, почему. Через прокладку из VLESS-сервера в РФ с outbounds туда же - все работает.
Возможность войти в Интернет не Ваша заслуга, а их недоработка.
По статье... Первое, что пришло мне в голову это дальнейшая эволюция, когда внутри периметра несколько серверов на которые летят предварительно зашифрованные пакеты с таким расчётом, что расшифровка ни на одном сервере не вcкрыла ваш трафик (самодельный TOR).. А собираются они уже за периметром. Только это до первого поворота будет работать. Почему? См. Пункт первый...
PS Кстати 2-3 дня назад началось очередное обострение и привычные мне VPN отвалились. Надо будет посмотреть. Скорее всего придётся что то настраивать руками. Но Ваше решение помоему либо и бы точно (для разблокировки), либо недостаточно (для приватности)
Вы говорите про внимание к серверу. Разве РКН научился детектить VLESS? И что ему мешает обратить внимание сразу на канал Сервер в РФ -> Сервер в ЕС, чем он устойчивее прямого канала от вас до сервера в ЕС? Или чем устойчивее канал от вас до сервера в условно-нейтральной стране, чем прямой от вас до ЕС?
Если вам нужно оперативно менять конечный сервер на нескольких устройствах, почему бы вместо добавления на постоянной основе промежуточного сервера в соединение не воспользоваться механизмом subscriptions в VLESS клиентах?
Разве РКН научился детектить VLESS?
Частично - да, с эвристикой на длину пакетов при XTLS-Reality с SNI другого сайта и, соответственно, TLS 1.3. Пакеты больше 16-20 байт отбрасываются после 5 сек.
Решение: перейти на XTLS-Reality с самоворовством (self-steal/steal oneself), то есть со своим доменом, что вроде бы либо понижает TLS до 1.2, либо уменьшает длину пакета. Не знаю, но фиксится именно переходом на SNI своего домена.
Ну а трафик от вашего "промежуточного" сервера что, вопросов не вызовет тогда? Или трафик к промежуточному?
Больше похоже на усложнение ради усложнения.
Неоправданная сложность, на мой взгляд. Возможно, для VPN-сервиса такое нужно, но для персонального vpn достаточно просто сервера vless-панелью. Я не слышал, чтобы у кого-то блокировали его личные сервера. А если будут блочить по аномальному трафу на какой-то ip, то заблочат и middleman.
Но трафик на сервер внутри страны привлекает меньше внимания, чем прямой канал за границу
Но Middleman как раз и идёт за границу. Почему он должен привлекать меньше внимания?
Почему он должен привлекать меньше внимания?
https://habr.com/ru/articles/926786/comments/#comment_28564098
Сложновато. Обычная маршрутизация нужных портов через iptables на казахстанской впске работает так же хорошо :)
Мда... структурирование - это не ваше :))
А по теме: вы путаете и смешиваете обход блокировок и приватность. Отсюда такая сложность
AmneziaWG пока работает. (Хотя со стандартным конфигом, некоторые мобильные операторы уже научились блокировать)
ИМХО, с точки зрения обхода бокрировок, совершенно не раскрыта основная идея этого самого "Middleman". Если у вас есть VPS в России, трафик с которого зарубеж не фильтруется (а такие есть), то второй VPS и туннель до него уже не нужен. Аналогично и с условным "Армянским" VPS. Если до него ничего не блокируется, то и дальше все вполне нормально.
вот я тоже не понял, в чем цимес сервера посредника...
Но трафик на сервер внутри страны привлекает меньше внимания, чем прямой канал за границу.
Вот это по ощущениям берётся как данность, никак не доказанная.
РКН фильтрует трафик наружу и давит (ну или мы так предполагаем) определённые протоколы. Будет ли это трафик до сервера в дружественной или недружественной юрисдикции по имеющимся данным шайтан-коробке по барабану.
В теории это могло бы быть некоим подобием статической реализации схемы Tor'а, когда трафик для запутывания систем слежения перебрасывается из одной точку в другую.
Но во первых, это в первую очередь должно было проводиться без расшифровки (а иначе это типичный MITM), а во вторых теряется важнейшее достоинство Tor'а - динамичность.
Внутри страны точно также блокируют, просто в чёрные списки внесены прежде всего иностранные хостеры.
допустим, но вопрос в чем поможет предложенный промежуточный хост? Ну кроме того, что трафик будет на нём расшифрован.
Да хрен его знает, чем поможет. Скорее всего ничем. Скорее всего диапазоны адресов, на которых блокируются VLESS, будут постепенно расширять, так как его блокировка ломает всякое нужное, а потому лягушку нужно варить медленно. Уже сейчас VLESS успешно блокируется во многих регионах у многих провайдеров. Это же сначала обкатывают в отдельных регионах, а потом постепенно всё чаще включают на всю страну, вынуждая бизнес-пользователей отказывать от пострадавшей зарубежной инфраструктуры. А потом включают везде и навсегда.
То, что трафик не фильтруется, ещё не значит, что он не пишется.
Если у вас есть VPS в России, трафик с которого зарубеж не фильтруется (а такие есть), то второй VPS и туннель до него уже не нужен.
Есть пограничные случаи, когда замедление (youtube) не функционирует, но блокировка по ip (twitter, pornolab) работает.
https://github.com/go-gost/gost
Организует WebSocket или GRPC туннель в ОДНУ КОМАНДУ.
Без всех этих плясок с бубном.
Параноики могут через Gсore трафик дополнительно пробросить.
=)
Пока еще хватает простого ваиргарда до швеции.
"Из коробоки" AmnesiaWG спокойно справляется со своими задачи + объединения компьютеров в одну сеть, что важно в условиях блокировки стандартных VPN. К примеру для открытия доступа только с интрасети к своим ресурсам.
Мне кажется автор не разобрался в части dns , когда есть правила private и ru ip & address пропускать через локальный outbout , не разобрался зачем нужен ползунок sniffer и главное как с этим все работает один из самых главных параметров "домен только для маршрутизации".
Статья на 1\10. Совсем базовый уровень понимания как выше сказанное работает. Понимание сути межконтинентальных dns->ip когда ip выдаётся взависимости от местоположения для крупных сервисов.
судя по бреду "на промежуточном сервере траффик расшифровывается и потом шифруется обратно" - авто вообще не особо в вопросе разбирался.
Тут вы ошибаетесь. Трафик, который изначально нешифрованный, попадает в Vless (шифруется), на промежуточном VPS на некоторое время расшифровывается, чтобы быть вновь зашифрованным для второго Vless.
Возможно, вы ошибочно предположили, что условный клиентский запрос к https будет расшифрован на промежуточном сервере. Это не так.
Всю маршрутизацию (какой трафик в Россию, а какой за границу) делать на клиенте.
Трафик, предназначенный для выхода за границу пустить в vless туннель до заграничного сервера.
Если заграничный сервер блокируют, то туннель к нему завернуть в туннель до промежуточного сервера. Не цепочкой, в именно туннель в туннеле. Тогда на промежуточном сервере снимется только верхний слой шифрования, а внутренний без расшифровки продолжит путь до заграничного сервера. Заворачивание туннеля в туннель легко делается в конфиге sing-box (подозреваю что и xray тоже) клиента, как и вся маршрутизация трафика.
Само собой, при использовании голого sing-box, подразумевается наличие навыков ручного составления конфигов.
Можно пару слов про outline? Он же shadowsocks. Сижу на нем, на другие переходить не планировал. Стоит ли задуматься?
Определить, что у вас ShadowSocks цензура не сможет, для стороннего наблюдателя SS - это поток случайных данных. Однако, если включат белый список протоколов (а его в некоторых регионах уже применяли), например будут пускать только HTTP(S) и почту, а всё остальное резать, то SS заблокируется, потому что он точно не похож ни на один из стандартных протоколов.
Пока что одна из наиболее эффективных стратегий - применять какой-нибудь протокол мимикрирующий под HTTPS
аутлайн - мультиппротокольный клиент, шедоусокс - один из протоколов. не путайте понятия.
Стоит, ркн и отдельные провайдеры уже не раз и не два блочили всё что не https.
Пока работает пусть работает, но козырь в рукаве всё равно надо держать. И лучше не один. Когда понадобятся, настраивать без доступа к ресурсам и документации будет сложно.
Статье плюс, карме плюс, хабр - торт!
Какой путь в этой "гонке вооружений" выбрали вы?
Последний пункт из "9,5 правил ведения безопасного IT-бизнеса в России".
Так выходит, что со всей этой балканизацией Интернета VPN просто нужен. Априори.
Остались мосты в страны, где цензурят Сеть сильнее среднего по больнице? "Обратный" VPN для госуслуг, банков и прочей местной экосистемы.
Региональные ограничения плюшек в любимом сервисе? VPN/прокси/DNS.
Лень перезаходить в особо подозреваковые сервисы, которые 100% спалят, что ты уехал за тридевятьземель, хотя ты всего лишь сгонял в отпуск? VPN.
Нужно пройти KYC, у тебя несколько ВНЖ и паспортов, а сервис определяет страну по IP? VPN/прокси.
И список юзкейсов растёт. Через 20 лет безболезненно перемещаться можно будет, наверное, разве что внутри стран, входящих в военный блок, построенный вокруг местного ге(й)гемона. Выбери своего товарища майора, так сказать.
Это не только к РФ относится, к сожалению.
Тут, наверное, нужен будет обновлённый перечень "9,5 правил ведения безопасного IT-бизнеса на планете Земля (и как смыться на Марс к Илону Маску)".
Смените стандартный порт SSH с 22 на любой другой. Это не рекомендация, а требование.
Зачем?
защита от брут-флуда по стандартным портам. по опыту - на порядок меньше попыток коннекта
Та пофиг, ну стучит бот, и что? Потому что описанный вариант - это полумера отсекающая самых бесполезных ботов, более серьёзные способны просканить и найти твой ссш на кастомном порту. Если уже так хочется спрятать - прячь уже до конца, за какой-нибудь порт-кнокинг или вообще во внутренний контур, в впн
Та пофиг, ну стучит бот, и что?
Долбит TCP, грузит сеть и память. На бомж-впс это заметная нагрузка. В чем смысл держать его на 22? Лень цифры перебить в конфиге?
Потому что описанный вариант - это полумера отсекающая самых бесполезных ботов
Коих большинство. А вы знали, что в фишинговых письмах специально оставляют очевидные ошибки, чтобы не тратить время на людей, которые все равно не поведутся?
Если уже так хочется спрятать - прячь уже до конца, за какой-нибудь порт-кнокинг или вообще во внутренний контур, в впн
Какой-то юношеский максимализм. Нестандартного порта и авторизации по ключу более чем достаточно.
Долбит TCP, грузит сеть и память. На бомж-впс это заметная нагрузка.
Вы пробовали эту нагрузку оценивать? Подозреваю что нет, не заметная.
Нестандартного порта и авторизации по ключу более чем достаточно.
Авторизации по ключу достаточно, перенос порта не имеет смысла. Разве что вас коробят логи с неудачными попытками подключения. Но даже так, убрать ssh с внешнего интерфейса будет эффективнее переноса порта
P.S.
Какой-то юношеский максимализм.
Я предпочитаю нормально-закрытый фаервол и не открываю порты без необходимости. И однажды я полюбил решения вида tailscale/netbird/zerotier... Также как вам несложно перевесить порт ssh, так и мне несложно оставить доступ к нему только на внутреннем контуре
На практике, нестандартный порт прожил в тишине меньше недели. Дальше попал в скан, и распространился по ботам, которые жарили по 4000-10000 запросов в неделю. Только белый список IP/CIDR откуда можно 22-ой порт - спасает.
Порт-кнокинг выглядит универсальнее, но руки не доходят до изучения.
Я могу сказать почему во всех штампованных статьях есть этот идиотский пункт «Засуньте голову в песок»
Потому что кто-то однажды еще в 00ых написал это заявив, что так безопасней
С той поры люди не понимающие что делают, а просто повторяющие магические заклинания везде лепят этот идиотизм.
ssh на порту отличном от 22го никак не увеличивает безопасность, а вход по ключам полностью убирает шансы перебора, потому все эти перевешивания не нужны. Но перед нами человек не понимающий элементарных вещей и просто повторяющий магические заклинания которые он видел в других местах
имеет смысл применять в комбо с другими мерами, например порт прячется на нестандартный типо 12345, при этом все соседние порты бросают в блэк лист сразу. сканить будут-заблочатся. лишних коннектов нет. а ключ это само собой
Не имеет это никакого смысла
Security through obscurity это глупость
Хочешь спрятать ssh? Убери его на IPv6, засунь его на VPN-интерфейс и убери с внешних. А переносить порт это детский сад, все сканируется за секунды. Только себе добавляешь проблемы каждый хост прописывать в ~/.ssh/config с его портом
Имеет отличный смысл, ты ничего не насканируешь, если у тебя куча портов при обращении автоматически кидают блокировку, и какой-то случайный между ними спрятанный, будет относиться к нужному сервису. Ipv6 всё ещё не является полноценным и его проще просто отключать, чем ещё возиться с его настройкой
если у тебя куча портов при обращении автоматически кидают блокировку
Если сканируют с одного или небольшого количества адресов
Ipv6 всё ещё не является полноценным
Эм…
проще просто отключать
Одна из причин замедления распространения протокола
Ради скана 65к адресов применять аккуратно меняя каждый на новый порт? Это уже на целевую атаку похоже
Именно потому, что он мало где используется и поддерживается смысла перехода нет. То есть вместо одного рабочего предлагается не другой рабочий, а один рабочий и один наполовину
Ради скана 65к адресов применять аккуратно меняя каждый на новый порт
Нет, это похоже на обычный скан интернета развитого ботнета. Они все равно просканируют весь ipv4 довольно быстро
У ботнета может быть и больше адресов, но вот использование всех сразу на один DST, что-то более уникальное. Но все же речь о том, что б не целенаправленная ддосилка не положила коннекты и это решает. При этом ботнеты крайне тупы, даже если включен только ключ и сервер в явном виде это люотдает, будут зачем-то долбиться
использование всех сразу на один DST
Вам это кажется, потому что вы не видите со стороны управляющего узла какой диапазон адресов загружен в ботнет для сканирования и как происходит распараллеливание запросов.
Ну, я по логам серверов вижу, что иногда и распределённо сканируют: каждый новый порт с нового адреса, и таких адресов тысячи. Это видно по возрастанию портов на которые идут попытки коннекта, при том, что IP всё время разные. С точки зрения организатора серьёзного ботнета нет принципиальной разницы, как сканировать - по диапазону портов на каждый адреса или по диапазону адресов и одному порту. Да, чуть замороченней, зато сложно детектируется и блокируется.
Человеку который говорит про «неполноценность» IPv6 мне даже ответить нечего, это будет как выступление академика перед детсадовцем
Ты небось девопсом работаешь, да? Знаний нет, но агрессивный и продвигает свою чушь
Да я побольше твоего знаю, тем не менее полноценным он станет когда все его будут поддерживать и можно будет дропнуть старую версию. А пока это выглядит как поиграйте с нами в новый стандарт, который пока не заменил старый. То есть в два раза больше работы делайте.
Я работаю с реальными, а не хипстерскими вещами. Агрессивно навязывать сырые или не распространенные это вот чушь. Как будет готово на 100% для всех, вернёмся к разговору. А так банальное начниссебятельство.
Мальчик, что ты знаешь?
Ты называешь IPv6, который превысил IPv4 по данным Google и Amazon «неполноценным»
У тебя нет базовых знаний сетей, тем более нет знаний практических. При этом ты сразу начинаешь хамить старшим, просто потому что тебе указали на отсутствие знаний
Иди дальше играться в кубики свои, не лезь в темы в которых не понимаешь. Иди дальше перевешивай на своей винде ssh на другой порт, если мама разрешит на ее компьютере что-то делать
А что в винде ссш завезли? Предки мамонта помнят?
Если по какой-то придури ipv6 раздают пучок за пятачок, это не значит, что они популярные. Для динозавров объясняю первый и последний раз: можно не включать ipv6 и все будет работать, так как сервисы работают на ipv4 точно. А вот наоборот не прокатит, так как есть ipv4 only. А сколько там этих префиксов выдали, это отдельная абстрактная метрика
О коллега по мыслям :) А еще задолбала рекомендация ставить fail2ban. Теоретически он может конечно помочь от DDOS на SSH, вот только если DDOS будет правильный, то не поможет...
Не, ну про f2b я слышал от коллег типа «что бы логи не засирались», но я этот аргумент тоже понять не могу. Ты логи чо глазами перед сном читаешь что ли и тебе лишние записи там мешают? Нет? Они парсятся автоматом если нужно? Ну так твоей автоматике пофигу на «лишние» записи
А что до DDoS, ну тут, простите, другие защиты. На уровне сервера ты от нормального DDoS один хрен не отмахаешься, тут нужна защита на уровне твоего хостера или прикрываться тем же CF, что бы никто настоящего адреса вообще не знал и не было возможности атаки по адресу
Просто у меня опыт с 97го года, я помню как эта мода появилась менять порт ssh и понимаю, что сейчас строки про нее добавляют люди которые вообще не знают о чем пишут, просто «тут так принято»
Ну так твоей автоматике пофигу на «лишние» записи
У меня как-то раз logrotate с ума сошел и nginx логами забил весь / впски.
как-то раз logrotate с ума сошел
Разработчику сообщали?
Нет, у меня нет компетенции искать причину возникновения проблемы, в линуксах я простой пассажир.
в линуксах я простой пассажир
Но для заявлений подобных вашему необходимы те самые компетенции.
А людей без компетенций всегда сопровождают странности и необъяснимые вещи. Касается любых областей человеческой деятельности.
Но для заявлений подобных вашему необходимы те самые компетенции.
Разве? Ну вот видите. Поэтому и не сообщал разработчику.
А людей без компетенций всегда сопровождают странности и необъяснимые вещи. Касается любых областей человеческой деятельности.
Совершенно согласен, но я logrotate не трогал и он у меня на 3 других впсках работает нормально. На четвертой - не работает. У меня просто нет интереса выяснять, почему.
Не знаю что нужно сделать, что бы «logrotate сошел с ума»
Дефолтный конфиг logrotate для nginx справляется с гигабайтными логами спокойно, а у нас вообще речь об auth.log который таким ты за сутки не отрастишь никак(ну кроме само DoS'а целенаправленного) речь
Все прекрасно справляется и нет никаких проблем с логами. Я повторю, как специалист, в том числе, в безопасности: перевешивание ssh на другой порт бессмысленно и бесполезно, о нем пишут просто копируя из чужих инструкций не понимая смысла этого действия люди не очень разбирающиеся в вопросе
Не знаю что нужно сделать, что бы «logrotate сошел с ума»
Я тоже, можете поверить - я к нему даже не прикасался.
Все прекрасно справляется и нет никаких проблем с логами.
"У меня такая же нога и она не болит".
Я повторю, как специалист, в том числе, в безопасности: перевешивание ssh на другой порт бессмысленно и бесполезно
А я отвечаю, что мне совершенно не сложно поменять порт в конфиге ssh. И количество попыток подключения в минуту это тоже элементарная для подсчета цифра, то есть эффект есть. Ну не нравится мне тыща попыток логина в минуту с admin:admin, почему вас это так напрягает?
Смотрите что мы имеем: бездоказательное утверждение, а на вопрос «а не пробовали пожаловаться авторам» ответ «Да плевал я на это»
Но при этом утверждение, что плохой логротейт не работает
Можно ли верить? Я бы не стал, но каждый решает сам
Смотрите что мы имеем: бездоказательное утверждение, а на вопрос «а не пробовали пожаловаться авторам» ответ «Да плевал я на это»
Смотрите что мы имеем: если бы каждый раз, когда в linux что-то не работает, я писал бы авторам, у меня день начинался бы не с кофе. И в ответ я бы получал только рассуждения о моих компетенциях, ибо я не Linus Tech Tips, и звать меня никак.
Когда у меня что-то не работает, я обычно иду в issues на гитхабе, если он мне известен, и ищу решения (в основном около python и ml). Иногда я нахожу их сам, и пишу в соответствующих issues. Но ни разу в жизни не было так, чтобы на это отреагировал разработчик. 0 раз. И что самое характерное, я даже не могу винить за это людей, которые работают бесплатно.
Но при этом утверждение, что плохой логротейт не работает
Логи не чистятся -> logrotate не работает. Я даже не знаю, что тут еще добавить. Мне они вообще не особо нужны были после первоначальной настройки, так что я их просто выключил на проблемном сервере.
мне совершенно не сложно поменять порт в конфиге ssh
Вы путаете сложность с полезностью. Вам говорят, что это бесполезно, а вы возражаете, что это несложно.
Приведу аналогию смены порта понятную для обывателя.
Есть забор вокруг домовладения. В некоторой точке забора вмонтирована калитка с надписью "Вход" крупными буквами. Так вот смена порта ssh по своему смыслу будет идентична перевешиванию калитки в другое место забора, с сохранением надписи "Вход".
Это уже смахивает на создания аналога Tor, там и тут тоже промежуточные сервера, там и тут обфускация
Для мобильного интернета пользуюсь другой схемой
Тут раскрывать не буду)
В личке тоже
Но этот вид посредников я не видел нигде
А вообще некоторые вещи прекрасно комбинируются!
Моя схема работает уже 7 месяцев без проблем (в том числе начиная с момента недавних блокировок)
Нам понадобятся два самых дешевых VPS на Ubuntu 22.04 (1 vCPU, 512MB RAM). Один в "нейтральной" стране (Middleman), другой — в Европе (Gate).
В такой конфигурации скорость никогда не будет превышать 40-45 Mb/s -- у всех дешевых VPS интерфейс 100 Mb/s, который в свою очередь скорее всего будет Shared, 100 делим пополам (входящий и исходящий траф будут делить один условный таймслот) и минусуем заголовки протокола.
Я бы не гнался за дешевизной, если важна скорость, и выбирал бы гигабитные решения.
Насчёт скорости дешёвых VPS слишком категоричное заявление. Масса дешёвых хостеров предоставляют гигабитный порт. Другое дело, что сейчас почти везде объём трафика лимитирован (однако, зачастую лимит вполне достаточный).
Да, и гигабит с полным дуплексом, насквозь.
Насчёт скорости дешёвых VPS слишком категоричное заявление.
Это заявление подкреплено тестами.
Недавно делал подобную оценку хостингов, которые заявили гигабитный канал на предлагаемых в аренду VPS. Четверо эту проверку провалили. Один из них даже развеселить сумел (подробности под спойлером).
Скрытый текст
Мда, какой-то позор просто... Ну оставлю тогда рефералочку, но не знаю как там с оплатой из России дела обстоят. У меня весь вебсерфинг через неё, всё устраивает и стоит 2 евро в месяц.
https://webdock.io/en/pricing?ReferralCode=WDREFAJNY
За ссылку спасибо, но у меня с этим хостингом дорожки разные. Оказывая помощь нескольким десяткам знакомых, контроль трафика невозможен.
Скрытый текст
А у софта нету никаких крутилок для ограничения трафика по логинам?
Спрашиваю не просто так -- я автор dumbproxy, в нём в принципе можно накрутить лимиты по трафу, но не очень удобным образом. Думаю, насколько целесообразно и востребовано было бы прикрутить лимиты по трафику.
О, большой человек! Как раз недавно крутил вашу программку, а авторизации по IP у вас нет, или я слепой? Впрочем, наверное, можно просто завернуть через фронт, где есть. Но было бы удобнее так.
Там целый скриптовый движок есть чтобы любое сочетание правил нарисовать можно было. Опцией -js-access-filter задаём файл со скриптом:
const allowedIPs = new Set([
"203.0.113.99",
]);
function ipFromAddrPort(addrPort) {
return addrPort.replace(/\:[^:]+$/, "").replace(/^\[(.*)\]$/, "$1");
}
function access(req, dst, username) {
const ip = ipFromAddrPort(req.remoteAddr);
if (allowedIPs.has(ip)) {
return true;
}
print(`rejecting IP address ${ip} due to IP filter restrictions`);
return false;
}Добавил рецепт в вики проекта: https://github.com/SenseUnit/dumbproxy/wiki/Recipe:-restricting-access-by-IP-address
А у софта нету никаких крутилок для ограничения трафика по логинам?
Нет. Я думал о tc, но с ним схема сильно усложнялась, учитывая динамичность количества поддерживаемых учеток, а шейпить хотелось по справедливости. Остановился на наборе разрешенных портов.
Скрытый текст
set clients_forward.ports {
type inet_proto . inet_service
flags interval
elements = {
tcp . 53, # dns
tcp . 80, # http
tcp . 443, # https
tcp . 465, # SMTP
tcp . 587, # SMTP
tcp . 853, # dns-over-tls
tcp . 993, # imap
tcp . 4083, # whois
tcp . 5222, # android
tcp . 5228, # android
udp . 53, # dns
udp . 123, # ntp
udp . 443, # https-quic
}
}
я автор dumbproxy, в нём в принципе можно накрутить лимиты по трафу
Спасибо за предложение, но не срослось у меня с прокси-решениями, роутинг мне кажется проще и гибче в управлении.
WireGuard с обфускацией UDP2RAW пока что прекрасно работает. Причём, когда у нас тут всё жестоко блочили (на 9 мая и 12 июня), то туннелирование через icmp и прокси через ssh всё ещё прекрасно работали.
Какой путь в этой "гонке вооружений" выбрали вы?
AmneziaWG
Тоже схема из двух VPS, первая из которых в РФ и она же делает сплитование клиентского трафика с помощью PBR по правилу: если таргет в RU-сегменте (по IP, а не по домену), тонаправляю на WAN-интерфейс, весь остальной трафик в туннель меду VPS.
Несколько раз порывался использовать Vless+something, но каждый раз плевался из-за проксирования вместо роутинга -- это делало неработоспособными правила PBR.
Рекомендую v2RayN вместо Nekoray на винде, недавно у меня и у знакомых он (Nekoray) сломался в один момент, хотя разные серваки юзали
В порыве страсти и желании выпендриться афтар спалил на всю ивановскую схему которой уже 3 года как.
БРАВО!
Ничего что эта «схема» и так, в целом, известна. И подобная инструкция далеко не первая, и, подозреваю, не последняя?
Кэп, спасибо, я про это как раз и писал))) Тут мисье выдал лютый лонгрид за то что делается условно за 30 минут одной рукой и одним глазом. Другое дело что схема не популярна по экономическим причинам, вменяемая скорость будет условно за 10килорублей в месяц, а это "не толь лишь каждый" может себе позволить
Если заморочаться с роутингом не в xray, а стандартными средствами linux, то теоретически можно сделать цепочку OpenVPN/L2TP в РФ -> Xray снаружи. На мой субъективный взгляд, конвенциональный VPN внутри страны будет не более заметным, чем HTTPS траффик к ресурсу внутри страны, но зато можно настроить VPN сразу на маршрутизаторе.
И лучше, наверное, несколько разных Xray серверов c балансировкой запросов.
OpenVPN/L2TP
Зачем из пушек по воробьям палить? В случае ненадобности полноценного маршрутизируемого с двух сторон туннеля, если использовать линуксовый PBR на основе списка доменов (dnsmasq+ipset/nft sets) либо списков IP, то вполне хватит связки высокопроизводительного hev-socks5-tunnel для создания маршрутизируемого tun (tcp+udp) и xray как транспорта.
Из пушки по воробьям палить, если хочется любой дешёвый маршрутизатор использовать как клиент, а они в лучшем случае только OpenVPN и поддерживают.
Всё, теперь понял, о чём вы. Как вариант, именно для таких дешевых маршрутизаторов - вполне себе. Можно написать скрипт и средствами OpenVPN пушить клиенту маршруты на ip заблокированных ресурсов через vpn (если конечно у дешевой железки оперативной памяти хватит хранить тысячи записей). И это при условии, что провайдер не трогает сам впн-протокол, а в случае с openvpn были уже преценденты блокировки даже внутри РФ.
Интересный подход к безопасности. Бояться, что злое гос-во будет читать трафик в оперативке вашего личного vpn-сервера, но рекомендовать использовать в качестве SNI популярные домены, которые используют выделенные, общеизвестные подсети ip. Ведь совершенно не подозрительно для DPI видеть, как с вашего ip идёт запрос к Microsoft.com, чей ip принадлежит ASN vasya-pupkin-vps Inc.
Кроме того, использование в качестве SNI адреса CDN просто опасно. Т.к. vless отправляет "неправильные" запросы на сайт, под который маскируется. И если обращаться к вашему серверу по ip, используя SNI, который находится ЗА CDN, ваш сервер будет исправно перенаправлять трафик на этот сайт. По сути, он будет бесплатным прокси для этого CDN. И многие товарищи из более цензурированных стран этим активно пользуются. Можно однажды зайти в панель управления сервером и увидеть, что за день куда-то улетел лишний ТБ трафика.
Цепочка серверов имеет смысл, если "входной" сервер будет в РФ, т.к. внутри страны трафик цензурируется менее строго, как и трафик с vps в России на внешние сервера. И то, с недавних пор доступность с vps внутри РФ до серверов известных иностранных провайдеров может хромать.
Чтобы прокси исправно работал, пока что достаточно использовать малоизвестные хостинг-провайдеров и менее палевные SNI. А ещё лучше, поднять свой сайт и использовать его в качестве SNI. Так и пинг будет лучше, и вероятность блокировки меньше (кроме РКН, вас может заблокировать и сам сайт, т.к. каждое ваше обращение к впн серверу создаёт обращение к сайту-маскировке, что даёт некую нагрузку на этот сайт). В будущем, если блокировки ужесточатся, можно использовать splithttp, который разделяет одно соединение на несколько, отправляет их на разные сервера, которые отправляют всё на конечный сервер, что собирает всё трафик воедино.
А вот рекомендации по защите сервера и панели хороши.
P. S. В Vless есть защита от анализа трафика - клиент отправляет ещё и мусорные пакеты, даже когда вы не используете прокси (ничего через него не шлёте). Насколько сейчас это действенно не знаю, но в Китае год назад точно определить прокси трафик vless не могли.
инструкция полное дно... у чувака даже снифинг невключен.. как соеденить 2 сервера в панели 3x-ui на промежуточном включаем routing и в правилах провисываем оутбаунд конечного сервера.. правила для рашки прописываем.. для геймеров это связка не подойдет так как мы получим 2ой пинг.. это дно расходимся
Если кто-то интересуется мультихопом, то dumbproxy поддерживает форвардинг через вышестоящий прокси и прост в настройке.
А можно дурацкий вопрос? Понимаю, что меня могут заминусовать, но любопытство сильнее. Зачем эти все увертки? От кого что прятать? Кому что надо скрывать? Или чисто для ютуба/ инстаграма / тиктока эти все танцы? Всегда вот это интересовало.
Зачем эти все увертки? От кого что прятать? Кому что надо скрывать?
[sarcasm]
Сможете объяснить, зачем вы сюда заходили по https? Ваш комментарий вполне безобидный и не несет в себе ничего ни противозаконного, ни секретного. Зачем было его оставлять, скрываясь за https?
[/sarcasm]
А теперь серьезно. Зачем все эти увертки государства ради одной цели -- нарушения моих конституционных прав? Им больше заняться нечем, других проблем нет, кроме как топтать мои права?
Допустим, что "для ютуба/ инстаграма / тиктока". Вы считаете, что этого не достаточно?
Кому что надо скрывать?
Вы когда в туалет или в душ ходите, дверь зачем закрываете, вам есть что скрывать?
Ну смотрите, вот на пальцах, образно. Если кто то грязный и воняет его пустят в кинозал? Непустят. Но если он переоденется и отмоется то станет такой как и все и его пустят.
На счет VLESS, вы вообще уверены, что блочат именно его, а не хостеров ваших VPS?
Я просто впервые слышу, что его блочат. У меня людей знакомых много, на разных регионах и провайдерах, и у всех все хорошо с ним.
Все хорошо, но вот примеры файлов config.json от обоих серверов хотя бы в конце статьи лучше смогли помочь получить полное понимание "что это лишь интерфейс к настоящей магии, которая творится в конфигах."
Схема сложная получается, но малость бесполезная. Главная задача это чтобы трафик в замаскированном виде покинул пределы РФ и с этим прекрасно справляется первый сервер, который в данном случае почему-то промежуточный. Делать цепочку из нескольких серверов вижу смысл только, если нужны несколько локаций с возможностью их быстро переключать, когда например часть сайтов идёт через одну страну, часть через другую.
Так же тема выбора vps для vpn сервера вообще не раскрыта. Брать самый дешёвый тариф это антисовет, нужно как минимум учесть сколько клиентов будут использовать vpn, какой средний объём трафика в месяц (у многих хостингов есть ограничение в 1-5 ТБ). Производительность сервера тоже немаловажна, xray при активной маршрутизации неплохо нагружает процессор. Так же нужно учитывать пропускную способность сервера, если хотите нормальную скорость через vpn (например гигабит/с, то придётся поискать хостера с нормальной сетью). Я с несколькими знакомыми протестировал кучу различных хостингов чтобы найти идеальный для своих нужд и результаты довольно интересные. Под свой vpn использую сервер с парой ядер Ryzen 9950x и 10 Гбит сетью.
У меня сейчас поднят vless, который находится за nginx рядом с моим сайтом, под который собственно всё и маскируется, это максимально естественная маскировка.
Так же есть сервер на OVH, там работает только AmneziaWG, любые другие протоколы блокируют
VLESS+Reality и Multi-hop: Архитектура VPN-цепочки для нового поколения блокировок