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

    Подключение 3-го узла

    Scheduled Pinned Locked Moved Russian
    23 Posts 3 Posters 2.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.
    • werterW
      werter
      last edited by

      @pigbrother:

      Т.е. если я верно понимаю, несмотря на то, что сети Open VPN и NATятся в WAN в , реально их пакеты ходят по  маршрутам согласно таблице маршрутов без попыток заNATить их.

      Локальные адреса сетей натятся в адреса своих концов туннеля, а не WAN.
      А так - нужно проверять. Будет время - отпишу. Может в 2.4.х что-то и изменилось в этом плане.

      1 Reply Last reply Reply Quote 0
      • M
        MStar
        last edited by

        Коллеги, по моему вопросу есть ли какие-нибудь соображения?

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

          @MStar:

          @pigbrother:

          pfSense, естественно , создал Automatic Rule для всех сетей, включая сети Open VPN c трансляцией их в WAN address.

          Очень интересно, а у меня pfSence создал правила только для физических интерфейсов, для OpenVPN никаких NAT-правил не было. И переключение с Hibrid на Automatic и обратно ничего не дает. Можно подробнее?

          Давным-давно (еще в 2.1 или даже в 2.0) переключил NAT с автоматического в manual для добавления пара правил NAT. Обновился до 2.3.х. Потом эти правила стали не нужны и были удалены, из manual NAT  переключился в hybrid. В Automatic Rules получил такое:

          WAN	 127.0.0.0/8  a.a.2.0/24 b.b.100.0/24 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 	* 	* 	500 	WAN address 	* 		Auto created rule for ISAKMP
