Ads
Comments 99
+13
Я так смотрю, какие-то три дурацкие буквы вызвали такой невиданный рост внедрений и проксирования, и ipv6, плюс более глубокого понимания протоколов, что парням этим нужно не только за неосиливание недовыполнение «заданий Партии и Правительства» цацку и повышение давать, и но премию по линии министерства народного образования!
-8

После беглой проверки возможностей приложения sslh мне показалось, что «завести» не удастся, но меня очень заинтересовало это приложение, и, как оказалось, скрестить ужа с ежом все-таки можно.

+3
Посмотрел, писал поздно вечером, сейчас еще раз перечитываю и в упор пока не могу понять в чем конкретно проблема =)

PS Лучше в личку о таком писать.
+1
Не вижу проблем в построении этой фразы. Что в ней не так, по вашему мнению?
0
Были предложения по добавлению «И», я его добавил, так правда чуть по лучше.
0
да, и пусть, там он будет дропатся если ключ не подходит, опционально можно еще добавить ключ --http и указать порт apache --> большинство ботов и сканеров пойдут в Apache
+1
А добавить openvpn в этот конфиг можно? Или его трафик тоже попадает под anyprot и возникает конфликт настроек? И ещё, есть ли в ней возможность непонятный трафик (anyprot) с одного хоста раскидывать по round-robin принципу (или типа сразу всем, а потом если хоть один не дропнул, оставлять соединение)? Например, за sslh спрятались openvpn и mtproto-proxy, пришел запрос непонятной сигнатуры на 443 порт. Можно ли дублировать syn/ack handshake, входящие пакеты тоже дублировать, а исходящие, если пока ещё RST не прилетел, откладывать в очередь на отправку, и если одно из приложений послало по соединению RST, его пакеты не посылать, а посылать только от того, которое RST не послало, ну и запомнить, которое это, чтобы потом не мучить другие приложения трафиком не для них?
+1
Можно! добавляете ключ --openvpn с требуемым портом
PS вот все протоколы которые распознает приложение: (Добавил в пост)
[--ssh ]
[--openvpn ]
[--tinc ]
[--xmpp ]
[--http ]
[--ssl ]
[--tls ]
[--anyprot ]

Расширенного варианта настроек я не нашел, roud-robin можно попробовать реализовать через IPtables или сделать доработку предложив PR на github
0
Подождите-подождите, а проброс OpenVPN работает и с tls-auth, и с tls-crypt?
0
Насколько я помню, OpenVPN сам умеет «мультиплексировать» ssl. Так что его можно поставить впереди, а все остальное разруливать уже через sslh.
0
Автор sslh пишет в документации:
OpenVPN clients connecting to OpenVPN running with -port-share reportedly take more than one second between the time the TCP connection is established and the time they send the first data packet.

и поэтому советует ставить на фронт именно sslh.
-1
Ну, в любом случае, если вдруг с sslh впереди не заработает, то 1 секунда на старте клиента — не сильно большая плата.
0
Тогда еще удлинится цепочка
OpenVpn --> sslh --> SSH
Зачем если первый элемент можно поставить ниже убрав целый сетевой hop
0
а стабильный ресурсозатратный вариант насколько ресурсозатратный? не проводили сравнение?
0
Из документации с официального репозитория:

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.
0
Странно, зачем форкать ради поддержки соединения. Я, когда был молодой и глупый, форкал свой sqlserver, потому что не умел работать с больше чем одним источником запросов в коде, но это когда было… Сейчас я бы просто сокет передавал. (Тогда, кстати, распоряжаться трафиком для многих назначений anyprot теоретически можно — согласно этой информации, sslh работает как tcp-прокси, и соединения терминирует на себе вместо маршрутизации пакетов. Это и хорошо и плохо, но это фишка архитектуры, не более)
0
В общем, не густо. Но все ровно прикольно. Мученики флешей и сильверлайтов в свое время оценили бы. :)
0
Ну, отдельный процесс на каждое соединение это конечно жесть, но и запихивать все в один поток не лучшая идея. Даже если полностью не использовать синхронное чтение/запись этот поток станет узким местом. На ssh может и не заметно, но если там будут разные протоколы с разной степенью загруженности и реалтаймовости, то хорошего будет мало.
Нужен вариант с количеством потоков пропорциональным количеству ядер. Это было бы оптимально, как мне кажется.
0
Многопоточность здесь не нужна, т.к. нагрузки на CPU здесь нет. Доказано nginx.
Просто вместо `select` нужно использовать `epoll`, и тогда хоть 10к соединений в одном потоке можно гонять.
-1
Вот мне однажды Nginx и не подошел из-за того что грузил процессор на 100%. Представьте что вам нужно передавать что-то реалтаймовое в рамках одного соединения. Т.е. есть данные, их на самом деле очень мало, они идут, например, от сервера к клиенту, с паузами, но должны доставляться моментально. Чтобы пропустить такой поток через Nginx нужно отключить ему буферизацию. И привет… А COMET реализован не везде, да и привносит свои задержки.
Впрочем да, вы правы. Мало ли на свете извращенцев. :)
+1
100% — это был именно user time или user + system? Если больше system, то претензии уже не к nginx.

