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

    OpenVPN PSK: Site-to-Site инструкция для обсуждения

    Scheduled Pinned Locked Moved Russian
    180 Posts 32 Posters 102.2k 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

      Что-то похожее :

      1. http://lists.freebsd.org/pipermail/freebsd-current/2009-July/010020.html
      Как вариант, если возможно, использовать tap-адаптер вместо tun

      2. http://www.daemonforums.org/showthread.php?t=527&highlight=hostname
      Смотрите внимательно конфиг. Красным в его конфиге сервера выделено dev tun0, т.е. явно указан номер tun-интерфейса.

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

        @glamourok:

        Настроено 2 канала OpenVPN (site-to-site, shared key), маршрутизация по OSPF. В общем все сделано, как у вас здесь написано. Нарисовалась проблема, при падению 1 из каналов интернета, соответственно падает туннель опенвпн. Ospf в соотвествии с метриками перекидывает все на другой канал опенвпн. Но вот при появлении интернета, туннель не восстанавливается. В логах пишется вот такая ошибка и служба openvpn падает. Перезапуск не помогает, светится такая же ошибка.

        Aug 19 11:28:58 	openvpn[48699]: OpenVPN 2.2.2 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013
        Aug 19 11:28:58 	openvpn[48699]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
        Aug 19 11:28:58 	openvpn[48699]: LZO compression initialized
        Aug 19 11:28:58 	openvpn[48699]: TUN/TAP device /dev/tun2 opened
        Aug 19 11:28:58 	openvpn[48699]: /sbin/ifconfig ovpns2 172.17.1.1 172.17.1.2 mtu 1500 netmask 255.255.255.255 up
        Aug 19 11:28:58 	openvpn[48699]: FreeBSD ifconfig failed: external program exited with error status: 1
        Aug 19 11:28:58 	openvpn[48699]: Exiting
        

        Помогает перезапуск службы Quagga OSPFd. После этого служба Openvpn стартует и все работает.

        Это читали?

        @rubic:

        Небольшое замечание по настройке OSPF. Не надо делать как на картинках выше. Во-первых, в пакет Quagga OSPF сейчас добрые люди прислали коммит, который не дает сервису OSPFd запустится, если у вас что-то прописано в Disable Redistribution. Во-вторых, даже если это починят, прописывать туда что-либо нет нужды и вообще неправильно.
        Т.е. в Global Settings снимаем галку с Redistribute connected subnets и вычищаем все Disable Redistribution. Идем на вкладку Interface Settings и добавляем там наш LAN интерфейс, в настройках которого ставим галку Interface is Passive.
        Этого достаточно для того, чтобы соседи по OSPF узнали маршрут в вашу локальную сеть, и такая настройка более лучше соответствует принципам OSPF.

        Если да, то конфиг Quagga и таблицу маршрутов на момент, когда один канал VPN лежит, приведите.

        1 Reply Last reply Reply Quote 0
        • G
          glamourok
          last edited by

          Да, именно так и делал. LAN добавил, сделал Пасссивным.

          Вот все маршруты. OpenVPN CLient лежит (там где коннект рвется, там и служба OpenVPN падает, может сервер, может клиент).

          
          IPv4
          Destination 	Gateway 	Flags 	Refs 	Use 	Mtu 	Netif 	Expire
          default 	213.228.116.131 	UGS 	0 	26259 	1492 	pppoe0 	 
          10.64.64.2 	link#11 	UH 	0 	0 	1492 	ppp2 	 
          10.122.66.247 	link#11 	UHS 	0 	6 	16384 	lo0 	 
          10.154.44.150 	10.64.64.2 	UGHS 	0 	174640 	1492 	ppp2 	 
          10.154.44.154 	10.64.64.2 	UGHS 	0 	11702 	1492 	ppp2 	 
          10.154.44.158 	10.64.64.2 	UGHS 	0 	11706 	1492 	ppp2 	 
          92.126.192.213 	link#9 	UHS 	0 	0 	16384 	lo0 	 
          95.191.130.4 	213.228.116.131 	UGHS 	0 	98 	1492 	pppoe0 	 
          127.0.0.1 	link#8 	UH 	0 	21776 	16384 	lo0 	 
          172.17.1.2 	172.17.2.1 	UGH1 	0 	0 	1500 	ovpnc3 	 
          172.17.2.1 	link#13 	UH 	0 	0 	1500 	ovpnc3 	 
          172.17.2.2 	link#13 	UHS 	0 	0 	16384 	lo0 	 
          192.168.0.0/24 	172.17.2.1 	UG1 	0 	8989 	1500 	ovpnc3 	 
          192.168.10.0/24 	link#3 	U 	0 	7810096 	1500 	fxp0 	 
          192.168.10.254 	link#3 	UHS 	0 	0 	16384 	lo0 	 
          195.162.32.5 	213.228.116.131 	UGHS 	0 	2495 	1492 	pppoe0 	 
          195.162.41.8 	213.228.116.131 	UGHS 	0 	2395 	1492 	pppoe0 	 
          213.228.116.131 	link#9 	UH 	0 	0 	1492 	pppoe0 	 
          
          

          172.17.1.0/24 - сеть первого туннеля (ovpnc2), который упал. И больше не поднимается, как раз ошибка, как в посте выше.

          А как конфиг просмотреть QUAGGA OSPFd?

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

            @glamourok:

            Да, именно так и делал. LAN добавил, сделал Пасссивным.

            Вот все маршруты. OpenVPN CLient лежит (там где коннект рвется, там и служба OpenVPN падает, может сервер, может клиент).

            
            IPv4
            Destination 	Gateway 	Flags 	Refs 	Use 	Mtu 	Netif 	Expire
            default 	213.228.116.131 	UGS 	0 	26259 	1492 	pppoe0 	 
            10.64.64.2 	link#11 	UH 	0 	0 	1492 	ppp2 	 
            10.122.66.247 	link#11 	UHS 	0 	6 	16384 	lo0 	 
            10.154.44.150 	10.64.64.2 	UGHS 	0 	174640 	1492 	ppp2 	 
            10.154.44.154 	10.64.64.2 	UGHS 	0 	11702 	1492 	ppp2 	 
            10.154.44.158 	10.64.64.2 	UGHS 	0 	11706 	1492 	ppp2 	 
            92.126.192.213 	link#9 	UHS 	0 	0 	16384 	lo0 	 
            95.191.130.4 	213.228.116.131 	UGHS 	0 	98 	1492 	pppoe0 	 
            127.0.0.1 	link#8 	UH 	0 	21776 	16384 	lo0 	 
            172.17.1.2 	172.17.2.1 	UGH1 	0 	0 	1500 	ovpnc3 	 
            172.17.2.1 	link#13 	UH 	0 	0 	1500 	ovpnc3 	 
            172.17.2.2 	link#13 	UHS 	0 	0 	16384 	lo0 	 
            192.168.0.0/24 	172.17.2.1 	UG1 	0 	8989 	1500 	ovpnc3 	 
            192.168.10.0/24 	link#3 	U 	0 	7810096 	1500 	fxp0 	 
            192.168.10.254 	link#3 	UHS 	0 	0 	16384 	lo0 	 
            195.162.32.5 	213.228.116.131 	UGHS 	0 	2495 	1492 	pppoe0 	 
            195.162.41.8 	213.228.116.131 	UGHS 	0 	2395 	1492 	pppoe0 	 
            213.228.116.131 	link#9 	UH 	0 	0 	1492 	pppoe0 	 
            
            

            172.17.1.0/24 - сеть первого туннеля (ovpnc2), который упал. И больше не поднимается, как раз ошибка, как в посте выше.

            А как конфиг просмотреть QUAGGA OSPFd?

            /var/etc/quagga/ospfd.conf

            проблема в этом маршруте:

            
            172.17.1.2 	172.17.2.1 	UGH1 	0 	0 	1500 	ovpnc3 	 
            
            

            quagga видит клиентский адрес упавшего туннеля через сервер и держит маршрут к нему в таблице,
            соответственно openvpn, поднимая туннель, не может сконфигурировать интерфейс с таким адресом
            почитайте тут:

            http://redmine.pfsense.org/issues/2712
            http://forum.pfsense.org/index.php/topic,60231.0.html

            вроде были какие-то патчи, не помню чем дело кончилось

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

              
              function openvpn_clear_route($mode, $settings) {
              	if (empty($settings['tunnel_network']))
              		return;
              	list($ip, $cidr) = explode('/', $settings['tunnel_network']);
              	$mask = gen_subnet_mask($cidr);
              	$clear_route = false;
              
              	switch($settings['mode']) {
              		case 'shared_key':
              			$clear_route = true;
              			break;
              		case 'p2p_tls':
              		case 'p2p_shared_key':
              			if ($cidr == 30)
              				$clear_route = true;
              			break;
              	}
              
              	if ($clear_route && !empty($ip) && !empty($mask)) {
              		list($ip1, $ip2) = openvpn_get_interface_ip($ip, $mask);
              		$ip_to_clear = ($mode == "server") ? $ip1 : $ip2;
              		mwexec("/sbin/route -q delete {$ip_to_clear}");
              	}
              }
              
              

              Это часть патча, которая уже интегрирована в openvpn.inc - руками патчить ничего не надо. Смотрим и видим, что маршрут будет очищен только когда префикс tunnel network = 30 (if ($cidr == 30) $clear_route = true;).
              Т.е. вместо 172.17.1.0/24, 172.17.2.0/24 ставим везде 172.17.1.0/30 и 172.17.2.0/30, должно работать. Во всяком случае, у меня на стенде работает с /30 и не работает с /24

              1 Reply Last reply Reply Quote 0
              • D
                dsm150
                last edited by

                1. Уважаемый Rubic, не могли бы Вы описать процедуру создания туннелей, с использованием OSPF, при нескольких    филиалах, при WAN failover со-всех сторон?

                2. Попробовал создать подключение двух филиалов к центральному офису, без OSPF, как и описано в первом посте - оба филиала отлично видят центральный офис, а вот друг друга - нет. Роуты в адвансед клиентов, естесственно, прописал. С шлюза филиала1, Traceroute до ip в сети  филиала2 уходит в туннель, и там "оседает".

                Таблица центрального офиса:

                Таблица филиала1:

                Таблица филиала2:

                Traceroute с одного из филиалов:

                В обоих филиалах Multiwan failover

                3. Возможно ли как то клиентов из Remote Acceess тоже заставить видеть все эти три сети?

                Заранее, благодарен!

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

                  1. Если нужна полная связность при любых обстоятельствах (кроме конечно падения обоих WAN на одной из площадок), то связывают WANы туннелями по принципу "каждый с каждым". Только накладно это в режиме PSK - при 3-х плошадках на каждом WAN надо иметь по 4 сервера/клиента OpenVPN. В OSPF потом просто добавляются все OpenVPN интерфейсы как активные, а все LANы - как пассивные.
                  2. С маршрутами, судя по всему, все в порядке. Поэтому смотрите логи файервола на центральном сервере, на сервере и клиенте филиала, который трассируете.
                  3. Прописать маршруты на клиентах, или настроить, чтобы VPN был маршрутом по умолчанию. Не понятно что за клиенты.

                  1 Reply Last reply Reply Quote 0
                  • D
                    dsm150
                    last edited by

                    @rubic:

                    1. Если нужна полная связность при любых обстоятельствах (кроме конечно падения обоих WAN на одной из площадок), то связывают WANы туннелями по принципу "каждый с каждым". Только накладно это в режиме PSK - при 3-х плошадках на каждом WAN надо иметь по 4 сервера/клиента OpenVPN. В OSPF потом просто добавляются все OpenVPN интерфейсы как активные, а все LANы - как пассивные.
                    2. С маршрутами, судя по всему, все в порядке. Поэтому смотрите логи файервола на центральном сервере, на сервере и клиенте филиала, который трассируете.
                    3. Прописать маршруты на клиентах, или настроить, чтобы VPN был маршрутом по умолчанию. Не понятно что за клиенты.

                    1. Может посоветуете оптимальное решение для таких условий?

                    Лог Firewall центрального, при traceroute с pfs филиала 1 на машину в сети филиала 2.

                    Лог  Firewall филиала 2, при traceroute с pfs филиала 1 на машину в сети филиала 2.

                    И кстати, если пытаюсь делать traceroute с машины в сети филиала 1 на машину в сети филиала 2 - trace вообще отправляется в сеть провайдера. То же самое и наоборот.
                    Если из филиала делаю trace на машины центрального, все идет как положено.

                    3. Клиенты подключенные к серверу remote access поднятому тоже на центральном pfs (ноутбуки, телефоны и т.п.)

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

                      1. В режиме PKI OpenVPN сервер может обслуживать несколько клиентов, т.е. как минимум сократится кол-во серверов. А вообще надо сначала определиться с топологией связей между площадками. Либо весь трафик между ними ходит через центральный офис (неполная связность - меньше работы по настройке), либо каждая должна быть связана с каждой (полная - больше). Зависит от ваших задач. Должны ли, например, филиалы иметь возможность общаться между собой, когда центральный офис в офлайне? Какие провайдерские сети лежат под туннелями и как они связаны? У вас вон, судя по скринам, оба филиала подключены к одному провайдеру. Стоит ли дублировать связь между ними, иными словами что вероятнее, что у этого провайдера аплинк упадет, или что внутренняя связность нарушится?

                      2. Трассируйте не с pfSense первого филиала, а с машины из его локальной сети. Второй филиал знает только про 172.11(кстати, почему 11 а не 16?).11.0/24 и ничего не знает про 10.0.5.2. Соответственно, не знает куда слать ответы и шлет их на шлюз по умолчанию, т.е. провайдеру.

                      3. Опять же в режиме PKI можно настройками на сервере передать клиенту нужные маршруты или даже завернуть весь трафик клиента через сервер.

                      1 Reply Last reply Reply Quote 0
                      • D
                        dsm150
                        last edited by

                        1. Буду пробовать PKI. Связь нужна с центральным, возможность общаться между филиалами - приятная опция. В приведенных примерах тестовый вариант. Так сказать изучаю вопрос в боевых условиях. Вторые аплинки у филиалов и центра будут иными провайдерами или GSM.

                        2. Так в том то и дело, что трассировка с компа в сети филиала 1 на комп в сети филиала 2 - сразу же уходит к провайдеру, в то время, как трассировка с этого же компа на ком в сети центрального офиса - идет до адресата правильно. С компа центрального офиса, трассировка до компов филиалов тоже идет без нареканий.
                        По адресации - не совсем по rfc, понимаю. Но изменить пока возможности нет, но запланировано.

                        И как филиал 2 должен узнать про туннель 10.0.5.0/24? В Вашей инструкции про это ничего не сказано. Как бы все само собой должно работать?

                        3. Понял.

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

                          @dsm150:

                          Так в том то и дело, что трассировка с компа в сети филиала 1 на комп в сети филиала 2 - сразу же уходит к провайдеру, в то время, как трассировка с этого же компа на ком в сети центрального офиса - идет до адресата правильно. С компа центрального офиса, трассировка до компов филиалов тоже идет без нареканий.
                          По адресации - не совсем по rfc, понимаю. Но изменить пока возможности нет, но запланировано.

                          Из чего видно, что трассировка уходит к провайдеру? На pfSense 1-го филиала настроен какой-нибудь policy routing? Приведите скрин Firewall -> Rules -> LAN и Floating если в последнем что-то есть.

                          1 Reply Last reply Reply Quote 0
                          • D
                            dsm150
                            last edited by

                            Во всех трех PFS идентичные правила. На центральном только нет failover.

                            Каких то специальных правил не прописывал. Есть только портмаппинги по определенным портам, и все.

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

                              Выше правила FAILOVER сделайте правило:

                              • Lan Net * 172.11.10.0/24 * * none
                              1 Reply Last reply Reply Quote 0
                              • R
                                rubic
                                last edited by

                                Во втором филиале тоже:

                                • Lan Net * 172.11.11.0/24 * * none
                                1 Reply Last reply Reply Quote 0
                                • S
                                  swch
                                  last edited by

                                  Спасибо за хорошую инструкцию.
                                  Все сделал как в первой публикации и заработало, НО не все получилось.  Из филиала сеть главного офиса пингуется и полностью доступна, а из центрального офиса сеть филиала не видна. Пинг не идет даже до адреса 10.0.8.2 (виртуальный адрес филиала). Трейсроут доходит до pfsens-а главного офиса и теряется. Что это может быть? В какую сторону рыть?

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

                                    @swch:

                                    Спасибо за хорошую инструкцию.
                                    Все сделал как в первой публикации и заработало, НО не все получилось.  Из филиала сеть главного офиса пингуется и полностью доступна, а из центрального офиса сеть филиала не видна. Пинг не идет даже до адреса 10.0.8.2 (виртуальный адрес филиала). Трейсроут доходит до pfsens-а главного офиса и теряется. Что это может быть? В какую сторону рыть?

                                    Смотрите в сторону правил файервола на LAN центрального офиса. Простейший способ проверить, что дело в них - временно разрешить все.

                                    1 Reply Last reply Reply Quote 0
                                    • S
                                      swch
                                      last edited by

                                      Так в том то и дело, что в ЛАНе практически все разрешено, кроме 80 порта. Что б люди ходили через прокси, а не через NAT. В таблице маршрутизации тоже криминала не вижу. Грешу на обновление до версии 2.1. Похоже надо перебивать сервак, а очень не хочется.

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

                                        2 swch

                                        Покажите таблицу маршрутизации и что стоит на втором конце туннеля?

                                        1 Reply Last reply Reply Quote 0
                                        • S
                                          swch
                                          last edited by

                                          Сегодня выяснилась странная ситуация. Оказывается сеть главного офиса доступна, просто пинг не ходит. Но правила блокирующего протокол ICMP я не создавал. Чертовщина какая-то!
                                          Вопрос закрыт.

                                          1 Reply Last reply Reply Quote 0
                                          • X
                                            xojic
                                            last edited by

                                            Попробуй прописать основной шлюз pfsense, на той тачке которую хочешь пингануть.

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