SSLH: Прячем SSH/HTTPS/OpenVPN/Telegram за единым портом 443

  • Tutorial
image

SSH/HTTPS/OpenVPN/Telegram и всё на одном порту?! Что?!
— Да!
  • Хотите скрыть наличее у вас некоторых сервисов?
  • В публичной wi-fi сети блокируется всё кроме 443 (https) порта?
  • Настроили Telegram Proxy/OpenVPN и не хотите его «светить» ?
  • SSH подключение к своему серверу из стран с цензурой?

На все эти вопросы ответ один — Мультиплексирование SSL/TLS соединений, или SSLH.

В посте мы рассмотрим как в 1 команду спрятать кучу сервисов за 1 портом.

Почему?


С недавним выходом Telegram Proxy который почти полностью выглядит как SSL трафик появился интересный вопрос в комментариях к посту:
Newton:
У меня довольно нубский вопрос — а завести это вместе с sslh не реально?
После беглой проверки возможностей приложения sslh мне показалось, что «завести» не удастся, но меня очень заинтересовало это приложение, и, как оказалось, скрестить ужа с ежом «завести» все-таки можно.

Как?


Приложение SSLH — мултиплексор, другими словами, оно анализируя трафик (фактически выполняя работу mini-DPI) и в зависимости от типа трафика, направляет его в локальный порт 8443/999/991 или любой другой…

Что позволяет нам впервые использовать технологию DPI во благо.

Задача


Для примера использования SSLH поставим задачу:

На сервере установлены следующие приложения — Telegram Proxy, Apache, SSH и все эти сервисы мы хотим пускать в мир через 443 порт.

Сервер в нашем примере — Ubuntu 16.04.4 LTS, Apache2 + LetsEncrypt,SSH,Telegram Proxy в Docker.

На данный момент, на нем работает, как и положено, Apache.

Установка & Настройка


Установим SSLH:

sudo apt-get install --no-install-recommends sslh

При установке будет задан вопрос о режиме использования, их два:

  • стабильный но более ресурсозатратный
  • быстрый, но с потерей соединений при падении процесса

Я за второй вариант, вы, конечно же, можете выбрать другой.

Проверим, работает ли наше чудо следующей командой:


sudo sslh-select -f --listen IP:8443 --tls 127.0.0.1:443  --ssh 127.0.0.1:22 --anyprot 127.0.0.1:9443

IP — внешний IP сервера
8443 — порт на котором будет запущен наш мултиплексор
443 — там где живет Apache
Обратите внимание на опцию anyprot — именно там будет жить наш Telegram Proxy, другими словами, если трафик не подошел ни под какой тип — отправить туда.

Внимание! Если в вашей конфигурации отсутствует Telegram или SSH — уберите лишние ключи запуска.

Проверим?


Откройте браузер по адресу вашего сервера с портом 8443 — вы должны увидеть ответ от Apache, далее попробуйте подключить по SSH или через Telegram Proxy.

Перенос Apache на другой порт


Для переноса Apache со стандартного порта (443) на другой, например на 7443, посетите следующие файлы:


sudo nano /etc/apache2/ports.conf
sudo nano /etc/apache2/sites-enabled/000-default-le-ssl.conf

В примере Apache+SSL/HTTPS был установлен с использованием LetsEncrypt при другом сертификате конфигурационные файлы могут быть по другим путям.

Автозапуск


Настало время настроить автозапуск.

Отредактируем файл:


sudo nano /etc/default/sslh

В поле DAEMON_OPTS= добавьте атрибуты при запуске команды sslh-select, установите RUN в =yes.

Запустим:


sudo systemctl start sslh

Убедимся, что всё хорошо:


sudo systemctl status sslh

Что в итоге?


После прохождения данного туториала у вас должен был появится сервер, у которого через единый порт доступны сразу несколько служб (какие — на ваш выбор).

А как дела с OpenVPN? какие протоколы еще умеет приложение?


На момент написания поста, sslh умеет определять и мультиплексировать следующие протоколы:

	[--ssh <addr>]
	[--openvpn <addr>]
	[--tinc <addr>]
	[--xmpp <addr>]
	[--http <addr>]
	[--ssl <addr>]
	[--tls <addr>]
	[--anyprot <addr>]

Перед использованием, лучше убедиться, какие протоколы поддерживает ваша версия, (вдруг она новее) используя:

sslh-select -h


Ссылки


Разработка SSLH происходит на github, вот в этом репозитории: github.com/yrutschle/sslh

Docker


Собрать рабочий вариант sslh в докере вместе со всеми другими службами у меня не получилось, на мой взгляд будет интересен docker-compose файл который сможет поднять на 443 порту:
  • Apache + LetsEncrypt
  • Telegram Proxy
  • OpenVPN (опционально)
  • Использовать локальный SSH


Если у кого то это получится — пишите в комментариях — добавим в статью, на мой взгляд, это будет полезно.

Вам также может быть интересно


Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 99

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

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

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

            PS Лучше в личку о таком писать.
              +1
              Не вижу проблем в построении этой фразы. Что в ней не так, по вашему мнению?
                0
                Были предложения по добавлению «И», я его добавил, так правда чуть по лучше.
          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 надо тестировать
                      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
                почему не густо? чего не хватает?
                  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

                        У меня через SNI ~ 50 доменов разруливались.

                          0
                          Какая связка ПО?
                            0

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

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

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

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

                                    Во время прошлой поездки в Китай решал проблему, используя международную дата-симку одного из рекламировавшихся здесь операторов — она определялась как гонконгская, и файрвол на неё не распространялся.
                                      0
                                      Да причем тут Китай? Тут. GFW? Okey — пилите
                                        +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 протокол.

                                          +1
                                          Вы сейчас описали как работает Китайских фаервол в режиме «Опережающего подключения»
                                            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
                                            Не завелся транспарент( На гитхабе описано как такое работает и для очень частных случаев только можно применять. А жаль.
                                            0

                                            del

                                            0

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

                                              0
                                              Можно всё, цель непонятна.
                                                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, и это важный момент. Добавил на дохабе описание отличия одного от другого и зачем либврап нужен в данном случае :)

                                                                  Проверил сейчас, все работает
                                                                    0

                                                                    правда — работает :)
                                                                    спасибо

                                                        –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
                                                              Это ж какой? Хотя не суть, речь не об этом.
                                                                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
                                                                  Всё же одна команда быстрее. Хотя какая разница…
                                                                    0
                                                                    Сам сервер ставить не надо, он уже готовый из набора и выбирается при создании VPS, уже настроенный. Только пользователей заводи, да скачивай настройки для клиента.
                                                            0

                                                            Вопрос от новичков — не пробовал никто с Algo VPN подружить?
                                                            Есть варианты?


                                                            https://github.com/trailofbits/algo

                                                              0
                                                              Обратите внимание на опцию anyprot — именно там будет жить наш Telegram Proxy, другими словами, если трафик не подошел ни под какой тип — отправить туда.

                                                              Значит, раз sslh не считает трафик MTProto Proxy за HTTPS, то и DPI провайдера его легко заблокирует, если потребуется.

                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                              Самое читаемое