проблема у клиента при доступе к филиалу



  • Доброго дня уважаемые.
    Есть два офиса, которые подключены между собой по openvpn(см. картинку) и есть моб. клиенты.
    Резервирование каналов vpn организовано средствами ospf
    Клиент, подключается к Off1 по W1 или по W2 , имеет доступ к ресурсам обоих офисов.
    Если у Off2 падает W1, то клиент на видит ресурсов Off2, но офисы видят ресурсы друг друга(при пропадании туннелей 10.2.0.0/30 и 10.3.0.0/30 офисы видят друг друга по туннелям 10.8.0.0/30 и 10.9.0.0/30 и на оборот).
    В таблице маршрутов у Off2 для сети 10.1.0.0/24 шлюзом остаётся 10.2.0.1 либо 10.3.0.1, хотя должен быть 10.8.0.1 либо 10.9.0.1
    В Firewall: Rules для закладки OpenVpn разрешено все для обоих шлюзов, для закладки LAN правило разрешающее трафик из Lan Net Off1 в локальную сеть Off2
    Как вариант: поможет ли добавление интерфейса openvpn сервера для клиентов в ospf, либо добавить сеть клиента 10.1.0.0/24 в правило разрешающее трафик из Lan Net Off1 в локальную сеть Off2




  • Доброе.
    У офисов по 2 WAN, но openvpn-линков - 4. Перестраховались ?
    Попробуйте оставить только два линка - оф 1 wan 1 <-> оф 2 wan 1 и оф 1 wan 2 <-> оф 2 wan 2.

    P.s.. Я так понимаю, что впн у Вас p2p ? А если попробовать с клиент-серверной версией ? Причем настроить оф1 wan 1 server <-> оф2 wan 1 client и
    наоборот - оф2 wan 2 server  <-> оф1 wan 2 client.



  • У офисов по 2 WAN, но openvpn-линков - 4. Перестраховались ?

    :) Именно так, решили сделать полное резервирование.

    Попробуйте оставить только два линка - оф 1 wan 1 <-> оф 2 wan 1 и оф 1 wan 2 <-> оф 2 wan 2.

    Пробовали и такое решение: при пропадании W1 у Off2, клиент не видит ресурсов филиала.

    Вы правильно предположили, openvpn работает в режиме p2p. Забыл указать при описании схемы.

    А если попробовать с клиент-серверной версией ? Причем настроить оф1 wan 1 server <-> оф2 wan 1 client и
    наоборот - оф2 wan 2 server  <-> оф1 wan 2 client.

    Ваш вариант заманчив, приму его к сведению.
    Хотелось бы понять причину, почему не работает изначальная схема, ведь она скорей всего работоспособна,
    но причина неудачи кроется либо в правилах Firewall либо в OSPF.
    Вот и ломаю голову, пытаясь понять причину.



  • @aka_daemon:

    У офисов по 2 WAN, но openvpn-линков - 4. Перестраховались ?

    :) Именно так, решили сделать полное резервирование.

    Перемудрили. Оставляйте 2 openvpn-линка. Этого вполне достаточно.



  • Как вариант, если не требуется большая скорость схождения можно попытаться использовать вместо ip  адресов DNS записи.
    Да и у ospf есть недостаток — он перестраивает таблицы если видит прямое падение линка. А иначе таймаут вроде около 2-х минут.



  • @werter:

    Перемудрили. Оставляйте 2 openvpn-линка. Этого вполне достаточно.

    Оставил два vpn линка, т.е.: off1 w1 <–--10.2.0.0/30-----off2 w1 и off1 w2 <----10.3.0.0/30-----off2 w2.

    В таблице маршрутов off2: офисы соединены по линку 10.2.0.0/30, для сети openvpn клиента 10.1.0.0/24 линком является 10.3.0.0/30.

    Произвёл отключение w1 у off2, сети между офисами стали общаться по линку 10.3.0.0/24 по нему же удалённый клиент видит ресурсы off2.

    Отключаю w2 у off2, сети между офисами стали общаться по линку 10.2.0.0/30, но в таблице маршрутов off2 для сети 10.1.0.0/24(сеть для удалённых клиентов) линк просто отсутствует, хотя должен быть 10.2.0.0/30



  • Доброе.
    Покажите таблицы мар-ции обоих концов при 2 линках и таблицы при одном упавшем.



  • @werter:

    Доброе.
    Покажите таблицы мар-ции обоих концов при 2 линках и таблицы при одном упавшем.






  • Вар. Б :

    Оставить один линк с клиента на сервер.
    В настройках клиента в Адвансед указать второй remote:

    remote WAN2-пф-сервера1 порт протокол

    Т.о., впн-линк один, но при падении первого линка клиент будет переподкл. ко второму.
    И там же в Адвансед клиента что-то типа :

    keepalive 5 10
    ping-timer-rem
    pull
    verb 5



  • В Off2 убирайте статический маршрут в сеть 10.1.0.0/30, в Off1 добавляйте интерфейс(ы) OpenVPN мобильных клиентов в OSPF в качестве Passive



  • @werter:

    Вар. Б :

    Оставить один линк с клиента на сервер.
    В настройках клиента в Адвансед указать второй remote:

    remote WAN2-пф-сервера1 порт протокол

    Т.о., впн-линк один, но при падении первого линка клиент будет переподкл. ко второму.
    И там же в Адвансед клиента что-то типа :

    keepalive 5 10
    ping-timer-rem
    pull
    verb 5

    @rubic:

    В Off2 убирайте статический маршрут в сеть 10.1.0.0/30, в Off1 добавляйте интерфейс(ы) OpenVPN мобильных клиентов в OSPF в качестве Passive

    Огромное спасибо за ваши советы, обязательно попробую оба варианта и отпишусь.



  • @rubic:

    В Off2 убирайте статический маршрут в сеть 10.1.0.0/30, в Off1 добавляйте интерфейс(ы) OpenVPN мобильных клиентов в OSPF в качестве Passive

    попробовал ваш вариант, у удалённого клиента доступ в сеть 10.2.2.0 вообще пропал(не проходит пинг, не доступен rdp и прочие ресурсы).

    добавил интерфейс обслуживающий удалённых клиентов в ospf, сделав его "Passive", у филиала(Off2) для обоих линков openvpn убрал статический маршрут в сеть 10.1.0.0/24

    На Off1 добавил в правило для ospf сеть 10.1.0.0/24(см.картинку), такое же правило на стороне Off2

    Получаю отказ.

    И затерзали меня смутные сомнения в правильности настройки openvpn для клиентов. так как у меня 2wan, то мне пришлось сделать след. образом: в настройках сервера для клиентов интерфейсом указан "LocalHost", сделан проброс порта 1194 с WAN1-2 на 127.0.0.1 и в настройках vpn сервера Advanced configuration указаны маршруты в другие сети: push "route 192.168.2.0 255.255.255.0";push "route 192.168.4.0 255.255.255.0";push "route 10.2.2.0 255.255.255.0"

    Убирая маршруты push "route 192.168.2.0 255.255.255.0";push "route 192.168.4.0 255.255.255.0";push "route 10.2.2.0 255.255.255.0"  с сервера для клиентов, получаю вообще забавную картину по утилите tracert: вторым хопом после 10.1.0.1 идёт вообще 10.33.0.1 и дальше "Превышен интервал ожидания для запроса"

    Не происходят ли проблемы из-за такой настройки???






  • @aka_daemon:

    так как у меня 2wan, то мне пришлось сделать след. образом: в настройках сервера для клиентов интерфейсом указан "LocalHost", сделан проброс порта 1194 с WAN1-2 на 127.0.0.1

    Не представляю как это может работать, и дело совсем не в  OSPF, а во внутренней маршрутизации OpenVPN в режимах SSL/TLS (см. Status: OpenVPN > Show Routing Table на сервере). Если у вас один сервер в Off1 и два клиента в Off2, то чтобы Off1 видел локальную сеть Off2 вы на сервере должны были указать локальную сеть Off2 в Client Specific Overrides для каждого клиента (см. IPv4 Remote Network/s - аналог iroute). Без этого связи не будет независимо от системных маршрутов pfSense.

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



  • @rubic:

    @aka_daemon:

    так как у меня 2wan, то мне пришлось сделать след. образом: в настройках сервера для клиентов интерфейсом указан "LocalHost", сделан проброс порта 1194 с WAN1-2 на 127.0.0.1

    Не представляю как это может работать, и дело совсем не в  OSPF, а во внутренней маршрутизации OpenVPN в режимах SSL/TLS (см. Status: OpenVPN > Show Routing Table на сервере). Если у вас один сервер в Off1 и два клиента в Off2, то чтобы Off1 видел локальную сеть Off2 вы на сервере должны были указать локальную сеть Off2 в Client Specific Overrides для каждого клиента (см. IPv4 Remote Network/s - аналог iroute). Без этого связи не будет независимо от системных маршрутов pfSense.

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

    при создании vpn для удалённых клиентов руководствовался этой статьёй - https://doc.pfsense.org/index.php/Multi-WAN_OpenVPN.

    на шлюзе Off1 подняты два vpn сервера 10.2.0.0 и 10.3.0.0, на шлюзе Off2 подняты два клиента до Off1 для резервирования. режим работы vpn - p2p.

    Off1(192.168.0.0/24)<–--10.2.0.0/30------Off2(10.2.2.0/24)
    Off1(192.168.0.0/24)<----10.3.0.0/30------Off2(10.2.2.0/24)

    Удалённый клиент подключается либо к wan1 off1 либо к wan2 off1 в зависимости от доступности оных, получает ip из сети 10.1.0.0/24 и маршруты в сети филиалов, к примеру 10.2.2.0/24.

    при этом в ospf на Off1:

    
    ============ OSPF network routing table ============
    N    10.1.0.2/32           [10] area: 1.1.1.1
                               directly attached to ovpns7
    N    10.2.0.2/32           [10] area: 1.1.1.1
                               directly attached to ovpns1
    N    10.2.2.0/24           [20] area: 1.1.1.1
                               via 10.2.0.2, ovpns1
    N    10.3.0.2/32           [20] area: 1.1.1.1
                               directly attached to ovpns2
    N    10.4.0.2/32           [10] area: 1.1.1.1
                               directly attached to ovpns3
    N    10.5.0.2/32           [20] area: 1.1.1.1
                               directly attached to ovpns4
    N    10.6.0.2/32           [10] area: 1.1.1.1
                               directly attached to ovpns5
    N    10.7.0.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 re1
    N    192.168.2.0/24        [20] area: 1.1.1.1
                               via 10.4.0.2, ovpns3
    N    192.168.4.0/24        [20] area: 1.1.1.1
                               via 10.6.0.2, ovpns5
    
    
    
    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 31.28.192.1, pppoe0
    K>* 10.1.0.0/24 via 10.1.0.2, ovpns7
    O   10.1.0.2/32 [110/10] is directly connected, ovpns7, 13:46:48
    C>* 10.1.0.2/32 is directly connected, ovpns7
    O   10.2.0.2/32 [110/10] is directly connected, ovpns1, 13:46:48
    C>* 10.2.0.2/32 is directly connected, ovpns1
    O>* 10.2.2.0/24 [110/20] via 10.2.0.2, ovpns1, 02:29:57
    O   10.3.0.2/32 [110/20] is directly connected, ovpns2, 13:46:48
    C>* 10.3.0.2/32 is directly connected, ovpns2
    O   10.4.0.2/32 [110/10] is directly connected, ovpns3, 13:46:48
    C>* 10.4.0.2/32 is directly connected, ovpns3
    O   10.5.0.2/32 [110/20] is directly connected, ovpns4, 13:46:48
    C>* 10.5.0.2/32 is directly connected, ovpns4
    O   10.6.0.2/32 [110/10] is directly connected, ovpns5, 13:46:48
    C>* 10.6.0.2/32 is directly connected, ovpns5
    O   10.7.0.2/32 [110/20] is directly connected, ovpns6, 13:46:48
    C>* 10.7.0.2/32 is directly connected, ovpns6
    C>* 127.0.0.0/8 is directly connected, lo0
    O   192.168.0.0/24 [110/10] is directly connected, re1, 13:46:48
    C>* 192.168.0.0/24 is directly connected, re1
    O>* 192.168.2.0/24 [110/20] via 10.4.0.2, ovpns3, 13:46:43
    O>* 192.168.4.0/24 [110/20] via 10.6.0.2, ovpns5, 13:46:35
    
    

    в таблице маршрутов Off1:

    
    10.1.0.0/24	10.1.0.2	UGS	30463	1500	ovpns7
    10.1.0.1	link#16	UHS	0	16384	lo0
    10.1.0.2	link#16	UH	90	1500	ovpns7
    
    

    при этом в ospf на Off2:

    
    ============ OSPF network routing table ============
    N    10.1.0.2/32           [20] area: 1.1.1.1
                               via 10.2.0.1, ovpnc2
    N    10.2.0.1/32           [10] area: 1.1.1.1
                               directly attached to ovpnc2
    N    10.2.2.0/24           [10] area: 1.1.1.1
                               directly attached to rl0
    N    10.3.0.1/32           [20] area: 1.1.1.1
                               directly attached to ovpnc1
    N    10.4.0.1/32           [30] area: 1.1.1.1
                               via 10.2.0.1, ovpnc2
    N    10.4.0.2/32           [20] area: 1.1.1.1
                               via 10.2.0.1, ovpnc2
    N    10.5.0.1/32           [40] area: 1.1.1.1
                               via 10.2.0.1, ovpnc2
    N    10.5.0.2/32           [30] area: 1.1.1.1
                               via 10.2.0.1, ovpnc2
    N    10.6.0.1/32           [30] area: 1.1.1.1
                               via 10.2.0.1, ovpnc2
    N    10.6.0.2/32           [20] area: 1.1.1.1
                               via 10.2.0.1, ovpnc2
    N    10.7.0.1/32           [40] area: 1.1.1.1
                               via 10.2.0.1, ovpnc2
    N    10.7.0.2/32           [30] area: 1.1.1.1
                               via 10.2.0.1, ovpnc2
    N    192.168.0.0/24        [20] area: 1.1.1.1
                               via 10.2.0.1, ovpnc2
    N    192.168.2.0/24        [30] area: 1.1.1.1
                               via 10.2.0.1, ovpnc2
    N    192.168.4.0/24        [30] area: 1.1.1.1
                               via 10.2.0.1, ovpnc2
    
    
    
    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 10.2.1.1, rl1
    K>* 8.8.8.8/32 via 10.2.1.1, rl1
    O>* 10.1.0.2/32 [110/20] via 10.2.0.1, ovpnc2, 02:33:47
    O   10.2.0.1/32 [110/10] is directly connected, ovpnc2, 02:33:52
    C>* 10.2.0.1/32 is directly connected, ovpnc2
    C>* 10.2.1.0/24 is directly connected, rl1
    K * 10.2.1.1/32 via 10.2.1.1 inactive
    O   10.2.2.0/24 [110/10] is directly connected, rl0, 02:33:52
    C>* 10.2.2.0/24 is directly connected, rl0
    O   10.3.0.1/32 [110/20] is directly connected, ovpnc1, 02:33:52
    C>* 10.3.0.1/32 is directly connected, ovpnc1
    O>* 10.4.0.1/32 [110/30] via 10.2.0.1, ovpnc2, 02:33:47
    O>* 10.4.0.2/32 [110/20] via 10.2.0.1, ovpnc2, 02:33:47
    O>* 10.5.0.1/32 [110/40] via 10.2.0.1, ovpnc2, 02:33:47
    O>* 10.5.0.2/32 [110/30] via 10.2.0.1, ovpnc2, 02:33:47
    O>* 10.6.0.1/32 [110/30] via 10.2.0.1, ovpnc2, 02:33:47
    O>* 10.6.0.2/32 [110/20] via 10.2.0.1, ovpnc2, 02:33:47
    O>* 10.7.0.1/32 [110/40] via 10.2.0.1, ovpnc2, 02:33:47
    O>* 10.7.0.2/32 [110/30] via 10.2.0.1, ovpnc2, 02:33:47
    C>* 127.0.0.0/8 is directly connected, lo0
    O>* 192.168.0.0/24 [110/20] via 10.2.0.1, ovpnc2, 02:33:47
    O>* 192.168.2.0/24 [110/30] via 10.2.0.1, ovpnc2, 02:33:47
    O>* 192.168.4.0/24 [110/30] via 10.2.0.1, ovpnc2, 02:33:47
    
    

    в таблице маршрутов Off2:

    
    10.1.0.2	10.2.0.1	UGH1	0	81	1500	ovpnc2
    
    

    меня очень смущает вот что:

    
    K>* 10.1.0.0/24 via 10.1.0.2, ovpns7
    
    

    Ведь когда у Off2 в vpn клиенте до Off1 был прописан статический маршрут в сеть 10.1.0.0/24, удалённый клиент видел сеть 10.2.2.0/24
    Следуя вашему совету и логике ospf, маршруты я убрал.



  • @aka_daemon:

    режим работы vpn - p2p.

    Shared key или SSL/TLS?



  • @rubic:

    @aka_daemon:

    режим работы vpn - p2p.

    Shared key или SSL/TLS?

    Shared Key



  • 2 aka_daemon

    при создании vpn для удалённых клиентов руководствовался этой статьёй - https://doc.pfsense.org/index.php/Multi-WAN_OpenVPN.

    Спасибо за ссылку. Как раз мой случай с неск. WAN.
    Только я в настр. сервера в Interface выбирал

    any

    . Так вот с TCP это на обоих WAN работало, а вот с UDP - нет.



  • @aka_daemon:

    в таблице маршрутов Off1:

    
    10.1.0.0/24   10.1.0.2   UGS   30463   1500   ovpns7
    10.1.0.1   link#16   UHS   0   16384   lo0
    10.1.0.2   link#16   UH   90   1500   ovpns7
    
    

    Это хрень какая-то. Должно быть:

    
    10.1.0.0/24   10.1.0.1   UGS   30463   1500   ovpns7
    10.1.0.1   link#16   UHS   0   16384   lo0
    10.1.0.2   link#16   UH   90   1500   ovpns7
    
    

    В каком режиме подключаются мобильные клиенты (Road warriors, давайте уж называть их так, чтобы не путаться)?
    Ваш сетап очень простой. В обоих офисах в Services: Quagga OSPFd > Global Settings заполнить только Master Password, Router ID и Area

    В Off1 в Services: Quagga OSPFd > Interface Settings должны быть:

    Interface: LAN, Area, Interface is Passive
    Interface: ovpns1, [Metric] Area
    Interface: ovpns2, [Metric] Area
    Interface: ovpns7, Area, Interface is Passive

    В Off1 в Services: Quagga OSPFd > Interface Settings должны быть:

    Interface: LAN, Area, Interface is Passive
    Interface: ovpnc1, [Metric] Area
    Interface: ovpnc2, [Metric] Area

    Area везде одна, никаких статических маршрутов в соседние сети, push "route…" верните для Road warriors



  • Режим работы RoadWarrior(мобильные клиенты) см. картинку

    Прошёлся ещё раз по настройкам ospf обоих шлюзов, все так же как вы советуете.

    Quagga OSPFd > Global Settings заполнить только Master Password, Router ID и Area

    В Off1 в Services: Quagga OSPFd > Interface Settings должны быть:

    Interface: LAN, Area, Interface is Passive
    Interface: ovpns1, [Metric] Area
    Interface: ovpns2, [Metric] Area
    Interface: ovpns7, Area, Interface is Passive

    В Off1 в Services: Quagga OSPFd > Interface Settings должны быть:

    Interface: LAN, Area, Interface is Passive
    Interface: ovpnc1, [Metric] Area
    Interface: ovpnc2, [Metric] Area

    Area везде одна, никаких статических маршрутов в соседние сети, push "route…" верните для Road warriors

    off1:

    
    # This file was created by the pfSense package manager.  Do not edit!
    
    password ***
    log syslog
    interface re1
    interface ovpns1
      ip ospf cost 10
    interface ovpns2
      ip ospf cost 20
    interface ovpns7
    
    router ospf
      ospf router-id 0.0.0.1
      passive-interface re1
      passive-interface ovpns7
      network 192.168.0.0/24 area 1.1.1.1
      network 10.2.0.0/30 area 1.1.1.1
      network 10.3.0.0/30 area 1.1.1.1
    
    

    off2:

    
    # This file was created by the pfSense package manager.  Do not edit!
    
    password ***
    log syslog
    interface rl0
    interface ovpnc2
      ip ospf cost 10
    interface ovpnc1
      ip ospf cost 20
    
    router ospf
      ospf router-id 0.0.0.4
      passive-interface rl0
      network 10.2.2.0/24 area 1.1.1.1
      network 10.2.0.0/30 area 1.1.1.1
      network 10.3.0.0/30 area 1.1.1.1
    
    




  • В настройках OpenVPN сервера для Road warrios поставьте галку в чекбоксе "Topology". Вот так у вас должно быть в Off1 (см. последнюю строчку)

    # This file was created by the pfSense package manager.  Do not edit!
    
    password ***
    log syslog
    interface re1
    interface ovpns1
      ip ospf cost 10
    interface ovpns2
      ip ospf cost 20
    interface ovpns7
    
    router ospf
      ospf router-id 0.0.0.1
      passive-interface re1
      passive-interface ovpns7
      network 192.168.0.0/24 area 1.1.1.1
      network 10.2.0.0/30 area 1.1.1.1
      network 10.3.0.0/30 area 1.1.1.1
      network 10.1.0.0/24 area 1.1.1.1
    
    


  • Спасибо всем, кто оказал помощь в решении данной проблемы.
    Решение

    В настройках OpenVPN сервера для Road warrios поставьте галку в чекбоксе "Topology"

    , подсказанное rubic, оказалось правильным.
    Прошу закрыть тему.



  • Я уже писал, что в режимах SSL/TLS topology subnet обязательна для использования OSPF. В новых версиях она, похоже, будет топологией по умолчанию.