Но вообще, это не является типичным сценарием для пользователя sslh.
0
Действительно. Nginx — это же святое! Как я мог?..

Но даже его воркер можно распараллелить по нескольким процессам и потокам.
0
Да, можно, но конкретно в этом случае смысла не вижу. Ведь задача воркера — это принять пакет из одного сокета и тут же его засунуть в другой сокет без всякой обработки (кроме определения типа протокола в самом начале).

Конечно, если вам нужно обрабатывать хотя быть 100 новых соединений в секунду, а скорость передачи данных превышает 10 гбит/сек, тогда да, нужно заморачиваться с многопоточностью. В противном случае разницы никакой не будет, за исключением того, что однопоточный код проще и меньше подвержен ошибкам.
0
Если кому-то не понравится приведённое в статье решение, то можно использовать HAProxy и разруливать всё доменами. Например, считать, что то, что идёт на ovpn.home.home должно быть спроксировано OpenVPN серверу.
+1
а вы уверены, что тот же openvpn/telegram в заголовках передает домен?
-1
Я делал настройку на основе разбора SNI. У меня за 443 портом жили web-сервер и SoftetherVPN(Который также работает как OpenVPN). OpenVPN клиенты нормально подключались.
+2
Опять же, я не уверен, что все сервисы передают SNI а не делают nsslokup на стороне клиента и уже по IP всё шлют
0

4 haproxy в параллели.
Ходить по SNI не умел только каллбек из яндекс денег.

+2
Мне кажется многим бы был интересен ваш опыт в качестве поста и сравнение с утилитой из этого поста
0
OpenVPN до сих пор не умеет в SNI. Возможно у вас на него fallback правило было (ну т.е. нет правила для конкретного домена — перенаправляем на OpenVPN). В составе Softether у меня по SNI корректно работают только сам Softether и SSTP.
+1
А HAProxy в MTProto-proxy прозрачно будет кидать, или телега будет думать, что всё на одном IP сидят?
+1
использовать технологию DPI во благо

т.е. получается и «взрослый» DPI на строне провайдера это может делать с тем же успехом и блокировать весь канал по этому признаку… верно?
0
Ну, и да и нет. Ваш сервер знает что это за трафик и для чего он, а DPI провайдера — нет. Что касается анализа протоколов, те, что не являются https можно обернуть в stunnel, после чего мультиплексировать на стороне сервера по sni через haproxy или даже nginx (только сборку надо брать официальную, там нужные модули собраны).

В принципе haproxy вообще может заменить sshl (который неизвестно как нагрузку держит), только конфиг для него сложнее написать.
+1
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).
+1
DPI провайдера может резать соединения и по косвенным признакам, например, по паттернам передачи данных по соединению. Кажется, так делают в Китае.
0
Я очень хочу посмотреть на такие DPI в деле. И на законодательную базу к ним.
+3
Приезжайте в Китай и смотрите. Со стороны это выглядит так: поднимаешь VPN до сервера — всё работает. Первые пару мегабайт всё хорошо, а дальше начинается лагодром вплоть до полной невозможности использования VPN, причём остальной трафик не режется.