WAN 	 127.0.0.0/8  a.a.2.0/24 b.b.100.0/24 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 	* 	* 	* 	WAN address 	* 		Auto created rule

          a.a.2.0 - LAN,  b.b.100.0/24 - DMZ. 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 - сети туннелей RA и site-to-site клиентов Open VPN, котрые в интернет через Open VPN не ходят.
          Интерфейсы для Open VPN не создавались.

          1 Reply Last reply Reply Quote 0
          • M
            MStar
            last edited by

            @pigbrother:

            Интерфейсы для Open VPN не создавались.

            Все так. В данном случае NAT - фактор, роли не играющий.
            Поэтому снова повторяю вопрос: что может препятствовать назначению таблицы маршрутизации серверному интерфейсу OpenVPN и/или как можно этот момент отследить и исследовать. Очень нужна помощь специалиста, знающего pfSense на уровне внутренних механизмов.
            Status / System Logs / OpenVPN```

            Nov 15 09:46:12 openvpn 96554 54AG_Crch_client/188.x.x.10:4484 MULTI_sva: pool returned IPv4=192.168.104.10, IPv6=(Not enabled)
            Nov 15 09:46:12 openvpn 96554 188.x.x.10:4484 [54AG_Crch_client] Peer Connection Initiated with [AF_INET]188.x.x.10:4484
            Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_TCPNL=1
            Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_COMP_STUBv2=1
            Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_COMP_STUB=1
            Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_LZO=1
            Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_LZ4v2=1
            Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_LZ4=1
            Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_PROTO=2
            Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_PLAT=freebsd
            Nov 15 09:46:11 openvpn 96554 188.x.x.10:4484 peer info: IV_VER=2.4.4
            Nov 15 09:43:04 openvpn 96554 Initialization Sequence Completed
            Nov 15 09:43:04 openvpn 96554 UDPv4 link remote: [AF_UNSPEC]
            Nov 15 09:43:04 openvpn 96554 UDPv4 link local (bound): [AF_INET]89.x.x.70:11941
            Nov 15 09:43:04 openvpn 96554 /usr/local/sbin/ovpn-linkup ovpns2 1500 1621 192.168.104.9 255.255.255.248 init
            Nov 15 09:43:04 openvpn 96554 /sbin/ifconfig ovpns2 192.168.104.9 192.168.104.10 mtu 1500 netmask 255.255.255.248 up
            Nov 15 09:43:04 openvpn 96554 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
            Nov 15 09:43:04 openvpn 96554 TUN/TAP device /dev/tun2 opened
            Nov 15 09:43:04 openvpn 96554 TUN/TAP device ovpns2 exists previously, keep at program end
            Nov 15 09:43:04 openvpn 96554 Initializing OpenSSL support for engine 'rdrand'
            Nov 15 09:43:04 openvpn 96554 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
            Nov 15 09:43:04 openvpn 96294 library versions: OpenSSL 1.0.2k-freebsd 26 Jan 2017, LZO 2.10
            Nov 15 09:43:04 openvpn 96294 OpenVPN 2.4.4 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 19 2017

            
netstat -r

| Routing tables |  |  |  |  |
|  |  |
| Internet: |  |
| Destination | Gateway | Flags | Netif | Expire |
| default | 89.225.253.65 | UGS | igb1 |  |
| 10.0.10.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
| 10.0.11.0/24 | 192.168.104.10 | UGS | ovpns2 |  |
| 10.0.13.0/24 | 192.168.104.10 | UGS | ovpns2 |  |
| 10.0.14.0/24 | 192.168.104.10 | UGS | ovpns2 |  |
| 89.225.253.64/28 | link#2 | U | igb1 |  |
| 89.225.253.70 | link#2 | UHS | lo0 |  |
| localhost | link#7 | UH | lo0 |  |
| 172.16.1.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
| 188.172.154.10.bcu | 89.225.253.65 | UGHS | igb1 |  |
| 192.168.1.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
| 192.168.2.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
| 192.168.3.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
| 192.168.100.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
| 192.168.101.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
| 192.168.102.0/24 | link#3 | U | igb2 |  |
| 192.168.102.1 | link#3 | UHS | lo0 |  |
| 192.168.103.0/24 | link#12 | U | igb2.2 |  |
| 192.168.103.1 | link#12 | UHS | lo0 |  |
| 192.168.104.0/29 | 192.168.104.2 | UGS | ovpns1 |  |
| 192.168.104.1 | link#14 | UHS | lo0 |  |
| 192.168.104.2 | link#14 | UH | ovpns1 |  |
| 192.168.104.8/29 | 192.168.104.10 | UGS | ovpns2 |  |
| 192.168.104.9 | link#15 | UHS | lo0 |  |
| 192.168.104.10 | link#15 | UH | ovpns2 |  |
| 192.168.110.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
| 192.168.111.0/24 | link#1 | U | igb0 |  |
| pfSense-Crch | link#1 | UHS | lo0 |  |
| 192.168.112.0/24 | link#13 | U | igb2.4 |  |
| 192.168.112.1 | link#13 | UHS | lo0 |  |
| 192.168.114.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
| 192.168.125.0/24 | 192.168.252.73 | UGS | ovpnc3 |  |
| 192.168.222.0/29 | link#6 | U | igb5 |  |
| 192.168.222.2 | link#6 | UHS | lo0 |  |
| 192.168.252.0/28 | 192.168.252.73 | UGS | ovpnc3 |  |
| 192.168.252.72/29 | 192.168.252.73 | UGS | ovpnc3 |  |
| 192.168.252.73 | link#16 | UH | ovpnc3 |  |
| 192.168.252.74 | link#16 | UHS | lo0 |  |

| 
[ [/td] |
            1 Reply Last reply Reply Quote 0
            • werterW
              werter
              last edited by

              @pigbrother:

              WAN	 127.0.0.0/8  a.a.2.0/24 b.b.100.0/24 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 	* 	* 	500 	WAN address 	* 		Auto created rule for ISAKMP
WAN 	 127.0.0.0/8  a.a.2.0/24 b.b.100.0/24 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 	* 	* 	* 	WAN address 	* 		Auto created rule

              a.a.2.0 - LAN,  b.b.100.0/24 - DMZ. 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 - сети туннелей RA и site-to-site клиентов Open VPN, котрые в интернет через Open VPN не ходят.
              Интерфейсы для Open VPN не создавались.

              Явно указано - WAN. Т.е. если завернуть весь трафик от впн-клиентов в туннель, то в инет они будут иметь возможность выходить через головной сервер. Странно.

              Сохранить конфиг. Удалить правила. Проверить.

              Зы. А может 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 - это локальные сети за впн-сервером? Оч. похоже. И просто забыли ?  ::)

              1 Reply Last reply Reply Quote 0
              • M
                MStar
                last edited by

                @werter:

                Зы. А может 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 - это локальные сети за впн-сервером? Оч. похоже. И просто забыли ?  ::)

                Это вообще не мои сети, это "pigbrother" рассуждал об автосоздаваемых правилах NAT. На своем примере.

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

                  А я ему и отвечал  ;D

                  1 Reply Last reply Reply Quote 0
                  • M
                    MStar
                    last edited by

                    @werter:

                    А я ему и отвечал  ;D

                    Жалко, что мне никто не вожет ответить! :'(

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

                      Зы. А может 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 - это локальные сети за впн-сервером? Оч. похоже. И просто забыли ?

                      Не забыл ;) Адресацию своих LAN вспомню и во сне. 10.11.12.0/24 10.11.11.0/24 10.11.10.0/24 - это именно сети, выделенные под туннели.
                      10.11.12.0/24 - туннель для site-to-site
                      10.11.11.0/24 и 10.11.10.0/24 - туннели двух Remote access OVPN серверов. Зачем  их 2? Один "правильный" на UDP, второй - TCP  для клиентов, чьи провайдеры режут UDP.

                      Жалко, что мне никто не может ответить

                      Не знаю, что может мешать. Маршрут и шлюз в другую сеть через появляются в таблице сразу после создания экземпляра Open VPN сервера, насколько помню - даже если к серверу никто не подключен.

                      Создайте для эксперимента сервер, ведущий в никуда с уникальной адресацией туннеля. Маску туннеля выберите "стандартную" /24.

                      И да, у вас в
                      var-etc-openvpn-csc-server6-Crch_client.txt
                      несколько записей iroute:

                      iroute 192.168.102.0 255.255.255.0
iroute 192.168.103.0 255.255.255.0
iroute 192.168.111.0 255.255.255.0
iroute 192.168.112.0 255.255.255.0

                      За этим клиентом  действительно столько сетей?

                      1 Reply Last reply Reply Quote 0
                      • M
                        MStar
                        last edited by

                        Правильный ответ на заданный вопрос: Если в таблице маршрутизации VPN соединения на сервере виден только адрес собственного шлюза, значит не подключилась информация из CSO. Наивероянейшая причина - ошибка в написании канонического имени сертификата пользователя.

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

                          ошибка в написании канонического имени сертификата пользователя.

                          Вероятно - Common Name.

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

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