Маршрутизация в Quagga OSPF

aka_daemon

Доброго дня.
Имеется офис и несколько филиалов.
В офисе1 pfsense01 имеет 2 wan канала, работающих в режиме failover. в филиале2 pfsense02 имеет 1 wan канал.
Между офисом и филиалом подняты два openvpn канала(режим PSK): 1 канал 10.10.9.0/24, port udp 1196; 2 канал 10.13.9.0/24, port udp 1296

Встала задача обеспечить отказоустойчивость посредством Quagga OSPF. Пакет установлен и настроен по инструкции c учётом:

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

Маршруты появились:

============ OSPF network routing table ============
N 10.10.9.2/32 [10] area: 1.1.1.1
directly attached to ovpns3
N 10.13.9.2/32 [20] area: 1.1.1.1
directly attached to ovpns6
N 192.168.0.0/24 [10] area: 1.1.1.1
directly attached to re0
N 192.168.4.0/24 [20] area: 1.1.1.1
via 10.10.9.2, ovpns3

============ OSPF router routing table =============

============ OSPF external routing table ===========

Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, A - Babel,
> - selected route, * - FIB route

K>* 0.0.0.0/0 via 95.66.187.52, pppoe0
K>* 8.8.4.4/32 via 84.53.192.2, pppoe1
K>* 8.8.8.8/32 via 95.66.187.52, pppoe0
K>* 10.2.2.0/24 via 10.9.9.2, ovpns2
K>* 10.8.0.0/24 via 10.8.0.2, ovpns1
C>* 10.8.0.2/32 is directly connected, ovpns1
C>* 10.9.9.2/32 is directly connected, ovpns2
O 10.10.9.2/32 [110/10] is directly connected, ovpns3, 15:55:42
C>* 10.10.9.2/32 is directly connected, ovpns3
C>* 10.11.9.2/32 is directly connected, ovpns4
C>* 10.12.9.2/32 is directly connected, ovpns7
O 10.13.9.2/32 [110/20] is directly connected, ovpns6, 15:55:42
C>* 10.13.9.2/32 is directly connected, ovpns6
C>* 10.14.9.2/32 is directly connected, ovpns5
C>* 84.53.192.2/32 is directly connected, pppoe1
K>* 84.53.199.254/32 via 84.53.192.2, pppoe1
K>* 84.53.200.24/32 via 84.53.192.2, pppoe1
C>* 95.66.187.52/32 is directly connected, pppoe0
K>* 95.66.187.247/32 via 95.66.187.52, pppoe0
K>* 95.66.188.11/32 via 95.66.187.52, pppoe0
C>* 127.0.0.0/8 is directly connected, lo0
O 192.168.0.0/24 [110/10] is directly connected, re0, 15:55:42
C>* 192.168.0.0/24 is directly connected, re0
K>* 192.168.2.0/24 via 10.14.9.2, ovpns5
O>* 192.168.4.0/24 [110/20] via 10.10.9.2, ovpns3, 15:55:33

10.10.9.1 link#16 UHS 0 0 16384 lo0
10.10.9.2 link#16 UH 0 0 1500 ovpns3

10.13.9.1 link#17 UHS 0 0 16384 lo0
10.13.9.2 link#17 UH 0 0 1500 ovpns6

192.168.4.0/24 10.10.9.2 UG1 0 52389 1500 ovpns3

И вот в чём возникла загвоздка: с филиала в сеть офиса доступ есть, а вот наоборот по разному.
После поднятия ospf: С офиса был доступен(ping) сервер филиала 192.168.4.2, но не был доступен(ping) voip шлюз 192.168.4.3
После перезагрузки pfsense офиса и филиала сервер 192.168.4.2 стал не доступен(ping), но стал доступен(ping) voip шлюз 192.168.4.3.
Делаю tracert до 192.168.4.2 и первый хоп сразу уходит на шлюз провайдера.

Правила для обоих pfsense одинаковы: правило для Lan - разрешено все, правило для OpenVpn - разрешено все.
Установлена галка - Load Balancing * Allow default gateway switching

01.jpg_thumb

werter

1. Зачем два канала между одними и теми же точками ?

2.

Правила для обоих pfsense одинаковы: правило для Lan - разрешено все, правило для OpenVpn - разрешено все.

Этого мало. Необходимо создать на LAN отдельное правило, где в source - lan subnet , а в dest - сеть за openvpn-клиентом. Возможно, что и указать явно Gateway прийдется.
Далее, директиву iroute прописывали в Client Specific overrides ? Иначе сеть клиента не будет доступна из сети сервера.

И еще. Ospf - это замечательно, но если маршрутов немного, может обойтись директивами route\push route\iroute на сервере\клиенте?

Upd. Как вариант - исп. IPsec + OSPF.

aka_daemon

1. Зачем два канала между одними и теми же точками ?

филиал должен при падении одного из каналов в головном офисе автоматически переключаться на другой, компы офиса и филиала должны видеть друг-друга.
вроде для этого и надо поднимать 2 экземпляра openvpn сервера(гл. офис) и 2 экземпляра openvpn клиента(филиал).

Необходимо создать на LAN отдельное правило, где в source - lan subnet , а в dest - сеть за openvpn-клиентом.

по поводу правила-попробую ваш вариант.

по инструкции rubic рекомендует

Ни в головном офисе, ни в филиале на серверах и клиентах не прописаны ни Remote Network, ни какие-либо route.

если не ошибаюсь, то Client Specific overrides нет при создании openvpn в режиме PSK.

если маршрутов немного, может обойтись директивами route\push route\iroute на сервере\клиенте

дело в том, что филиалы будут добавляться.

если отбросить ospf, то все прекрасно работает: организована связь глав. офиса и 3х филиалов и филиалы видят гл. офис и друг друга.

если на сервере и клиентах openvpn прописывать remote network и route(для обеспечения связи между филиалами) и использовать ospf, то по истечении нек. времени основной openvpn канал падает и его перезапуск не помогает.

aka_daemon

заметил одну особенность в правилах Firewall, вкладка LAN:
если в основном правиле(отмечено красным) поменять поле Gateway с multiwan на default, то при реализации ospf сеть филиала доступна.
но в основном правиле LAN, в поле Gateway рекомендуют выставлять группу шлюзов для обеспечения отказоустойчивости при падении одного из каналов.
если в основном правиле(отмечено красным) оставить поле Gateway со значением multiwan и создать новое правило(отмечено зеленым) со значением Gateway - default, то сеть филиала тоже доступна.

Правильна ли такая реализация с точки зрения корректности?

02.jpg_thumb

rubic

Так и должно быть. Красное правило с gateway - это policy routing, который не принимает во внимание системные маршруты (gateway-то уже указан), а зеленое - наоборот действует по системной таблице маршрутов. Оставляйте оба и именно в этом порядке.

aka_daemon

спасибо, что разъяснили. тему можно закрывать.