Во время прошлой поездки в Китай решал проблему, используя международную дата-симку одного из рекламировавшихся здесь операторов — она определялась как гонконгская, и файрвол на неё не распространялся.
+1
То есть возможность деградацию интернета по китайскому сценарию вы даже не рассматриваете?
0
В выгрузке 4 битых ссылки, 450 протухших доменов, раз в месяц невалидный XML — о чем мы тут?
0
Это хорошие дела нужно делать хорошо.
А вредительство, если его делать «спустя рукава» вредительством быть не перестаёт.
0
А что с законодательной базой может быть не так, если она предусматривает блокировки в принципе? Расшифровки не происходит, просто более глубокий анализ пакетов, чем это делает «тупой» роутер, умеющий блокировать по IP типа iptables.
+1
Законодательная база предусматривет некие процедуры. Пока ещё
0
Глубина анализа — техническая деталь реализации, как по мне
0
А как именно отличаются статистические «слепки» Web-серфинга через HTTPS и точно такого же Web-серфинга через HTTPS через VPN?
Долгое соединение с одним web-сервером в реальной жизни довольно часто бывает, наврядли это будет расценено подозрительно.
Оверхед на каждый запрос немного пожирнее, чем обычно, но скорее всего тоже в пределах погрешности.
Что еще?
+1

Ну так речь о том, чтобы отличить обычное HTTPS-соединение от соединения с Telegram-сервером over VPN, а не с HTTPS over VPN. Размер и частота пакетов в этом случае будет отличаться.


Я бы это реализовал так:


  1. При активности на соединении по 443 порту более 15 минут и нехарактерном паттерне пакетов соединение помечается как подозрительное.


  2. Как только соединение определяется как подозрительное, оборудование провайдера переходит к активному анализу — подключается к 443 порту и пытается понять, если ли там чо (OpenVPN, SSH, HTTPS и т.д.)


  3. Если нашлось что-нибудь интересное, кроме HTTPS, то тупо блочим по IP, иначе думаем дальше.

Вариант противодействия есть — это VPN over HTTPS. При запросе определённой секретной страницы происходит переключение на VPN протокол.

0
Но есть и хорошая новость, в случае с Telegram Proxy — без знания ключа ничего не будет работать, openssl подключится без какого либо продолжения т.е сервис раскрыт не будет
0
Да, может, но пока не делает так. Обход блокировок — это игра в кошки-мышки. Провайдер блокирует — люди находят новые способы для обхода.

0
Если мультиплексировать трафик через openvpn share port, то в логах веб сервера адресом источника будет локалхост. У sslh такое же поведение?
+1
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.
0
Не завелся транспарент( На гитхабе описано как такое работает и для очень частных случаев только можно применять. А жаль.
0

Я новичок в стеке vpn/proxy, поэтому возможно немного глупый вопрос. Если есть vpn сервер расположенный в цивилизованной стране не блокирующей трафик и сервер арендованный на деньги работодателя расположенный на мощностях ростелекома, то нужен ли SSLH чтобы развернуть реверс прокси и стучаться в удаленный сайт через впн просто подключаясь к Ростелекомовскому серверу.

0
Цель в том, чтобы без настроек на стороне клиента заходить на сервер, который уже будет поднимать тунели/проксировать до сайта. Хочется настроить один раз и использовать на любой машине.
+3
вот это на самом деле уже не понятно:
без настроек на стороне клиента заходить на сервер

куда заходить? как? чем?

Если вы сможете по лучше объяснить цель, я смогу помочь с решением

0
Заранеее спасибо за ответ.
Есть виртуальный сервер с публичным ip (centos, nginx) расположеный в России и vpn сервер расположенный за границей. Хочеться как-то настроить эту связку, так чтобы заходить на ip первого сервера, а уже сервер через тунель стучался к конкретному сайту (rutracker.org например). Сейчас же приходиться на каждом клиенте поднимать vpn соеденение
+1
гм, два nginx transparent proxy, российский смотрит на зарубежный, зарубежный смотрит на сайты, домены разместить в формате rutracker.ваш_домен.com, при обращении он должен отправлять запрос к истинному сайту. в случае с Apache, это настраивается через proxypass в две строки.

 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 А зачем в схеме вообще российский сервер?, он не несет никакой смысловой нагрузки
+1
Нужно так же отметить, что желательно все-таки на первом nginx/apache (на российском) установить фильтр по IP или какой-нибудь HTTP Auth, иначе есть риск, что рано или поздно он тоже влетит в список блокировок как зеркало.
0
и еще эти методы не будут работать для https сайтов, выход — пропись IP сервера в HOSTS, но это еще менее удобно чем VPN, имхо тогда уж лучше просто прокси поднять да в браузер прописать во второй который для хождения по заблокированным ресурсам
+1
А зачем в схеме вообще российский сервер


Просто что Российский сервер, что акаунт VPN достались по наследству и совершенно бесплатны. Поэтому и хотелось обойтись чисто ими.

0
я намекаю, что он лишнее звено в пищевой цепочке и его можно исключить.
0
Это очевидно, что если есть заграничный сервер то прокси можно настраивать прямо на заграничном. Но в то-то и дело, что есть только Российский сервер и акаунт на vpn сервере. К самому зарубежному серваку доступа нет. Вот и думал, можно ли обойтись без полноценного сервера зарубежом или стоит не парить себе голову взять за 5$/месяц от DO.
+1
Вот теперь я вас наконец-то понял, заграничный у вас не сервер а просто арендованный VPN аккаунт.

Обойтись можно — на сервер подключаем VPN и настраиваем маршрутизацию аналогично как написано выше.

Но это все сложнее чем купить сервер или у DO за 5 евро или у arubacloud за 1 евро
+1
Самое важное, что эта штука умеет не только в localhost.
VPN-сервер может находиться где угодно, а сам sslh может туда ходить по ipv6.
0
К теме докера. Вы написали что у вас не получилось объединить с другими службами, я так понимаю у вас возникли проблемы с сетевыми интерфейсами? Если так, то не пробовали sshl запускать в контейнере с параметром --net host? Тогда по сути он будет работать в контейнере но в сетевом окружении хостовой машины. Или проблема была в другом?
+1
Проблема была в том, что при установке он выдаёт меня выбора в GUI какой тип использовать, докер естественно не может выбрать нужный.
0
а у него нет варианта работы в не-интерактивном виде без dialog? Может проще собрать из исходников внутри контейнера? И чтобы занимало меньше места попробовать использовать build step'ы… Надо будет покопаться)
+1
К сожалению я не нашел, если у вас получится — я думаю ваш докер файл стоило бы приложить в основной репозиторий проекта
+2
Ну контейнер я сделал, собрал. Вроде всё ок.
Лежит на Docker HUB
Буду рад если кто-нибудь сможет протестировать, у меня пока возможности отладить до конца нет. За любой фидбек в личку буду благодарен :)

