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

    PfSense для средней сети и настройка правил.

    Scheduled Pinned Locked Moved Russian
    45 Posts 7 Posters 20.0k 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.
    • R
      rubic
      last edited by

      @pigbrother:

      Прочитал  :) комментарии к настройке поля Remote networks. Они честно отличаются:

      Для 2.0.х

      This is a network that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a CIDR range. If this is a site-to-site VPN, enter here the remote LAN here…

      Для 2.1.2:
      These are the IPv4 networkS that will be routed through the tunnel, so that a site-to-site VPN can be established without manually changing the routing tables. Expressed as a comma-separated list of one or more CIDR ranges. If this is a site-to-site VPN, enter the remote LAN/s here….

      Таким образом, теперь нет необходимости прописывать "route…" в Advanced configuration, все сети можно прописать в IPv4 Remote Network/s. То же самое с "push route" - все локальные для сервера сети можно прописать в IPv4 Local Network/s.

      Если можно - подробнее про самостоятельное создание аналога negate rule.

      Обратите внимание на следующее: любое policy based routing (PBR) правило направляет трафик в обход системной таблицы маршрутизации, т.е. на этот трафик системные маршруты не действуют, даже если они есть (pf routing: https://forum.pfsense.org/index.php?topic=73670.0). Поэтому, чтобы трафик между сетями подчинялся системным маршрутам, необходимо перед PBR правилом поставить другое - из нужной сети в нужную сеть с gateway = default. Это именно то, что и делают скрытые negate rules - перед каждым PBR правилом разрешают трафик из всех подключенных сетей во все подключенные сети. Очевидно, разработчики пришли к выводу, что это медвежья услуга - лучше, чтобы оператор сам контролировал кого куда пускать.

      По поводу negate_networks> на клиентах. Проверил на  2.1.2
      В tmp/rules.debug
      table <vpn_networks>и table <negate_networks>Создаются\заполняются только при создании сервера, но не клиента OVPN.</negate_networks></vpn_networks>

      А если на клиенте в IPv4 Remote Network/s прописать что-нибудь?

      1 Reply Last reply Reply Quote 0
      • W
        WY6EPT
        last edited by

        я бы посоветовал переназначить порт управления роутером и выключить автоматический редирект в админку. искать специально будут долго.

        а так же как уже выше описали при использовании атрибута Gateway в правиле сети можно исключить попадание клиента в любую сеть кроме внешней.

        так же можно заготовить правило для копирования и просто переносить копию на вновь появившийся интерфейс. для запрета доступа к локальному интерфейсу шлюза.
        допустим прописать его таким образом
        reject
        интерфейс клиента
        протокол any
        сурс эни
        дест интерфейс_адресс

        а в портах прописать алиас портов которые хочется прикрыть 22 80 443 и тд
        днс в таком случае будет ходить

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

          Поэтому, чтобы трафик между сетями подчинялся системным маршрутам, необходимо перед PBR правилом поставить другое - из нужной сети в нужную сеть с gateway = default

          То есть то самое правило вида:
          IPv4 * LAN net * remote_network/24 * * none
          Так?

          А если на клиенте в IPv4 Remote Network/s прописать что-нибудь?

          Создал fake-клиента с такими настройками:

          dev ovpnc1
          dev-type tun
          tun-ipv6
          dev-node /dev/tun1
          writepid /var/run/openvpn_client1.pid
          #user nobody
          #group nobody
          script-security 3
          daemon
          keepalive 10 60
          ping-timer-rem
          persist-tun
          persist-key
          proto udp
          cipher AES-128-CBC
          up /usr/local/sbin/ovpn-linkup
          down /usr/local/sbin/ovpn-linkdown
          local 192.168.126.128
          tls-client
          client
          lport 0
          management /var/etc/openvpn/client1.sock unix
          remote 1.2.3.4 1194
          ifconfig 10.0.22.2 10.0.22.1
          route 10.0.0.10 255.255.255.0
          ca /var/etc/openvpn/client1.ca 
          cert /var/etc/openvpn/client1.cert 
          key /var/etc/openvpn/client1.key 
          tls-auth /var/etc/openvpn/client1.tls-auth 1
          

          и в  tmp/rules.debug

          записи появились:

          table <vpn_networks>{ 10.0.0.10/24 10.0.22.0/24 }
          table <negate_networks>{ 10.0.0.10/24 10.0.22.0/24 }

          Какой правильный вывод из этого следут сделать? Обязательно заполнять Remote Network/s и на клиенте?</negate_networks></vpn_networks>

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

            Какой правильный вывод из этого следут сделать? Обязательно заполнять Remote Network/s и на клиенте?

            В чем проблема проверить?
            Варианты :

            1. Не указывать. В настройках сервера прописать директиву push "route x.x.x.x y.y.y.y vpn_gateway"; и route … .На клиенте же можно добавить директиву pull (а можно и не добавлять)
            2. В настройках сервера не указывать директиву push …, только route. В настройках клиента прописать директиву route x.x.x.x y.y.y.y vpn_gateway;
            3. Заполнить поле  Remote Network/s на клиенте и route ... на сервере.

            Это основные вар-ты. Существуют еще и подверсии этих же.

            P.s. @ pigbrother

            Какой-то Вы нерешительный, что ли. С одним несчастным ОпенВПН-ом разбираетесь хз сколько времени. Уже давно бы все попробовали и выяснили что для вас подходит\работает.
            Так нет, устроили тут "Твиттер" честное слово : "Прописал строку, удалил строку" и т.д. и т.п.

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

              @pigbrother:

              Какой правильный вывод из этого следут сделать? Обязательно заполнять Remote Network/s и на клиенте?

              Не и на клиенте, а только на клиенте, если negate_networks вам так дороги)

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

                @werter
                Так нет, устроили тут "Твиттер" честное слово : "Прописал строку, удалил строку" и т.д. и т.п.

                Показалось, что тема negate в деталях интересна не только мне. Если этим отвлек\напряг вас - не обессудьте, старею, наверное.

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

                  @ pigbrother

                  Пардоньте и вы меня, но вот сложилось такое впечатление.
                  P.s. "Не ошибается тот , кто ничего не делает"(с)

                  1 Reply Last reply Reply Quote 0
                  • R
                    Rearden
                    last edited by

                    Коллеги, приветствую!
                    Ограничил доступ к ssh,http как показано на скриншоте. На самом деле всё просто - первым правилом разрешается пинговать шлюз, следующим правилом разрешается доступ к локальным ресурсам (на тестовом роутере сделано from $net to $servers any, в идеале надо сделать доступ только к определенным портам, Например from $net to $server 80,25 etc.). Третьим правилом разрешается "выход в интернет" но кроме $local_networks в чей диаппазон и входит адрес конкретного маршрутизатора.

                    На данный момент полет нормальный. 18 VLAN'ов. States в среднем 10k (в данный момент 7% (6461/98000)).
                    За 37 дней аптайма был следующий глюк - сервер перестал пускать на вэб-интрефейс. Проблема решилась удалением php-sockets из /tmp и рестартом webconfigurator.

                    Далее есть непонятка с NetFlow. Сейчас работает softflowd. На самом деле не понятно как работает, ибо в том VLANe на который он натравлен крайне мало netflow трафика (несколько пакетов в 5 минут), соответственно в биллинге не обновляется информация о трафике. Пробовал pfflowd, он генерит больше трафика, но постоянно падает. Так что вопрос о netflow остается открытым. На продакшене сейчас работает через ngctl и правило ipfw add ngtee 5 ip from any to any in.

                    1.png
                    1.png_thumb

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

                      https://forum.pfsense.org/index.php?topic=78224.30

                      И да, по первому правилу (сверху вниз) - fw разрешает\запрещает трафик только ко внешним сетям. У вас же правило, к-ое пытается обработать трафик в одной с pfsense сети.
                      Толку от него - нуль.

                      Поправьте (или проверьте) , если я не прав.

                      1 Reply Last reply Reply Quote 0
                      • R
                        Rearden
                        last edited by

                        werter, смотрите:
                        Первое правило - это разрешение пинговать шлюз (Proto ICMP)
                        Второе правило - разрешение трафика до серверов
                        Третье правило - выход в инет

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

                          @Rearden:

                          werter, смотрите:
                          Первое правило - это разрешение пинговать шлюз (Proto ICMP)
                          Второе правило - разрешение трафика до серверов
                          Третье правило - выход в инет

                          Как работают правила - я в курсе . Еще с первых версий m0n0wall-а.

                          И да, по первому правилу (сверху вниз) - fw разрешает\запрещает трафик только ко внешним сетям. У вас же правило, к-ое пытается обработать трафик в одной с pfsense сети. Толку от него - нуль.

                          Проверили это ?

                          1 Reply Last reply Reply Quote 0
                          • R
                            Rearden
                            last edited by

                            Проверили это ?

                            Не понимаю, что Вы имеете ввиду.

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

                              Отключите\удалите то правило и проверьте будет ли пинг.

                              1 Reply Last reply Reply Quote 0
                              • R
                                Rearden
                                last edited by

                                не пингует без него.

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