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.
    • 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.