Comments 129
Популярность вашего решения резко вырастет, если добавить ссылку на гитхаб и ещё Dockerfile.
В Docker умею только как юзер.
Мда если честно это такой геморрой и vpn проще будет поднять и маршруы закидать на клиенте всго 2 действия
Это ваше право. Для меня прокси проще, а x-ui поднимается и настраивается примерно за схожее количество шагов (если не тупо весь трафик через него гнать):
Ставим x-ui \ Ставим squid
Настраиваем inbound \ Настраиваем squid
Прописываем маршруты \ Автоматизируем сборку файла с заблокированными доменами
PROFIT
Другое дело, что в случае с прокси на стороне клиента ничего делать не нужно - максимум расширение для браузера с поддержкой авторизации для прокси поставить.
Представьте, что скинули history в файл.
Не надо это популяризировать, squid-openssl на удалённом сервере это, мягко говоря, не самая лучшая идея.
Поясните свою точку зрения ?
https://habr.com/ru/articles/866746/comments/#comment_27677704
squid-openssl предназначен для SSL bumping, то есть для того чтобы кешировать и фильтровать зашифрованный контент. Это более-менее нормально если это будет внутри домашней сети и на сервере, которому ты доверяешь. Но если это на удалённом хостинге, то теоретически его могут взломать и получить доступ ко всему трафику.
ЗЫ Посмотрел ещё раз конфиги - не уверен на 100%, но похоже я неправ и автор использует squid-openssl для заворачивания https в https.
Вы правы в этом сообщении, и не правы в прошлом: мы не расшифровываем ssl, а проксируем. Делать MITM это тот еще геморрой, я даже не возьмусь писать инструкцию. Да и нужды в этом нет никакой.
Вот как выглядит трафик для сервера в отчете за вчера:

Единственное, что реально "утекает" при включенном логгинге - это IP клиентов и SNI сайтов, на которые они ходят. В том числе и поэтому в конце гайда есть инструкция о том, как логгинг access можно отключить. При этом отчеты calamaris намеренно не включают в себя информацию о том, кто и куда ходит. Хотя в самом логе такая информация есть.
Только не аеза. Сменили сами ip адрес сервера и этот новый адрес во многих сервисах в блеклисте...а замена на "работающий" не бесплатна)) Поменял хостера.
Обычный сквид не умеет https: его нужно либо собирать из сорцов --enable-ssl-crtd --with-openssl
, либо ставить с левой репы.
This project provides scripts needed to recompile modern version of Squid on Ubuntu 22.04 LTS with support for HTTPS filtering and SSL inspection. Results of the compilation are available in the public repos hosted by diladele.com.
UP: дописал.
UP2: поправочка, в 24.04 уже есть squid-openssl версии 6.6. В целом, не вижу вреда от левой репы, раз она актуальна для более старых систем. В новые все равно встанет из родной.
Что значит "Обычный сквид не умеет https"? Всё он умеет. Он не сможет заглядывать внутрь зашифрованного трафика и кэшировать его, но пробрасывать его будет без проблем.
Жонглирование сертфикатами имеет свои последствия, если удалённый сквид взломают, то злоумышленник получит доступ ко всему трафику через прокси, включая пароли.
Спрашивается, зачем так усложнять конфигурацию, чтобы в итоге серьёзно ослабить свою безопасность. Чтобы что?
Как минимум следует указать о такой опасности, чтобы народ не тянул бяку без понимания, что он делает. Всех предупреждаю, если вы глубоко не понимаете, о чём речь, то не пользуйтесь squid-openssl, описанным в статье.
Вполне достаточно простого squid, это будет гораздо безопасней и проще в настройке.
Хотелось бы добавить, не пользуйтесь также случайными инструкциями из Интернета.
ЗЫ Посмотрел ещё раз конфиги - не уверен на 100%, но похоже я неправ и автор использует squid-openssl для заворачивания https в https, а не для SSL bumping. Прошу пояснений, я верно понял?
Вполне достаточно простого squid, это будет гораздо безопасней и проще в настройке.
По поводу ssl-bumping уже написал, а squid без openssl не понимает директиву https_port, только и всего. Собственно, я раньше им и пользовался, пока не задумался, насколько нежизнеспособная затея - гонять plain http и надеяться, что его не найдут.
Сертификатами мы не жонглируем и трафик не расшифровываем.
Спасибо, теперь понял. А то я начал читать для чего используется squid-ssl, а у него везде в описании стоит что он предназначен для ssl-bumping.
Но у меня ещё вопрос, зачем всё-таки нужен второй прокси? Чтобы скрыть что первый прокси за границей и от клиентов не было прямых коннектов за границу?
По поводу плагина, здесь пишут что достаточно выставить опцию network.negotiate-auth.allow-proxies, тогда плагин не нужен.
ЗЫ интересно как работает https прокси - шифрует зашифрованный трафик по второму кругу?
Но у меня ещё вопрос, зачем всё-таки нужен второй прокси?
Чтобы не гонять трафик до российских ресурсов через заграницу, а выпускать его сразу с российского сервера
Чтобы со стороны фильтрующих коробочек у провайдера был видно, что пользователь всегда подключается к российскому серверу - в этом случае, как показывает практика, фильтрация по протоколам происходит не так активно.
интересно как работает https прокси - шифрует зашифрованный трафик по второму кругу
К сожалению да. Поэтому в теория этот вариант уязвим к детектированию TLS-in-TLS
Чтобы со стороны фильтрующих коробочек у провайдера был видно, что пользователь всегда подключается к российскому серверу - в этом случае, как показывает практика, фильтрация по протоколам происходит не так активно.
У "коробочек" провайдера есть какая-то принципиальная разница между тем, кто стучится забугор — домашний ПК на Windows или сервак на Linux?
если сервак на Linux стоит у абонента, то разницы нет, блокироваться будет одинаково.
а вот если сервак стоит в дата-центре, то разница большая - там часто этих коробочек или нет вообще, или они работают не настолько яростно (например, на них не распространяются региональные блокировки, как недавно в Дагестане).
Чтобы не гонять трафик до российских ресурсов через заграницу, а выпускать его сразу с российского сервера
Зачем российский трафик гонять через прокси, если можно напрямую? Это же можно настроить через Automatic proxy configuration URL, он для этого предназначен. Ну или просто через No proxy for *.ru в браузере
Но у меня ещё вопрос, зачем всё-таки нужен второй прокси? Чтобы скрыть что первый прокси за границей и от клиентов не было прямых коннектов за границу?
Во-первых, да, чтобы клиенты ходили в одну точку, а там уже серверы между собой ими жонглировали.
Во-вторых, первый сервер в РФ забирает у клиента задачу настраивать маршрутизацию. То есть клиент настраивается один раз и навсегда. Дальше маршрутизация настраивается админом на сервере, и клиентам об этом задумываться вообще не нужно. Это, во-первых, проще развернуть на множество клиентов, а во-вторых убирает проблемы совместимости: если софт умеет прокси, то он будет ходить куда нужно и как нам нужно, потому что он вообще не задумывается о маршрутизации.
Да, я первым пробовал HAProxy, но мне не удалось завести авторизацию по IP и по логин:пароль.
У меня сильно проще схема, и для другого. Я в Украине, и мне бывает нужно пользоваться российскими сайтами с российского IP. Еще что то. Тут нет такой глобальной блокировки как в РФ, и такого маразма, люблй прокси или VPN работает. Ну и некоторые сервисы в РФ вообще не хотят работать с зарубежными IP.
Есть 2 сервера, один в рф, на нем Squid, без шифрования, на самом деле шифрование не так уж и нужено, т. к. используется запрос CONNECT, и если само соединение подразумевает шифрование, то прокси просто как бы через себя пробросит порт, в общем в сеть не уйдет никакой конфиденциальной информации больше, чем если б прокси вообще небыло, разве что злоумышленник сможет узнать а куда именно (адрес) я через прокси ходил перехватывая мой трафик гдето по середине (ip адрес и порт, для подключения то открытым текстом передается).
Ну, а на втором сервере в общем-то ничего нет, просто через iptables проброшен порт. В админке уже самого сервера разрешено подключение по IP адресу, к проброшенному порту, чтоб я дома со своего провайдера мог получить доступ.
Минус прокси в отличии от VPN есть, он в том, что если нужно проьросить UDP траффик то он не пойдет.
Без https логин и пароль для подключения к прокси будут же передаваться открытым текстом. Не сильно страшно, но всё-таки неприятно.
И можно пояснить, зачем второй сервер? Разве одного прокси недостаточно?
Да, без активного вмешательства цензора в трафик вполне подойдет проксировать CONNECT в HTTP. У нас в любой момент могут прикрутить на ТСПУ скрипт, который будет брать авторизацию из plaintext-http и пытаться достучаться до запрещенки самостоятельно, делая по результатам проверки выводы. ChatGPT такое напишет за пару минут. Рекламу в HTTP вставлять уже не гнушаются, дело за малым.
Они точно так же могут сходить к вам по TLS и попытаться сделать CONNECT без пароля или с неправильным рандомным паролем, и если сервер ответит им не 405 Method not allowed или 400 Bad Request, а 403 Unauthorized или 407 Proxy Authorization Required, то заблокировать его по IP, потому что на адресе явно находится прокси.
Прокси найдется, это да. Но у них хотя бы не будет однозначного ответа, пускает ли прокси куда не надо.
Но у них хотя бы не будет однозначного ответа, пускает ли прокси куда не надо.
Их это, к сожалению, волновать уже не будет, просто заблокируют.
Наверное. Есть смысл покумекать, за чем спрятать squid от active probing. Либо научить squid отдавать 400 вместо прокси-кодов...
Не совсем понятно, чем эта схема лучше банального SSH туннеля с SOCKS проксей?
А как конечный пользователь будет у себя ssh туннель настраивать? С прокси просто, открыл настройки, ввёл три значения урл, логин, пароль и всё.
А как ходить на российские сайты, которые на Западе заблокированы или заблокированы для Западных айпи уже с российской стороны?
>А как конечный пользователь будет у себя ssh туннель настраивать
Например, той же переменной среды https_proxy=socks5://127.0.0.1:1080.
перед этим сначала надо саму SSH-сессию поднять. попробуйте объяснить, например, пенсионерке в преклонном возрасте, как это сделать.
добавить скрипт в любой доступный вариант автозагрузки и пусть он занимается поддержанием активной ssh сессии в течение всего аптайма
Не так-то это просто. Если всё это обернуть в какой-то пакет, то наверное пойдёт, но этот пакет нужно ещё поставить, потом добавить желательно зашифрованный ключ ssh с правильными правами.
Потом нужно на сервере это всё правильно ограничить, чтобы кроме прокси больше ничего на сервере не было доступно, но это вроде бы несложно.
Отключить для российских сайтов можно и прямо в чёрном списке в настройках браузера.
Потом желательно какой-то способ запустить/остановить проксю.
Для Линукса я это ещё представляю как сделать, для Виндоса уже нет, но наверное можно. А как быть с Андроидом?
Исхожу из того, что конечный пользователь и админ прокси это одно лицо. Если надо всё настроить для далекого от сетевых технологий человека, то да, это не самый хороший вариант
Очевидно, что для этого туннель должен быть на сервер в РФ, разве в случае прокси что-то меняется?
Если вам не нужно кэширование, то вместо squid можно использовать https://github.com/SenseUnit/dumbproxy
Если я правильно понимаю схему, то можно вместо местного прокси использовать функционал расширения https://github.com/anticensority/runet-censorship-bypass, которое умеет брать список заблокированных сайтов и заворачивать в прокси только их.
Я бы все же не рассчитывал на работоспособность plain-http в долгую. Это явно не наша заслуга, что он работает, а их недоработка.
Если вам не нужно кэширование, то вместо squid можно использовать https://github.com/SenseUnit/dumbproxy
У dumbproxy кстати есть большое преимущество по сравнению со squid: он умеет защищаться от active_probing'а с помощью hidden_domain
Для себя я бы просто закрыл вход для всех IP, кроме своих клиентов.
(del)
Если клиенты на динамике, то придется открывать доступ на все диапазоны адресов их провайдеров, а коробочка, делающая пробинг, вполне может стоять у того же провайдера за тем же NAT'ом.
А с чего у вас уверенность, что цензор не может осуществлять пробы с ИП-адресов клиентов, которых видел?
VLESS может работать как прокси, возни с этим решением кратно меньше, ключи продаются на каждом углу.
А, и да, у всех решений формата прокси главный минус — за пределами браузера не каждая прога это нормально переваривает. Например у дискорда разрабы криворукие, там просто хз как прокси указать, есть какие-то извраты с патчем библиотек, но они не всегда работают.
Все верно, UDP не будет. Но я пользуюсь такой связкой без него уже года 2 и первое, что мне пришлось обходить какими-то костылями - это как раз Discord. Для ютуба и всей прочей запрещенки в браузере прекрасно подходит прокси.
Что касается VLESS, то я ярый адепт selfhosted, поэтому ключи на каждому углу меня не очень привлекают. Плюс, здесь один раз накрутил на стороне сервера - и пользуешься, где хочешь. Настроить по телефону родственнику прокси тоже на порядки проще, чем условный nekoray. Это если вы, конечно, не предлагаете на том же сервере открыть доступ к порту "прокси" VLESS-клиента. Такое я не пробовал, наверное взлетит, вопрос только что там с авторизацией.
В этом плане все сейчас гораздо проще стало - вместо Nekoray с действительно сложным для новичков интерфейсом, теперь есть Hiddify, в котором при установке надо выбрать из списка страну (чтобы автоматически применялись маршруты напрямую), а после установки нужно просто нажать плюсик и вставить ссылку на подписку (с которой он ещё потом сможет автоматически обновлять список серверов), после чего вся работа с прокси будет сводится к нажатию огромной красивой кнопки "Подключиться". Справится даже пенсионер.
Теоретически - да. На практике, тут в соседней теме человек пишет, что у него "на android hiddify работает, а под виндой все идёт мимо него". Я товарищам и VPN раздаю, через тот самый hiddify / v2rayNG по QR-кодам, и хочу сказать, что вопросов ко мне и по настройке, и к стабильности там сильно больше, чем вопросов по прокси (по крайней мере было, пока я с tcp vless не перешёл на grpc).
Там человек писал про не про Винду, а про Linux, и там это действительно проблема.
Проблема в том, что в Линухе нет единого стандарта централизованного хранения настроек прокси на уровне всей системы, там каждый дистрибутив/DE изобретает свой велосипед. Есть, конечно, env'ы, которые понимает большинство приложений, но понятно дело, что это уже не во власти прокси-клиента, особенно для уже запущенных приложений.
и VPN раздаю, через тот самый hiddify / v2rayNG
Почему VPN? Это именно что прокси
по крайней мере было, пока я с tcp vless не перешёл на grpc
Вот это что-то очень странное, потому что grpc транспорт испокон веков считается очень кривым и использовать его советуют только в совсем безвыходных случаях (там у вас тот же vless и тот же tcp, только оно все ещё в один слой инкапсулируется).
Вот это что-то очень странное, потому что grpc транспорт испокон веков считается очень кривым
Ох, у меня жизнь разделилась на "до grpc" и "после grpc". Пинг по hiddify упал в 2 раза, по v2rayNG - в 3. И сервера больше не отваливаются со странной ошибкой "io read write on closed pipe". Раньше стабильно раз в неделю что-то подкручивал и перезагружал, сейчас уже 2 недели как "ни единого разрыва".
Случайно Reality на сервере не используете? Если да, то меняйте домен маскировочного сервера, дело в нем (он либо медленный, либо далеко, либо просто вас не любит и периодически перестает вам отвечать). Либо вы натыкаетесь на какой-то системный лимит количества открытых подключений.
В вашем случае разница между голым VLESS и VLESS+gRPC - что в gRPC соединения мультиплексируются, то есть переиспользуется одно TCP-соединение до прокси для нескольких соединений от клиента к серверу назначения. Поэтому и "пинг" (меньше хендшейков), и в случае Reality меньше тычков в сторону маскировочного сервера. Но есть и недостаток - больше оверхед на саму передачу данных, и не работает XTLS-Vision.
В этом плане все сейчас гораздо проще стало
мне тут вообще показывали шайтан-машину:
клиент амнезии умеет так: пишешь айпишник своего сервера (например VPS)
вписываешь юзера и пароль для входа по ssh, выбираешь какой прокси/впн хочешь - и клиент сам топает куда надо, качает и ставит что надо. После этого остается только пользоваться. Я не смотрел, конечно что он там по настройкам на самой тачке делает (есть ли какая-то настройка фаера и т.д.)
Но чел так себе vless впилил на VPS'ке, вроде даже работает)
Амнезия - это хорошо, но есть ряд проблем, которые мешают беззаботно жить. Это те, с которыми я столкнулся в первый час. Исправлять их никто не собирается.
Просто кроссплатформенный клиент для proxy/VPN. Плюсы в сравнении с условным nekoray - включение и выключение в один клик через огромную кнопку на весь экран. Максимально "для домохозяек". Ну, или для тех, кто ценит свое время.
Минусы (субъективно) - Hiddify склонен капризничать и отваливаться по любому поводу. В отдельных случаях ещё и может порядочно так систему поломать. Ну и количество настроек, конечно, не идёт ни в какое сравнение с nekoray
Максимально "для домохозяек".
Как раз на днях решил попробовать VLESS + Hiddify.
Восторги мне непонятны и хз что там за домохозяйки такие, мне пришлось достаточно долго тыкаться и перебирать настройки, чтобы всё заработало. В отличии от всяких OpenVPN/WG клиентов, где реально всё в 1 клик работало
Имеется ввиду "максимально для домохозяек" среди VLESS клиентов, вроде всяких Nekobox/nekoray, с первоначальной настройкой надо немножко помучиться зато потом всё сводится к нажатию одной большой кнопки.
А OpenVPN и WG это вообще уже что-то из далёкого беззаботного прошлого, про них давно уже пора забыть.
у всех решений формата прокси главный минус — за пределами браузера не каждая прога это нормально переваривает
есть tun2socks и куча разных "проксифаеров"
Я не скажу за tun2socks, но Proxifier точно не умеет UDP.
В поиске "купить ключ vless" - это доступ к vless-серверу.
После ставите себе любой понравившийся vless-клиент (я Invisible Man Xray использую), в него этот ключ и пользуетесь.
Рисков пока не заметил. Допускаю, что где-нить на горизонте года роскомпозор научится и этот тип прокси блочить.
Оно, по идее умеет и как туннель работать, но на седьмой винде чот этот режим глючит.
Не понятно, чем такой танец с конями лучше обычного vpn? Тем более что полно уже готовых сборок на основе докера. Запустил контейнер, настроил скрипт к iptables и маршрутизацию, и всë. Или же упор именно на возможность логина браузером? Но так для этого вроде как тоже решения были. Интересовался этим еще со времен, когда организации начали заставлять закрывать публичный wifi авторизацией. Думаю с тех пор многое улучшилось. Тогда для настройки они были тяжеловаты, но сейчас то уж должны были подтянуться. Я про схему, когда клиент ломится через wifi в интернет браузером, а его редиректит на форму с авторизацией. Он проходит авторизацию и... А дальше как пожелает админ - кому то отрежут всë кроме детских сайтов, а кого-то через впн пустят. Да, многие из них включали сквид в себя, но настраивались проще. По факту в простейшем случае там просто прописывался маршрут кого куда пускать/не пускать. Точно также можно было прописать идти через vpn.
Не понятно, чем такой танец с конями лучше обычного vpn?
Именно поэтому:
настроил скрипт к iptables и маршрутизацию
Для кого-то, включая меня, возня с iptables и маршрутизацией - это совсем не "и все".
Кроме того, поддержка split tunneling у обычного VPN - это тот еще танец с конями. Та же amnezia под Windows работает кое-как. А гонять через VPN в другой стране весь трафик, включая игры и ОС - идея сомнительная.
Или же упор именно на возможность логина браузером? Но так для этого вроде как тоже решения были.
Упор на максимальную простоту для клиента. Особенно для того, который слова "iptables" и "маршрутизация" не слышал. Друзьям гораздо проще "продать" прокси с логином и паролем. Для некоторых уже даже nekoray - слишком сложно.
Что касается порталов с авторизацией, там вроде сейчас "модно" вообще мимо них ходить по ICMP-туннелям. Хотел настроить в свое время хохмы ради, но я публичными wifi не пользуюсь, так что затею забросил.
чем такой танец с конями лучше обычного vpn
Тем, что обычные VPN такие как IPSec, OpenVPN и Wireguard уже давно детектируются и блокируются, SoftEther и SSTP уязвимы к active probing, а OpenConnect имеет характерный TLS-фингерпринт клиента.
Тем, что можно ( и удобно! ) заворачивать в туннель только то, что нужно. Достаточно, чтоб софт умел работать с прокси. В частности можно прекрасно разруливать на какие сайты браузер будет ходить через прокси, а на какие напрямую.
Уточняю: в предложенной конфигурации, браузер всегда будет ходить через прокси, вопрос только через какой: первый (в РФ) или второй (зарубежный). Чтобы браузер ходил напрямую, ему нужно скармливать правила на стороне клиента, чего мы стараемся избежать.
Добавить правило *.ru в настройках прокси в браузере не так уж и сложно
Но конечно, с двумя прокси удобней. Хотя больше возни для админа.
Хотя больше возни для админа.
Это смотря насколько админ вовлечен в настройку прокси на клиентах. Если клиентов 10, и у них всех лапки, да еще они в разных частях города - тут не грех и над централизованным решением подумать по усерднее, времени все равно уйдет меньше.
Я через плагин FoxyProxy в Firefox добавлял те ресурсы, для которых нужен прокси. Он сразу и показывает какие запросы идут от браузера.
Вести у себя локально можно что угодно, пользоваться средствами обхода пока не запрещено. Запрещено предоставлять услуги.
В зависимости от задачи, если речь идет об малом количестве клиентов, то можно обойтись связкой внешний прокси+расширение для браузера. Либо, если клиентов много, поступить так, как сделал автор статьи и самостоятельно рулить списком на внутреннем прокси. И тут речь идет не только о блокировках РКН, но и об обходе блокировок адресов из РФ западными компаниями, intel, lenovo, canva и пр.
Позволяет гонять через себя весь трафик не интересуясь, что там уже заблокировано, а что еще нет.
Не весь, а HTTP. И то, если конкретная программа интересуется конфигурацией HTTP прокси на уровне системы, что далеко не всегда так.
HTTP и HTTPS, прокси работает на уровне браузера, а не системы. Для браузеров, которые не умеют прокси с авторизацией (это, как я понимаю, все браузеры из коробки) придется ставить дополнение. Это не сильно сложно...
Не работает только UDP, но он в браузере не сильно нужен.
прокси работает на уровне браузера, а не системы
Речь о том, что если программа - не браузер, а что-то другое, то она должна быть в курсе, где в системе взять текущие параметры прокси (в винде для этого ключ в реестре есть), и уметь с ним работать.
Зачем платить за 2 сервера (относительно мощных) и городить страшный огород, если можно проще добиться не просто того же, а даже лучше на том же техническом уровне без выхода датацентровского IP в РФ (привет капчи и даже блокировки от некоторых РФ сайтов) с помощью расширения Runet Censorship Bypass в свой любимый браузер, который скачает сразу все правила и завернёт в HTTPS-прокси только заблокированные сайты и dumbproxy сразу на зарубежный сервер (или в РФ датацентре без Роскомнадзора)?
Складывается впечатление, что автор решил просто позаморачиваться с настройкой GNU/Linux вместо «домашнего задания» по поиску простого и дешёвого решения абсолютно той же самой задачи.
без выхода датацентровского IP в РФ
Полагаю, что это зависит от сервера, но на серверах регру и аезы у меня не было никаких проблем с сайтами, окромя Reddit: он требует логиниться.
с помощью расширения Runet Censorship Bypass в свой любимый браузер, который скачает сразу все правила и завернёт в HTTPS-прокси только заблокированные сайты
Расширения - это хорошо, но если прокси все же захочется использовать за пределами браузера, то возникает стандартная проблема: через прокси гоняем либо все, либо ничего. Ну либо долго и упорно курим маршруты, если в вашей ОС они вообще предусмотрены и редактируются.
Складывается впечатление, что автор решил просто позаморачиваться с настройкой GNU/Linux вместо «домашнего задания» по поиску простого и дешёвого решения абсолютно той же самой задачи.
Автор действительно любит, скажем так, попердолиться. Любит сделать себе файлопомойку на одного человека, шарилку скриншотов, стример музыки и все такое прочее. Поэтому вместо того, чтобы разбираться, что там нынче из дешевых решений считается кошерным, а что нет, само-собой разумеется для него было сделать свое.
Я никогда не претендовал на единственно верное решение, просто поделился своим, которое работает уже года два безо всяких проблем. Чем больше зоопарк решений, кроме моего - тем лучше. Меньше шансов, что РКН займутся конкретно моим.
Полагаю, что это зависит от сервера, но на серверах регру и аезы у меня не было никаких проблем с сайтами
Нет, это зависит от «обезопашенности» российского сайта, на который вы в этой схеме пойдёте с нерезидентного (датацентрового) IP, а это справедливо считается необычным и нормальные живые люди с таких IP действительно не ходят.
Расширения - это хорошо, но если прокси все же захочется использовать за пределами браузера
То прокси у вас уже есть. Всё равно в HTTPS прокси абсолютно что угодно технически не завернуть, тут уж мало кому нужно. IPsec пока работает, маршрутизаторы не отменили.
Фактически это расширение регулярно скачивает готовый PAC-файл и даёт возможность добавлять свои адреса прокси и дополнительные проксируемые адреса. Качаете PAC, добавляете туда свой адрес прокси и вкорячиваете в систему средствами ОС, или скриптуете это. Наверное, существует что-нибудь, что может это делать за вас.
само-собой разумеется для него было сделать свое
Но развернуть свой dumbproxy — то же самое «своё». Списки заблокированных сайтов в этой статье — тот же самый источник, тот же самый разработчик, что и автор расширения и списков сайтов.
Для сборки, воспользуемся antizapret-pac-generator-light
Нет, это зависит от «обезопашенности» российского сайта, на который вы в этой схеме пойдёте с нерезидентного (датацентрового) IP, а это справедливо считается необычным и нормальные живые люди с таких IP действительно не ходят.
Как я уже написал, живу в РФ, регулярно хожу на Госуслуги и прочее, проблемы за два года были только с Reddit. И то, когда я случайно вышел из учетки.
Фактически это расширение регулярно скачивает готовый PAC-файл и даёт возможность добавлять свои адреса прокси и дополнительные проксируемые адреса. Качаете PAC, добавляете туда свой адрес прокси и вкорячиваете в систему средствами ОС, или скриптуете это.
Ну, в предложенном мной варианте это делает squid и antizapret-pac-generator-light. Предлагаемое вами расширение позволяет обойтись без первого прокси, но, во-первых, к таким подключениям в теории больше вопросов, чем к коннектам между датацентрами. А во-вторых, настраивать PAC-файл, маршруты и все такое прочее придется на каждом клиенте в зависимости от назначения. Где-то в переменную прописать, где-то в браузер вбить. Мой вариант просто скармливается клиенту без сопутствующих костылей.
Архитектурно так и есть. Либо локальное управление конечным юзером, либо корпоративный squid, который конечные юзеры потрогать не могут.
Настройка расширения минимальна — вам стоит взглянуть.
К этому я бы добавил бесплатный домен третьего уровня и nat-vps, и вдруг решение превращается в скачивание расширения, вбив туда своего адреса proxy $5 в год и эта штука работает вообще без сбоев и управления.
IPsec пока работает
Уже не везде и не всегда, слава РКН с его ТСПУ
У меня всё проще - банальный SSH Socks на зарубежный сервер и расширение FoxyProxy в браузере. Туда я добавляю интересующие меня сайты в ручном режиме.
Туда я добавляю интересующие меня сайты в ручном режиме.
Да, с этого я и начинал, потом поиграл в Factorio и понял, что автоматизация - наше все.
а насколько просто добавлять домены вручную? Может быть актуально, например, на случай блокировок по айпи или в случае гео-блокировки по инициативе самого ресурса.
а насколько просто добавлять домены вручную?
Их нужно дописать (по одному на строчку) в файл /opt/antizapret-pac-generator-light/config/include-hosts-custom.txt
на сервере, который собирает список, и запустить сборку списка вручную (или подождать полуночи, пока процесс запустится из крона).
Для Ютуба у меня под десяток правил, кроме самого Ютуба там периодически идут запросы к googlevideo.com/
play.google.com/
И подобные.
Пролистал статью по диагонали, зацепился глаз за:
1) Уберите бездумную портянку sysctl,
совершенно непонятно зачем там, вроде же docker не используется
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
2) Squid по умолчанию отправляет конечному серверу адрес клиента, нежданчик.
https://www.squid-cache.org/Doc/config/forwarded_for/
нужно выключить
3) генерить ssh-ключи на сервере, чтобы их скопировать потом клиенту. Не надо так. Private ключ клиента должен генерить сам клиент, и отправлять серверу только свой публичный. У вас здесь все с ног на голову. Еще раз, не надо так. И файл с ssh private key должен быть под паролем.
Лучше привыкнуть сразу делать правильно, чем потом внезапно обнаружить, что какой-то случайный троян обнаружил текстовичок с ssh-ключем, и прошелся по всем сохраненным серверам.
4) Кеши в squid проще выключить совсем, не нужны они сегодня, и там.
опция cache_dir убрать совсем.
Занятно, что РКН мытьем и катаньем повышает грамотность населения в плане работы интернета и проксей. С другой стороны это порождает множество статей, в которых совершенно случайно могут вставить компрометирующие сервисы команды.
Уберите бездумную портянку sysctl,
Да, насчет sysctl у меня самого вопросы. Я, наверное, убирать ее не буду, а просто помечу, что это портянка экспериментальная. Я ее в целом и так задвинул подальше.
Squid по умолчанию отправляет конечному серверу адрес клиента, нежданчик.
Не могу сказать, что я скрываю адрес клиента. Мне, в целом, все равно. Вообще, трафик клиентов я стараюсь не трогать. Но сейчас раскуриваю, какие варианты есть замаскировать squid от active probing, и посмотрю заодно насчет вашей директивы. Наверное, можно и добавить.
Лучше привыкнуть сразу делать правильно, чем потом внезапно обнаружить, что какой-то случайный троян обнаружил текстовичок с ssh-ключем, и прошелся по всем сохраненным серверам.
Потихоньку подбираемся к солонке в столовой. ИМХО, если троян прошелся по вашей системе, то root доступ к несчастному прокси - это одна из ваших наименьших проблем.
опция cache_dir убрать совсем.
В статье упоминается. Как и упоминается умопомрачительная эффективность кеша в целых 0%. Я оставил. :)
Вы сильно недооцениваете существование троянов, которые просто сидят и ждут годами появления в системе всяких текстовых файлов с выгрузками 1С и ssh-ключами.
3proxy пробовали?
сколько с 0 вы потратили времени примерно что бы разобраться с конфигами кальмара?
3proxy пробовали?
Пробовал, крутится на всех серверах, но как тупой прокси. Тупо пропускает все через себя, если надо.
сколько с 0 вы потратили времени примерно что бы разобраться с конфигами кальмара?
calamaris или squid?
На calamaris я почти не тратил времени, а запряг для этих целей ChatGPT (который его и предложил для мониторинга).
Если squid, то я не помню. Дело было 2 или 3 года назад. День?
3proxy умеет работать с https ? Уточню, не пробрасывать https трафик клиента через метод connect через plain-http, а именно шифровать канал между клиентом и прокси ?
Это расшифровывать.
https://github.com/3proxy/3proxy/blob/master/doc/html/plugins/SSLPlugin.ru.html
и для шифрования трафика прокси-сервера
К слову, через обычный SOCKS-proxy запущенный за бугром на произвольном порту facebook иногда не открывается. Видимо TLS-сертификаты проверяются и на рандомных портах, кроме стандартных 443.
Какая связь между проверкой сертификатов, произвольным портом и неоткрытием фейсбука через прокси?
Фейсбук или гугл замедляли не через полную блокировку по IP-адресам, а через проверку сертификатов при установке соединений. При использовании нешифрованного socks-прокси видно на какой сервер идет клиент, и этот запрос точно так же замедлялся, как при прямом подключении без проксей и VPN.
Фейсбук или гугл замедляли не через полную блокировку по IP-адресам, а через проверку сертификатов при установке соединений
Неа. Сертификат сервера там не проверяется, проверяется только поле SNI из запроса. Достаточно запрещённое строки в SNI от клиента, сертификат сервера уже не играет роли.
При использовании нешифрованного socks-прокси видно на какой сервер идет клиент, и этот запрос точно так же замедлялся, как при прямом подключении без проксей и VPN.
А вот это что-то очень новенькое, потому что раньше РКН полностью игнорировал даже простые не шифрованные прокси (да и до сих пор игнорирует у большинства пользователей), вы первый, кто сообщил об обратном.
>проверяется только поле SNI из запроса
да, более правильный термин
>потому что раньше РКН полностью игнорировал даже простые не шифрованные прокси
Сам был сильно удивлен. В прошлом месяце не работало, сейчас простая прокся работает. Скорее всего, мне просто повезло попасть в какой-то тестовый пул провайдеров, и/или моя прокся была в отслеживаемом ДЦ.
Практика показывает, что вы не интересны РНК, как и весь ваш хранящийся семилетний траф ровно до той поры, пока вы не нарушаете закон. Как только вы начинаете валять дурака, безрассудно веря в свою безнаказанность, представляя что коварный майор замучается разгребать https шлак и, едва ли, не в ручную, то ваши изыски в области запрета на дополнительную шифрацию трафика (а за какой такой целью?) идёт логичным и отягчающим обоснованием (вы зачем наточили нож перед ограблением?). И итого: плюс статья. Специалисту одноцветно чем вы шифруетесь - любой вами выбранный алгоритм обратим. Специалист умеет в теорию информации и выступает в роли инспектора, как в ГИБДД - важен факт, не важно как. Это важно знать и помнить любому уважающему себя инженеру.
До этого так же уверенно писали "Помните! Специалист может увидеть из кинескопа, чем вы дома занимаетесь!"
Самой главной уязвимостью в такой системе является возможность придти к автору домой и изъять историю браузера с компа. А поскольку для этого совершенно не требуется, чтобы у автора была эта самая история, браузер или комп, то вот тут и проходит черта проблемы, которая технологически не решается.
"Амнезия" ставится за пару кликов...
Про амнезию уже писал дважды, мне не подходит.
Я бы номинировал на премию "наихудший рабочий способ", если для личного использования. Сервера 2, весь трафик через прокси, на юзерском компе надо надстраивать что-то в каких-то расширениях, вася-сборка сквида. Наверное я просто нелюблю прокси. Но вообще имеет место быть в зависимости от решаемой проблемы. Да, мне больше всего не нравится даже не то, что на компе пользователя надо чё-то настраивать в расширениях, а то, что трафик, который по сути проксировать не нужно всё равно проксируется (хоть и через сервер в рф).
Без впн... я бы предложил через 1 сервер зарубежом с nginx в режиме стрим и bind с генерированием конфигов через скрипты (ну либо вообще фэйкрут). Чтобы работала простая подмена днс на заблокированных ресурсах, а не на заблокированных шло, как шло. На стороне пользователя просто вбить днс сервер (ну или впн до сервера с маршрутом только на 1 этот адрес, а не 0.0.0.0/0).
У вас просто задачи другие.
Вы попробуйте про маршруты и DNS объяснить, например, пенсионерке на другом конце города по телефону.
Или на работе, на MacOS прописать левый DNS (я проверил - нельзя), когда даже удаление некоторых файлов требует права админа, которые вам никто давать не будет.
Прокси, в отличие от VPN и прочих SSH туннелей требует минимально возможные права и работает даже на кофеварках (слегка утрирую). Да, в современных браузерах почему-то не подразумевается использование прокси с аутентификацией. Впрочем, я видел несколько костылей для браузеров, когда прокси можно использовать как флаг при старте или включить поля для логин:пароль в конфигах браузера. Все эти костыли проще заменить банальным расширением, прав на него тоже никаких не нужно. И на MacOS, и на Linux, и на Windows, и на Android - просто устанавливаешь Firefox и просто устанавливаешь FoxyProxy. Все работает. Само-собой, прокси можно прикрутить к почти (?) любому браузеру. Прокси штука такая, что под капотом она совместима с чем угодно и не требует подпирать себя костылями. В контексте браузера весь затык исключительно в логине и пароле.
Кстати, если кому-то с руки протестировать, работает ли в Linux на Chrome и Firefox прокси с аутентификацией как переменная HTTPS_PROXY - было бы интересно, а то у меня все линуксы без гуев.
Ну про маршруты объяснять то никому не надо, это всё должно делаться на стороне сервера (в случае с впн). А вбить другие днс явно не сложней, чем ставить расширение на браузер и вбивать прокси. Другое дело, что при блокировке по sni будут проблемы (как ниже отметили) без заворачивания в впн.
Да в том-то и дело, что в случае, если не можем прописать прокси на всю систему (через переменные пути на линуксе раньше точно проблем не было), то имеем проблемы. Если кроме браузера у тебя с десяток приложений, половина из которых не поддерживает прокси, а остальная половина требует отдельной настройки... Это просто неудобно. Ну да, наверное вариант, если у вас нет возможности настроить впн. Но если возможность есть - я бы однозначно предпочел впн.
Ну подождите минутку... А какие приложения вообще нуждаются в впн и прокси, кроме браузера? Я не припомню ни одного, кроме Discord.
Без впн... я бы предложил через 1 сервер зарубежом с nginx в режиме стрим и bind с генерированием конфигов через скрипты (ну либо вообще фэйкрут)
И как ваша схема поможет против фильтрации запрещенных ресурсов по SNI? Она сработает только против блокировок по IP, а таких сейчас уже не так уж и много осталось.
Скажите, пожалуйста, а чем плох обычный SOCKS5 dante? Установил на VPS, в FoxyProxy закинул учетные данные - работает.
Ничем не плох, но если у вас один прокси, то вы либо весь трафик гоните через него (как минимум до сайтов в РФ будете ходить дольше, плюс у них могут быть вопросы, почему вы в Германии какой-нибудь), либо долго и мучительно настраиваете правила. Ну, можно конечно использовать готовые, как предлагали выше - но это на каждом отдельном устройстве надо городить свой огород.
В моей схеме весь огород от конечного пользователя (и устройства) скрыт, и кроме адреса прокси с логином и паролем ему ничего не нужно. Тупой прокси без правил и дополнений можно прикрутить к чему угодно. Особенно если IP статический и доступ по нему.
Обойдемся без VPN: связка из 2 прокси для хождения в Интернет