Комментарии 100
После беглой проверки возможностей приложения sslh мне показалось, что «завести» не удастся, но меня очень заинтересовало это приложение, и, как оказалось, скрестить ужа с ежом все-таки можно.
PS Лучше в личку о таком писать.
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.
Нужен вариант с количеством потоков пропорциональным количеству ядер. Это было бы оптимально, как мне кажется.
Просто вместо `select` нужно использовать `epoll`, и тогда хоть 10к соединений в одном потоке можно гонять.
Впрочем да, вы правы. Мало ли на свете извращенцев. :)
Но вообще, это не является типичным сценарием для пользователя sslh.
Но даже его воркер можно распараллелить по нескольким процессам и потокам.
Конечно, если вам нужно обрабатывать хотя быть 100 новых соединений в секунду, а скорость передачи данных превышает 10 гбит/сек, тогда да, нужно заморачиваться с многопоточностью. В противном случае разницы никакой не будет, за исключением того, что однопоточный код проще и меньше подвержен ошибкам.
У меня через SNI ~ 50 доменов разруливались.
использовать технологию DPI во благо
т.е. получается и «взрослый» DPI на строне провайдера это может делать с тем же успехом и блокировать весь канал по этому признаку… верно?
В принципе haproxy вообще может заменить sshl (который неизвестно как нагрузку держит), только конфиг для него сложнее написать.
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).
Во время прошлой поездки в Китай решал проблему, используя международную дата-симку одного из рекламировавшихся здесь операторов — она определялась как гонконгская, и файрвол на неё не распространялся.
Ну так речь о том, чтобы отличить обычное HTTPS-соединение от соединения с Telegram-сервером over VPN, а не с HTTPS over VPN. Размер и частота пакетов в этом случае будет отличаться.
Я бы это реализовал так:
При активности на соединении по 443 порту более 15 минут и нехарактерном паттерне пакетов соединение помечается как подозрительное.
Как только соединение определяется как подозрительное, оборудование провайдера переходит к активному анализу — подключается к 443 порту и пытается понять, если ли там чо (OpenVPN, SSH, HTTPS и т.д.)
- Если нашлось что-нибудь интересное, кроме HTTPS, то тупо блочим по IP, иначе думаем дальше.
Вариант противодействия есть — это VPN over HTTPS. При запросе определённой секретной страницы происходит переключение на VPN протокол.
Я новичок в стеке vpn/proxy, поэтому возможно немного глупый вопрос. Если есть vpn сервер расположенный в цивилизованной стране не блокирующей трафик и сервер арендованный на деньги работодателя расположенный на мощностях ростелекома, то нужен ли SSLH чтобы развернуть реверс прокси и стучаться в удаленный сайт через впн просто подключаясь к Ростелекомовскому серверу.
без настроек на стороне клиента заходить на сервер
куда заходить? как? чем?
Если вы сможете по лучше объяснить цель, я смогу помочь с решением
Есть виртуальный сервер с публичным ip (centos, nginx) расположеный в России и vpn сервер расположенный за границей. Хочеться как-то настроить эту связку, так чтобы заходить на ip первого сервера, а уже сервер через тунель стучался к конкретному сайту (rutracker.org например). Сейчас же приходиться на каждом клиенте поднимать vpn соеденение
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 А зачем в схеме вообще российский сервер?, он не несет никакой смысловой нагрузки
А зачем в схеме вообще российский сервер
Просто что Российский сервер, что акаунт VPN достались по наследству и совершенно бесплатны. Поэтому и хотелось обойтись чисто ими.
VPN-сервер может находиться где угодно, а сам sslh может туда ходить по ipv6.
Лежит на 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.
плюс сделал по умолчанию все таки дебиан, так как там есть libwrap, и это важный момент. Добавил на дохабе описание отличия одного от другого и зачем либврап нужен в данном случае :)
Проверил сейчас, все работает
И кстати ещё нубский вопрос. Нахожусь в Китае, тут мне многие говорят примерно так: «у китайцев DPI, поэтому никакие VPN и прочие анонимайзеры попку не спасут.». Скажите, правы ли они? И если правы, то что делать?
Спасибо.
P.S. Ещё раз, чукча нуб, но когда находился в РФ, то применял простую схему: арендовал на scaleway самый дешевы сервер, развернул там openvpn (через одну команду: github.com/Nyr/openvpn-install ), а дома подключался через аппаратур к нему. И всё. Боюсь подобные решения с китайцами и правда ненадолго.
Больше всего меня вот это радует:
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 провайдера его легко заблокирует, если потребуется.
SSLH: Прячем SSH/HTTPS/OpenVPN/Telegram за единым портом 443