Если всё нормально работает, то можно и в пост upd добавить будет :)
+1

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
0

из коробки не завелось с ошибкой:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/docker-entrypoint.sh\": permission denied": unknown.

+1
Я сейчас обновляю контейнер, переделываю под разные операционки как раз. Это на тэге latest?
+1
исправлено и перенастроено.

плюс сделал по умолчанию все таки дебиан, так как там есть libwrap, и это важный момент. Добавил на дохабе описание отличия одного от другого и зачем либврап нужен в данном случае :)

Проверил сейчас, все работает
-1
Что если IP-адрес сервера окажется заблокирован, и/или провайдер начнет блокировать по DPI трафик, используемого на 443 порту сервиса (т.к. он отличается от SSL)? Вероятно, лучше на 443/80 вешать обфусцированный мост Tor.
0
shifttstas, а что имели ввиду под фразой «Что позволяет нам использовать технологию DPI во благо.»? Я танкист и новичок.

И кстати ещё нубский вопрос. Нахожусь в Китае, тут мне многие говорят примерно так: «у китайцев DPI, поэтому никакие VPN и прочие анонимайзеры попку не спасут.». Скажите, правы ли они? И если правы, то что делать?

Спасибо.

P.S. Ещё раз, чукча нуб, но когда находился в РФ, то применял простую схему: арендовал на scaleway самый дешевы сервер, развернул там openvpn (через одну команду: github.com/Nyr/openvpn-install ), а дома подключался через аппаратур к нему. И всё. Боюсь подобные решения с китайцами и правда ненадолго.
0
На Scaleway все ещё проще — там очень удобный готовый образ с OpenVPN, удобнее чем этот скрипт.
0
Вот этот: 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.
0
Сам сервер ставить не надо, он уже готовый из набора и выбирается при создании VPS, уже настроенный. Только пользователей заводи, да скачивай настройки для клиента.
0
Обратите внимание на опцию anyprot — именно там будет жить наш Telegram Proxy, другими словами, если трафик не подошел ни под какой тип — отправить туда.

Значит, раз sslh не считает трафик MTProto Proxy за HTTPS, то и DPI провайдера его легко заблокирует, если потребуется.
Only those users with full accounts are able to leave comments.  , please.