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

    Доступ к удаленной VPN через WAN pfSense (port forwarding)

    Scheduled Pinned Locked Moved Russian
    28 Posts 5 Posters 4.3k Views 4 Watching
    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 Offline
      werter
      last edited by

      Добрый
      @Max69

      Странно. Вы там случаем не весь трафик в ВПН заворачиваете?
      Правила fw и таблицу марш-ции про поднятом ВПН покажите

      1 Reply Last reply Reply Quote 0
      • M Offline
        Max69
        last edited by Max69

        Может и весь, у меня по дефолту сейчас все настройки, весь forwarding, что я пробовал не помог, я все правила удалил.
        Я вычитал, что надо после создания ovpnc1 переподключить клиента, т.е. то, что он мне открывает доступ это видимо до переинициализации VPN-соединения, а после соединения VPN рубит весь http-трафик до сервера и видимо это штатное поведение ... А как открыть доступ к web-серверам по обеим сторонам VPN ? Web-сервер доступен со всех прочих машин, которые не за VPN клиентом, т.е. web-сервер торчит в интернете по тому же ip что и VPN-сервер и всем доступен, т.е. на серверной стороне никаких проблем нет.

        На самом pfSense порт сервера тоже доступен через VPN-адрес: Port test to host: 10.8.10.1 Port: 80 successful.

        Но из локалки сайт не открывается ни по 10.8.10.1 ни по публичному IP.

        Вот таблица при поднятом клиенте:

        Destination Gateway Flags Use Mtu Netif Expire
        default 192.168.8.1 UGS 3506 1500 hn0
        10.8.10.1/32 10.8.10.5 UGS 0 1500 ovpnc1
        10.8.10.5 link#7 UH 2123 1500 ovpnc1
        10.8.10.6 link#7 UHS 0 16384 lo0
        XX.XXX.XXX.XX/27 10.8.10.5 UGS 2254 1500 ovpnc1
        127.0.0.1 link#2 UH 165 16384 lo0
        192.168.1.0/24 link#6 U 20442 1500 hn1
        192.168.1.1 link#6 UHS 0 16384 lo0
        192.168.8.0/24 link#5 U 0 1500 hn0
        192.168.8.1 00:15:5d:00:88:0e UHS 2164 1500 hn0
        192.168.8.100 link#5 UHS 0 16384 lo0

        Как то можно направить конкретный порт до интернет-узла мимо VPN ? По идее должно быть как-то тривиально ...
        Выставил статический маршрут XX.XXX.XXX.XX/27 -> WAN_DHCP - 192.168.8.1, вроде работает ! Такое решение вообще корректно ?

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

          @Max69

          Выставил статический маршрут XX.XXX.XXX.XX/27 -> WAN_DHCP - 192.168.8.1, вроде работает ! Такое решение вообще корректно ?

          Как коcтыль - вполне.

          Зы. Так и не увидел скринов правил fw (

          Зы2. Вижу, что пф живет на гипер-в (с VLAN в ВМ-ах на нем "поиграйтесь", ага). Блин, ну есть же xen, vmware, KVM. Чего это "чудо" пользовать-то для fw? Лень что-то новое изучать, видимо.

          M 1 Reply Last reply Reply Quote 0
          • M Offline
            Max69 @werter
            last edited by Max69

            @werter
            Можно сказать лень, а можно сказать "некогда". В hyper-v есть галочка "Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру." Т.е. физическое соединение отдается под виртуалку, получается виртуальный шлюз межу интернетом и виртуалками. А пфсенс выбран за человеческий гуи, некогда читать толмуды и трах-ся с консолями, надо быстро решить конкретные и тривиальные задачи ... а что это - fw ?

            M 1 Reply Last reply Reply Quote 0
            • M Offline
              Max69 @Max69
              last edited by Max69

              @Max69
              Кстати обнаружился неприятный эффект - после обновления pfSense до 2.4.4 галочка "Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру." стала бесполезной. При запуске виртуалки c 2.4.4 сетевой адаптер становится доступным для хоста вне зависимости от галочки. Т.е. 2.4.4 не поддерживает эту фичу Hyper-V, и вообще локалка на прочих виртуалках пропала, короче обновление виртуального шлюза до 2.4.4 все ломает ... пришлось откатить до 2.3.3 обратно. Надо будет в официальную техподдержку запросить, что за бред ...

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

                @Max69
                Зевает
                Обновите hyper-v. Какой там у вас последний-то? Об чем вопрос?
                А, забыл. Это ж MS. Это ж целый гемор с мажорными обновлениями-то.
                У меня это 3 (буквами - три) команды в shell (после правки sources):
                apt-get clean; apt-get update; apt-get dist-upgrade -y

                Можно сказать лень, а можно сказать "некогда".

                Удачи с ленью.

                Зы. Может тут чего docs.netgate.com/pfsense/en/latest/virtualization/virtualizing-pfsense-with-hyper-v.html
                Или пишите в англоветке разрабам. Если это проблема пф, конечно.

                M 2 Replies Last reply Reply Quote 0
                • M Offline
                  Max69 @werter
                  last edited by Max69

                  @werter Не знаю какой гемор, винда обновляется автоматом ... хочешь ставь все обновления, хочешь мажорные ...
                  никакого гемора не было до обновления пф до 2.4.4

                  werterW 1 Reply Last reply Reply Quote 0
                  • M Offline
                    Max69 @werter
                    last edited by Max69

                    @werter А есть на других виртуальных платформах аналогичная возможность создать виртуальный шлюз на базе пф для виртуальной локальной сети. Если вы настолько против Hyper-V подскажите альтернативу. Т.е. чтобы виртуалка закрывала физический сетевой порт порт даже для хоста.

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

                      @Max69 said in Доступ к удаленной VPN через WAN pfSense (port forwarding):

                      Не знаю какой гемор, винда обновляется автоматом

                      Попробуйте обновить Hyper-v 2012 до 2019 )
                      И да. Гипер-в бывает разный - отдельный и КАК РОЛЬ сервера. У вас какой?

                      Т.е. чтобы виртуалка закрывала физический сетевой порт порт даже для хоста.

                      У PVE есть встроенный firewall c GUI. И без ВМ все можно гибко настроить. Мало того, этим же fw можно запретить\разрешить доступ к опред. портам\протоколам на самих VM. Для этого в настройках ВМ на сетевом интерфейсе есть галка Firewall.
                      1.png
                      2.png
                      3.png

                      Что такое PVE (и не только) forum.netgate.com/topic/120102/proxmox-ceph-zfs-pfsense-%D0%B8-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5

                      M 1 Reply Last reply Reply Quote 0
                      • M Offline
                        Max69 @werter
                        last edited by

                        @werter
                        Клево, как нибудь обязательно испытаю это удовольствие .

                        Однако возвращаясь к вопросу, имею необходимость перенаправить порт с публичного IP через VPN туннель на локальную машину.
                        На клиенте сделал проброс: 10.0.8.2:8090->192.168.1.18090
                        На сервере делаю test port: 10.0.8.2 8090 Port test to host: 10.0.8.2 Port: 8090 successful. Т.е. сервер в интернете видит через VPN открытый порт на 192.168.1.1
                        Делаю на сервере проброс
                        Public IP:8090->10.0.8.2:8090, однако чрез Public IP соединения с веб-сервером нет. Что упускаю ?

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

                          Зачем на клиенте проброс?

                          Схему с адресацией в студию.

                          M 1 Reply Last reply Reply Quote 0
                          • M Offline
                            Max69 @werter
                            last edited by Max69

                            @werter
                            Дано:
                            <Интернет> pf Сервер (x.x.x.x) <vpn tun10.0.8.x> pf Клиент <lan> Веб сервер(y.y.y.y)
                            Надо:
                            Доступ из Интернет к y.y.y.y:81 через x.x.x.x:81

                            На клиенте проброс 10.0.8.2:81->y.y.y.y:81 работает
                            На сервере проброс х.х.х.x:81->10.0.8.2:81 не работает

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

                              @Max69
                              Здр
                              Если я все верно понял, то
                              И не будет работать .
                              При такой реализации ответный пакет всегда будет уходить через шлюз по умолчанию pf Клиента.
                              Это особенность PF при работе через виртуальные интерфейсы (GRE,VTI,OpenVPN,...) Проблему можно решить , используя NAT Outbound на виртуальном интерфейсе PF сервера ,или изменив шлюз по умолчанию на PF клиенте.

                              Те сейчас Ваша схема функционирует так

                              Клиент --> <Интернет> pf Сервер (x.x.x.x)--> <vpn tun10.0.8.x>--> pf Клиент --><lan> Веб сервер(y.y.y.y)

                              Обратно
                              Веб сервер(y.y.y.y)--> <lan> --> pf Клиент --> <Интернет> --> Клиент

                              Результат - соединения нет

                              M 1 Reply Last reply Reply Quote 1
                              • M Offline
                                Max69 @Konstanti
                                last edited by Max69

                                @Konstanti
                                Ok. Однако почему-то пакет не ловится на клиенте вообще.
                                Если запускаю Packet Capture на клиенте, на сервере делаю Test Port 10.0.8.2, то все оk, Packet Capture показывает пакеты.
                                Если же http запрос через браузер то Packet Capture на клиенте вообще ничего не показывает ... т.е. похоже трафик не идет даже в одну сторону. Т.е. с публичного IP не заворачивает в VPN. В fw сервера открыл 81й порт на WAN, сделал редирект на 10.0.8.2, в одну то сторону должен пробрасывать по идее.

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

                                  @Max69
                                  Начните отлавливать пакеты с самого начала цепочки

                                  1. PF сервер WAN ( порт 81)
                                  2. PF сервер VPN интерфейс
                                    и тд ....
                                  M 1 Reply Last reply Reply Quote 1
                                  • M Offline
                                    Max69 @Konstanti
                                    last edited by Max69

                                    @Konstanti
                                    Попробовал, интересный эффект, трафик на клиенте ловится с других устройств, а если с самого хоста пф клиента, то трафика нет ... веб-гуи сервера есть, а на другом порту трафика нет ... Аааа, епсель-мопсель, на клиенте же fw, ну усе заработало,

                                    Мэни сэнкс ...)

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