Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    pfSense и SSLH - прикидывемся ветошью и не отсвечиваем

    Scheduled Pinned Locked Moved Russian
    21 Posts 3 Posters 1.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • werterW
      werter
      last edited by werter

      Конечно, не поможет от ДПИ, но как #because_i_can www.vpntutorials.com/tutorials/openvpn-sharing-a-port-with-a-webserver-on-port-80-443/

      --port-share host port
      When run in TCP server mode, share the OpenVPN port with another application, such as an HTTPS server. If OpenVPN senses a connection to its port which is using a non-OpenVPN protocol, it will proxy the connection to the server at host:port. Currently only designed to work with HTTP/HTTPS, though it would be theoretically possible to extend to other protocols such as ssh.

      1 Reply Last reply Reply Quote 0
      • K
        Konstanti @rubic
        last edited by Konstanti

        @rubic
        Здр
        Пока вдумываюсь в написанное , хотел уточнить
        будет работать такая идея ?
        есть список разрешенных ip
        пришел пакет с разрешенного ip ( например , на порт 443)
        меняем порт 443 (на 444 , к примеру , пересчитываем контрольную сумму tcp пакета ) и отправляем его дальше в файрвол , а на порту 444 работает наша прога
        обратно меняем так же с 444 на 443 и в путь
        Если ip неразрешенный , то порт остается 443, и пакет форвардится на липовый web сервер
        Работать все будет на уровне ядра и до того момента пока пакет "сырой" и не попал в стек ( обратно уже после стека соответственно )

        R 1 Reply Last reply Reply Quote 0
        • werterW
          werter
          last edited by werter

          @Konstanti
          Заранее извиняюсь, что вмешиваюсь

          есть список разрешенных ip
          пришел пакет с НЕразрешенного ip ( например , на порт 443) -->

          --> пакет форвардится на веб-сервер ЗА пф
          пришел пакет с разрешенного ip - пакет уходит на sslh, к-ый УЖЕ висит на ВАН. Делается простым разрешающим правилом Fw на WAN.

          Как-то так. Зачем еще какой-то доп софт городить?

          K 1 Reply Last reply Reply Quote 0
          • K
            Konstanti @werter
            last edited by

            @werter
            Согласен , что-то я об этом не подумал
            Это лежит на поверхности (а слона-то я и не заметил )

            1 Reply Last reply Reply Quote 0
            • werterW
              werter
              last edited by

              @rubic
              Надо бы попробовать? )

              1 Reply Last reply Reply Quote 0
              • R
                rubic @Konstanti
                last edited by

                @Konstanti werter подал захватывающую идею, буду ее думать, поэтому не отвечу по существу. Что если:

                1. завести 2 stunnel сервера: localhost:2345 и localhost:6789
                2. правилами Port Forward направлять четкие IP с 443 порта WAN на первый, а левые - на второй
                3. в настройках stunnel серверов в redirect указать localhost:1194 для первого, а localhost:80 - для второго
                  PROFIT?
                K 1 Reply Last reply Reply Quote 0
                • K
                  Konstanti @rubic
                  last edited by Konstanti

                  @rubic Не совсем понял сакрального смысла во втором сервере
                  Все левые ip проще силами PF сразу отправлять на нужный нам web сервер на порту 443 .

                  Насколько я вижу в исходниках , эта прога ничего не шифрует и не расшифровывает , а просто анализирует сигнатуры пакетов ( данные) и по этим сигнатурам определяет дальнейший порт назначения

                  R 1 Reply Last reply Reply Quote 1
                  • R
                    rubic @Konstanti
                    last edited by

                    @Konstanti said in pfSense и SSLH - прикидывемся ветошью и не отсвечиваем:

                    @rubic Не совсем понял сакрального смысла во втором сервере
                    Все левые ip проще силами PF сразу отправлять на нужный нам web сервер на порту 443 .

                    пфф... ну да, я просто еще в своей парадигме - завел ведь уже у себя второй инстанс nginx без шифрования, поэтому и stunnel тут для TLS offloading, это да, поправимо

                    Насколько я вижу в исходниках , эта прога ничего не шифрует и не расшифровывает , а просто анализирует сигнатуры пакетов ( данные) и по этим сигнатурам определяет дальнейший порт назначения

                    именно!

                    K 1 Reply Last reply Reply Quote 0
                    • K
                      Konstanti @rubic
                      last edited by

                      @rubic Ну , да
                      тут два пути вижу
                      1 это использовать внешнюю обертку
                      2 имплементровать библиотеку OPenSSl в этот проект
                      Особых сложностей тут не вижу, опыт есть
                      Но надо с кодом разбираться )

                      R 1 Reply Last reply Reply Quote 0
                      • R
                        rubic @Konstanti
                        last edited by

                        @Konstanti Эмм... это вы куда-то глубоко копнули, я не понял. Пока вижу более простые способы - либо second nginx на https перевести, либо таки второй сервер stunnel.
                        В любом случае, @werter, @Konstanti, вам спасибо! Приеду из отпуска через неделю, запилю что-то по новым вводным и выложу)
                        Для всех, кто не следил, задача подключаться с нужных IP к OpenVPN на HTTPS порт сервера, а ненужным отдавать фэйковый сайт

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.