Comments 100
Я так смотрю, какие-то три дурацкие буквы вызвали такой невиданный рост внедрений и проксирования, и ipv6, плюс более глубокого понимания протоколов, что парням этим нужно не только за неосиливание недовыполнение «заданий Партии и Правительства» цацку и повышение давать, и но премию по линии министерства народного образования!
После беглой проверки возможностей приложения sslh мне показалось, что «завести» не удастся, но меня очень заинтересовало это приложение, и, как оказалось, скрестить ужа с ежом все-таки можно.
В итоге весь неопознанный трафик будет идти в телегу.
да, и пусть, там он будет дропатся если ключ не подходит, опционально можно еще добавить ключ --http и указать порт apache --> большинство ботов и сканеров пойдут в Apache
А добавить openvpn в этот конфиг можно? Или его трафик тоже попадает под anyprot и возникает конфликт настроек? И ещё, есть ли в ней возможность непонятный трафик (anyprot) с одного хоста раскидывать по round-robin принципу (или типа сразу всем, а потом если хоть один не дропнул, оставлять соединение)? Например, за sslh спрятались openvpn и mtproto-proxy, пришел запрос непонятной сигнатуры на 443 порт. Можно ли дублировать syn/ack handshake, входящие пакеты тоже дублировать, а исходящие, если пока ещё RST не прилетел, откладывать в очередь на отправку, и если одно из приложений послало по соединению RST, его пакеты не посылать, а посылать только от того, которое RST не послало, ну и запомнить, которое это, чтобы потом не мучить другие приложения трафиком не для них?
Можно! добавляете ключ --openvpn с требуемым портом
PS вот все протоколы которые распознает приложение: (Добавил в пост)
[--ssh ]
[--openvpn ]
[--tinc ]
[--xmpp ]
[--http ]
[--ssl ]
[--tls ]
[--anyprot ]
Расширенного варианта настроек я не нашел, roud-robin можно попробовать реализовать через IPtables или сделать доработку предложив PR на github
PS вот все протоколы которые распознает приложение: (Добавил в пост)
[--ssh ]
[--openvpn ]
[--tinc ]
[--xmpp ]
[--http ]
[--ssl ]
[--tls ]
[--anyprot ]
Расширенного варианта настроек я не нашел, roud-robin можно попробовать реализовать через IPtables или сделать доработку предложив PR на github
а стабильный ресурсозатратный вариант насколько ресурсозатратный? не проводили сравнение?
Из документации с официального репозитория:
The Makefile produces two different executables: sslh-fork and sslh-select:
sslh-fork forks a new process for each incoming connection. It is well-tested and very reliable, but incurs the overhead of many processes.
If you are going to use sslh for a «small» setup (less than a dozen ssh connections and a low-traffic https server) then sslh-fork is probably more suited for you.
sslh-select uses only one thread, which monitors all connections at once. It is more recent and less tested, but only incurs a 16 byte overhead per connection. Also, if it stops, you'll lose all connections, which means you can't upgrade it remotely.
If you are going to use sslh on a «medium» setup (a few thousand ssh connections, and another few thousand ssl connections), sslh-select will be better.
Странно, зачем форкать ради поддержки соединения. Я, когда был молодой и глупый, форкал свой sqlserver, потому что не умел работать с больше чем одним источником запросов в коде, но это когда было… Сейчас я бы просто сокет передавал. (Тогда, кстати, распоряжаться трафиком для многих назначений anyprot теоретически можно — согласно этой информации, sslh работает как tcp-прокси, и соединения терминирует на себе вместо маршрутизации пакетов. Это и хорошо и плохо, но это фишка архитектуры, не более)
В общем, не густо. Но все ровно прикольно. Мученики флешей и сильверлайтов в свое время оценили бы. :)
почему не густо? чего не хватает?
Ну, отдельный процесс на каждое соединение это конечно жесть, но и запихивать все в один поток не лучшая идея. Даже если полностью не использовать синхронное чтение/запись этот поток станет узким местом. На ssh может и не заметно, но если там будут разные протоколы с разной степенью загруженности и реалтаймовости, то хорошего будет мало.
Нужен вариант с количеством потоков пропорциональным количеству ядер. Это было бы оптимально, как мне кажется.
Нужен вариант с количеством потоков пропорциональным количеству ядер. Это было бы оптимально, как мне кажется.
Многопоточность здесь не нужна, т.к. нагрузки на CPU здесь нет. Доказано nginx.
Просто вместо `select` нужно использовать `epoll`, и тогда хоть 10к соединений в одном потоке можно гонять.
Просто вместо `select` нужно использовать `epoll`, и тогда хоть 10к соединений в одном потоке можно гонять.
Вот мне однажды Nginx и не подошел из-за того что грузил процессор на 100%. Представьте что вам нужно передавать что-то реалтаймовое в рамках одного соединения. Т.е. есть данные, их на самом деле очень мало, они идут, например, от сервера к клиенту, с паузами, но должны доставляться моментально. Чтобы пропустить такой поток через Nginx нужно отключить ему буферизацию. И привет… А COMET реализован не везде, да и привносит свои задержки.
Впрочем да, вы правы. Мало ли на свете извращенцев. :)
Впрочем да, вы правы. Мало ли на свете извращенцев. :)
100% — это был именно user time или user + system? Если больше system, то претензии уже не к nginx.
Но вообще, это не является типичным сценарием для пользователя sslh.
Но вообще, это не является типичным сценарием для пользователя sslh.
Действительно. Nginx — это же святое! Как я мог?..
Но даже его воркер можно распараллелить по нескольким процессам и потокам.
Но даже его воркер можно распараллелить по нескольким процессам и потокам.
Да, можно, но конкретно в этом случае смысла не вижу. Ведь задача воркера — это принять пакет из одного сокета и тут же его засунуть в другой сокет без всякой обработки (кроме определения типа протокола в самом начале).
Конечно, если вам нужно обрабатывать хотя быть 100 новых соединений в секунду, а скорость передачи данных превышает 10 гбит/сек, тогда да, нужно заморачиваться с многопоточностью. В противном случае разницы никакой не будет, за исключением того, что однопоточный код проще и меньше подвержен ошибкам.
Конечно, если вам нужно обрабатывать хотя быть 100 новых соединений в секунду, а скорость передачи данных превышает 10 гбит/сек, тогда да, нужно заморачиваться с многопоточностью. В противном случае разницы никакой не будет, за исключением того, что однопоточный код проще и меньше подвержен ошибкам.
Если кому-то не понравится приведённое в статье решение, то можно использовать HAProxy и разруливать всё доменами. Например, считать, что то, что идёт на ovpn.home.home должно быть спроксировано OpenVPN серверу.
а вы уверены, что тот же openvpn/telegram в заголовках передает домен?
Я делал настройку на основе разбора SNI. У меня за 443 портом жили web-сервер и SoftetherVPN(Который также работает как OpenVPN). OpenVPN клиенты нормально подключались.
Опять же, я не уверен, что все сервисы передают SNI а не делают nsslokup на стороне клиента и уже по IP всё шлют
У меня через SNI ~ 50 доменов разруливались.
OpenVPN до сих пор не умеет в SNI. Возможно у вас на него fallback правило было (ну т.е. нет правила для конкретного домена — перенаправляем на OpenVPN). В составе Softether у меня по SNI корректно работают только сам Softether и SSTP.
А HAProxy в MTProto-proxy прозрачно будет кидать, или телега будет думать, что всё на одном IP сидят?
А если протокол host не умеет?
использовать технологию DPI во благо
т.е. получается и «взрослый» DPI на строне провайдера это может делать с тем же успехом и блокировать весь канал по этому признаку… верно?
Теоретически — да, насчет протокола telegram proxy — не понятно.
Ну, и да и нет. Ваш сервер знает что это за трафик и для чего он, а DPI провайдера — нет. Что касается анализа протоколов, те, что не являются https можно обернуть в stunnel, после чего мультиплексировать на стороне сервера по sni через haproxy или даже nginx (только сборку надо брать официальную, там нужные модули собраны).
В принципе haproxy вообще может заменить sshl (который неизвестно как нагрузку держит), только конфиг для него сложнее написать.
В принципе haproxy вообще может заменить sshl (который неизвестно как нагрузку держит), только конфиг для него сложнее написать.
Угу. И в mtproto-proxy всё будет влетать с одного IP, да?
On Linux and FreeBSD you can use the --transparent option to request transparent proxying. This means services behind sslh (Apache, sshd and so on) will see the external IP and ports as if the external world connected directly to them. This simplifies IP-based access control (or makes it possible at all).
DPI провайдера может резать соединения и по косвенным признакам, например, по паттернам передачи данных по соединению. Кажется, так делают в Китае.
Я очень хочу посмотреть на такие DPI в деле. И на законодательную базу к ним.
Приезжайте в Китай и смотрите. Со стороны это выглядит так: поднимаешь VPN до сервера — всё работает. Первые пару мегабайт всё хорошо, а дальше начинается лагодром вплоть до полной невозможности использования VPN, причём остальной трафик не режется.
Во время прошлой поездки в Китай решал проблему, используя международную дата-симку одного из рекламировавшихся здесь операторов — она определялась как гонконгская, и файрвол на неё не распространялся.
Во время прошлой поездки в Китай решал проблему, используя международную дата-симку одного из рекламировавшихся здесь операторов — она определялась как гонконгская, и файрвол на неё не распространялся.
А что с законодательной базой может быть не так, если она предусматривает блокировки в принципе? Расшифровки не происходит, просто более глубокий анализ пакетов, чем это делает «тупой» роутер, умеющий блокировать по IP типа iptables.
UFO just landed and posted this here
Ну так речь о том, чтобы отличить обычное HTTPS-соединение от соединения с Telegram-сервером over VPN, а не с HTTPS over VPN. Размер и частота пакетов в этом случае будет отличаться.
Я бы это реализовал так:
При активности на соединении по 443 порту более 15 минут и нехарактерном паттерне пакетов соединение помечается как подозрительное.
Как только соединение определяется как подозрительное, оборудование провайдера переходит к активному анализу — подключается к 443 порту и пытается понять, если ли там чо (OpenVPN, SSH, HTTPS и т.д.)
- Если нашлось что-нибудь интересное, кроме HTTPS, то тупо блочим по IP, иначе думаем дальше.
Вариант противодействия есть — это VPN over HTTPS. При запросе определённой секретной страницы происходит переключение на VPN протокол.
Вы сейчас описали как работает Китайских фаервол в режиме «Опережающего подключения»
Но есть и хорошая новость, в случае с Telegram Proxy — без знания ключа ничего не будет работать, openssl подключится без какого либо продолжения т.е сервис раскрыт не будет
Да, может, но пока не делает так. Обход блокировок — это игра в кошки-мышки. Провайдер блокирует — люди находят новые способы для обхода.
Если мультиплексировать трафик через openvpn share port, то в логах веб сервера адресом источника будет локалхост. У sslh такое же поведение?
Я новичок в стеке vpn/proxy, поэтому возможно немного глупый вопрос. Если есть vpn сервер расположенный в цивилизованной стране не блокирующей трафик и сервер арендованный на деньги работодателя расположенный на мощностях ростелекома, то нужен ли SSLH чтобы развернуть реверс прокси и стучаться в удаленный сайт через впн просто подключаясь к Ростелекомовскому серверу.
Можно всё, цель непонятна.
Цель в том, чтобы без настроек на стороне клиента заходить на сервер, который уже будет поднимать тунели/проксировать до сайта. Хочется настроить один раз и использовать на любой машине.
вот это на самом деле уже не понятно:
куда заходить? как? чем?
Если вы сможете по лучше объяснить цель, я смогу помочь с решением
без настроек на стороне клиента заходить на сервер
куда заходить? как? чем?
Если вы сможете по лучше объяснить цель, я смогу помочь с решением
Заранеее спасибо за ответ.
Есть виртуальный сервер с публичным ip (centos, nginx) расположеный в России и vpn сервер расположенный за границей. Хочеться как-то настроить эту связку, так чтобы заходить на ip первого сервера, а уже сервер через тунель стучался к конкретному сайту (rutracker.org например). Сейчас же приходиться на каждом клиенте поднимать vpn соеденение
Есть виртуальный сервер с публичным ip (centos, nginx) расположеный в России и vpn сервер расположенный за границей. Хочеться как-то настроить эту связку, так чтобы заходить на ip первого сервера, а уже сервер через тунель стучался к конкретному сайту (rutracker.org например). Сейчас же приходиться на каждом клиенте поднимать vpn соеденение
гм, два nginx transparent proxy, российский смотрит на зарубежный, зарубежный смотрит на сайты, домены разместить в формате rutracker.ваш_домен.com, при обращении он должен отправлять запрос к истинному сайту. в случае с Apache, это настраивается через proxypass в две строки.
www.digitalocean.com/community/tutorials/how-to-use-apache-http-server-as-reverse-proxy-using-mod_proxy-extension
PS А зачем в схеме вообще российский сервер?, он не несет никакой смысловой нагрузки
ProxyPass / http://0.0.0.0:8080/
ProxyPassReverse / http://0.0.0.0:8080/
www.digitalocean.com/community/tutorials/how-to-use-apache-http-server-as-reverse-proxy-using-mod_proxy-extension
PS А зачем в схеме вообще российский сервер?, он не несет никакой смысловой нагрузки
UFO just landed and posted this here
А зачем в схеме вообще российский сервер
Просто что Российский сервер, что акаунт VPN достались по наследству и совершенно бесплатны. Поэтому и хотелось обойтись чисто ими.
я намекаю, что он лишнее звено в пищевой цепочке и его можно исключить.
Это очевидно, что если есть заграничный сервер то прокси можно настраивать прямо на заграничном. Но в то-то и дело, что есть только Российский сервер и акаунт на vpn сервере. К самому зарубежному серваку доступа нет. Вот и думал, можно ли обойтись без полноценного сервера зарубежом или стоит не парить себе голову взять за 5$/месяц от DO.
Самое важное, что эта штука умеет не только в localhost.
VPN-сервер может находиться где угодно, а сам sslh может туда ходить по ipv6.
VPN-сервер может находиться где угодно, а сам sslh может туда ходить по ipv6.
К теме докера. Вы написали что у вас не получилось объединить с другими службами, я так понимаю у вас возникли проблемы с сетевыми интерфейсами? Если так, то не пробовали sshl запускать в контейнере с параметром --net host? Тогда по сути он будет работать в контейнере но в сетевом окружении хостовой машины. Или проблема была в другом?
Проблема была в том, что при установке он выдаёт меня выбора в GUI какой тип использовать, докер естественно не может выбрать нужный.
а у него нет варианта работы в не-интерактивном виде без dialog? Может проще собрать из исходников внутри контейнера? И чтобы занимало меньше места попробовать использовать build step'ы… Надо будет покопаться)
К сожалению я не нашел, если у вас получится — я думаю ваш докер файл стоило бы приложить в основной репозиторий проекта
Ну контейнер я сделал, собрал. Вроде всё ок.
Лежит на Docker HUB
Буду рад если кто-нибудь сможет протестировать, у меня пока возможности отладить до конца нет. За любой фидбек в личку буду благодарен :)
Если всё нормально работает, то можно и в пост upd добавить будет :)
Лежит на Docker HUB
Буду рад если кто-нибудь сможет протестировать, у меня пока возможности отладить до конца нет. За любой фидбек в личку буду благодарен :)
Если всё нормально работает, то можно и в пост upd добавить будет :)
upd.
Протестировал. Всё работает замечательно. Вот например с телеграмом. Так что можете пользоваться. Пример использования есть на докер хабе. :)
sslh-select v1.19c-6-g552723c-dirty started
anyprot:connection from ***-***-***.***:57994 to sslh:7443 forwarded from sslh:54486 to 172.17.0.2:https
anyprot:connection from ***-***-***.***:57995 to sslh:7443 forwarded from sslh:54496 to 172.17.0.2:https
anyprot:connection from ***-***-***.***:45175 to sslh:7443 forwarded from sslh:54516 to 172.17.0.2:https
anyprot:connection from ***-***-***.***:45177 to sslh:7443 forwarded from sslh:54518 to 172.17.0.2:https
anyprot:connection from ***-***-***.***:45182 to sslh:7443 forwarded from sslh:54520 to 172.17.0.2:https
anyprot:connection from ***-***-***.***:45190 to sslh:7443 forwarded from sslh:54522 to 172.17.0.2:https
anyprot:connection from ***-***-***.***:45549 to sslh:7443 forwarded from sslh:54528 to 172.17.0.2:https
anyprot:connection from ***-***-***.***:45550 to sslh:7443 forwarded from sslh:54530 to 172.17.0.2:https
anyprot:connection from ***-***-***.***:45551 to sslh:7443 forwarded from sslh:54532 to 172.17.0.2:https
из коробки не завелось с ошибкой:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/docker-entrypoint.sh\": permission denied": unknown.
Я сейчас обновляю контейнер, переделываю под разные операционки как раз. Это на тэге latest?
исправлено и перенастроено.
плюс сделал по умолчанию все таки дебиан, так как там есть libwrap, и это важный момент. Добавил на дохабе описание отличия одного от другого и зачем либврап нужен в данном случае :)
Проверил сейчас, все работает
плюс сделал по умолчанию все таки дебиан, так как там есть libwrap, и это важный момент. Добавил на дохабе описание отличия одного от другого и зачем либврап нужен в данном случае :)
Проверил сейчас, все работает
Что если IP-адрес сервера окажется заблокирован, и/или провайдер начнет блокировать по DPI трафик, используемого на 443 порту сервиса (т.к. он отличается от SSL)? Вероятно, лучше на 443/80 вешать обфусцированный мост Tor.
shifttstas, а что имели ввиду под фразой «Что позволяет нам использовать технологию DPI во благо.»? Я танкист и новичок.
И кстати ещё нубский вопрос. Нахожусь в Китае, тут мне многие говорят примерно так: «у китайцев DPI, поэтому никакие VPN и прочие анонимайзеры попку не спасут.». Скажите, правы ли они? И если правы, то что делать?
Спасибо.
P.S. Ещё раз, чукча нуб, но когда находился в РФ, то применял простую схему: арендовал на scaleway самый дешевы сервер, развернул там openvpn (через одну команду: github.com/Nyr/openvpn-install ), а дома подключался через аппаратур к нему. И всё. Боюсь подобные решения с китайцами и правда ненадолго.
И кстати ещё нубский вопрос. Нахожусь в Китае, тут мне многие говорят примерно так: «у китайцев DPI, поэтому никакие VPN и прочие анонимайзеры попку не спасут.». Скажите, правы ли они? И если правы, то что делать?
Спасибо.
P.S. Ещё раз, чукча нуб, но когда находился в РФ, то применял простую схему: арендовал на scaleway самый дешевы сервер, развернул там openvpn (через одну команду: github.com/Nyr/openvpn-install ), а дома подключался через аппаратур к нему. И всё. Боюсь подобные решения с китайцами и правда ненадолго.
На Scaleway все ещё проще — там очень удобный готовый образ с OpenVPN, удобнее чем этот скрипт.
Это ж какой? Хотя не суть, речь не об этом.
Вот этот: www.scaleway.com/docs/how-to-use-the-openvpn-instant-apps
Больше всего меня вот это радует:
Больше всего меня вот это радует:
You can download the configuration file from your server either via SSH or by starting a HTTP server that provides an URL to download the files directly on your computer: scw-ovpn serve CLIENTNAMEФайл настроек просто скачивается через одноразовый веб-сервер. Намного удобнее, чем sftp.
Вопрос от новичков — не пробовал никто с Algo VPN подружить?
Есть варианты?
Обратите внимание на опцию anyprot — именно там будет жить наш Telegram Proxy, другими словами, если трафик не подошел ни под какой тип — отправить туда.
Значит, раз sslh не считает трафик MTProto Proxy за HTTPS, то и DPI провайдера его легко заблокирует, если потребуется.
Есть ли где-нибудь свежие сборки под Windows? На оф. сайте после 1.17, от 2015 года, ничего нет.
Sign up to leave a comment.
SSLH: Прячем SSH/HTTPS/OpenVPN/Telegram за единым портом 443