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

    Сеть LAN за OpenVPN

    Scheduled Pinned Locked Moved Russian
    10 Posts 2 Posters 1.4k 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.
    • A
      Aircom
      last edited by

      Уважаемые гуру Pfsensa!

      Помогите разобраться с OpenVPN. Поиск мне не дал ответов(

      Поднял туннель, но с компьютеров из LAN клиента нет доступа к устройствам LAN сервера, хотя с обоих PF пинги идут в обе сети.
      С обоих сторон на WAN реальный IP.
      Сеть LAN клиента 10.0.0.0/13. Сеть LAN сервера 10.2.0.0/13
      Настройки Remote network пришлось ставить /22, так как если ставить /13, то даже с Pfsense пинг не проходил. В принципе, нужен доступ только из LAN клиента к адресам LAN сервера 10.2.0.0/22.

      В фаерволе на обоих машинах на интерфейсе OpenVPN IPv4 * * * * * * none все открыто.    
      01.png
      01.png_thumb
      02.png
      02.png_thumb
      03.png
      03.png_thumb
      01.png
      01.png_thumb
      02.png
      02.png_thumb
      04.png
      04.png_thumb
      03.png
      03.png_thumb

      1 Reply Last reply Reply Quote 0
      • A
        Aircom
        last edited by

        При добавлении маршрута смог попасть с адреса 10.0.3.253/13 на LAN интерфейс сервера, но доступа к другим устройствам так же нет.

        Фаервол на сервере так же говорит о том, что трафик проходит, но ничего не пингуется и не открывается(((

        5fa7ad0fce5ec9569de80d7238012f5e.png
        5fa7ad0fce5ec9569de80d7238012f5e.png_thumb
        2222.png
        2222.png_thumb

        1 Reply Last reply Reply Quote 0
        • P
          pigbrother
          last edited by

          Если я не ошибаюсь - при указанных масках /13 диапазоны сетей  клиента 10.0.0.0/13 и сервера 10.2.0.0/13 пересекаются:

          10.0.0.0/13 - 10.0.0.1 - 10.7.255.254
          https://ip-calculator.ru/#!ip=10.0.0.0/13

          10.2.0.0/13 - 10.0.0.1 - 10.7.255.254
          https://ip-calculator.ru/#!ip=10.2.0.0/13

          Соответственно роутинг между ними невозможен.

          В сетях действительно есть необходимость иметь 524286 хостов?

          1 Reply Last reply Reply Quote 0
          • A
            Aircom
            last edited by

            Нет необходимости.. Хорошо что на удаленном шлюзе для клиентов DHCP.. попробую сменить маску. Спасибо.

            Клиентская LAN 10.0.0.0/15 Удаленная LAN 10.2.0.0/22 - ничего не изенилось, кроме того, что убрал в роутере маршрут до сети 10.2.0.0. Пинг пошел без него и на LAN 10.2.0.1 попадаю нормально.

            Update  Все… Пошло... Только не могу попасть на устройства, работающие в прозрачном режиме моста WDS, хотя если я в той локалке - то все норм.

            1 Reply Last reply Reply Quote 0
            • A
              Aircom
              last edited by

              Тут в соседней теме

              @werter:

              Доброе.
              В кач-ве клиента pf ?
              1. Шлюзом у всех машин в обеих сетях должны быть их pf. Проверяйте.
              2. При Peer to Peer (Shared Key) сеть за клиентом видна не будет. Переходите на Remote access . После перехода - добавляйте директиву iroute на сервере в Client specific overrides.

              В гугле это звучит так - Не видно сеть за клиентом Openvpn.

              я вижу и попадаю на роутеры за сервером, но на беспроводные устройства не могу… Со стороны Сервера видны устройства за Клиентом, пинг проходит... при открытии - тишина.

              1 Reply Last reply Reply Quote 0
              • A
                Aircom
                last edited by

                Разобрался…

                Вобщем дело в том, что юзеры в DHCP привязаны маком (Static APR). На беспроводном устройстве IP - статика.. Прописал мак-адрес в DHCP - пинг пошел, но зайти не смог..

                Скорость юзерам режет Captive Portal по маку. Прописал устройство и скорость. ДОСТУП ЕСТЬ (устр-во за Сервером)!!!!

                Но для меня это не есть хорошо. Во-первых, 300+ устройств прописать, во-вторых -резать на них скорость нет необходимости.

                Подскажите, как решить проблему с доступом другим способом?

                1 Reply Last reply Reply Quote 0
                • P
                  pigbrother
                  last edited by

                  @Aircom:

                  Тут в соседней теме

                  @werter:

                  Доброе.
                  В кач-ве клиента pf ?
                  1. Шлюзом у всех машин в обеих сетях должны быть их pf. Проверяйте.
                  2. При Peer to Peer (Shared Key) сеть за клиентом видна не будет. Переходите на Remote access . После перехода - добавляйте директиву iroute на сервере в Client specific overrides.

                  В гугле это звучит так - Не видно сеть за клиентом Openvpn.

                  я вижу и попадаю на роутеры за сервером, но на беспроводные устройства не могу… Со стороны Сервера видны устройства за Клиентом, пинг проходит... при открытии - тишина.

                  Просто добавлю  - в  Peer to Peer (Shared Key) сеть за клиентом видна. Сам пользовался, был первый опыт внедрения Open VPN по канонической инструкции ув. rubic.

                  пинг проходит… при открытии - тишина.
                  Это уже чисто ваша специфика. Пинг проходит - значит маршрут есть.  Возможно запрещен доступ к конкретным ресурсам\сервисам из других сетей и т.д.
                  Т.е если pf - шлюз по умолчанию, на устройстве нет запрещающих правил - все должно работать.

                  В разрешающих правилах на OpenVPN точно указано ANY? pf по умолчанию пытается подставить только TCP.

                  Если планируете развивать использование OpenVPN  - ув. werter прав. К серверу Peer to Peer (Shared Key) нельзя добавить клиентов, он лишен гибкости PSK-Remote access в плане управления клиентами на стороне сервера и т.д.

                  1 Reply Last reply Reply Quote 0
                  • A
                    Aircom
                    last edited by

                    В разрешающих правилах на OpenVPN cтояло ANY, а вот в исходящих из LAN порт блочился. Открыл - завелось.

                    Насчет клиентов - ситуация такая. Сервер сбора статистики сейчас работает за шлюзом PF с установленным Клиентом. Устройства, которые мониторяться - за шлюзом PF на стороне Сервера OpenVPN. Сервер коннектится на устройство и то должно отдавать по TCP свои данные.

                    Какой тип тоннеля предпочтительнее в этом случае? Шлюзов с PF 7 штук.

                    1 Reply Last reply Reply Quote 0
                    • P
                      pigbrother
                      last edited by

                      @Aircom:

                      В разрешающих правилах на OpenVPN cтояло ANY, а вот в исходящих из LAN порт блочился. Открыл - завелось.

                      Насчет клиентов - ситуация такая. Сервер сбора статистики сейчас работает за шлюзом PF с установленным Клиентом. Устройства, которые мониторяться - за шлюзом PF на стороне Сервера OpenVPN. Сервер коннектится на устройство и то должно отдавать по TCP свои данные.

                      Какой тип тоннеля предпочтительнее в этом случае? Шлюзов с PF 7 штук.

                      Любой, настройки которого пропускают TCP.  OpenVPN в режиме tun - просто роутер между сетями. Любое устройство, работающее в IP-сетях будет работать при соблюдении условий:
                      1. Шлюзом по по умолчанию для него является pf в своей сети
                      2. Нужный протокол и порт не закрыты на нем и нет запрещающих правил на pf обеих сторон.

                      Шлюзов с PF 7 штук.
                      И как они (будут) соединяться в режиме PSK Peer-no-Peer?
                      Поэтому переходите на Peer-to-Peer или Remote Access - один сервер в центре, многоженство клиентов-филиалов.

                      1 Reply Last reply Reply Quote 0
                      • A
                        Aircom
                        last edited by

                        Получилось наоборот - множество серверов и на основном сервере несколько поднятых туннелей до каждого. Пака с задачей справился. Доступ между шлюзами не нужен.

                        Спасибо всем за уделенное внимание!

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