multicast в pptp

[bzzztomas77]

добрый день,

пытаюсь поднять bird для динамической маршрутизации.

два кинетика (giga - сервер, viva - клиент). на giga pptp сервер поднят, клиент viva к нему подключен штатным pptp клиентом, все пингуется. интерфейсы приватные.

запускаю bird в минимальной конфигурации, по логам вижу, что интефейсы находит, обе стороны посылают ospf hello, эти hello вижу на обоих сторонах в tcpdump.

 

bird со стороны pptp клиента получает пакеты:

Quote

2025-08-28 12:48:22.342 <TRACE> ospf1: HELLO packet received from nbr 192.168.1.1 on ppp2

а со стороны pptp сервера нет их, только видно что шлет..

в tcpdump со стороны сервера вот так это выглядит:

Quote

12:49:08.276622 IP (tos 0xc0, ttl 255, id 41923, offset 0, flags [none], proto OSPF (89), length 68)
    192.168.13.3 > 224.0.0.5: OSPFv2, Hello, length 48
    Router-ID 192.168.3.1, Backbone Area, Authentication Type: none (0)
    Options [External]
      Hello Timer 10s, Dead Timer 40s, Mask 0.0.0.0, Priority 1
      Neighbor List:
        192.168.1.1
 

может быть какой-то фильтр на стороне сервера?

 

[Le ecureuil]

55 минут назад, bzzztomas77 сказал:

добрый день,

пытаюсь поднять bird для динамической маршрутизации.

два кинетика (giga - сервер, viva - клиент). на giga pptp сервер поднят, клиент viva к нему подключен штатным pptp клиентом, все пингуется. интерфейсы приватные.

запускаю bird в минимальной конфигурации, по логам вижу, что интефейсы находит, обе стороны посылают ospf hello, эти hello вижу на обоих сторонах в tcpdump.

 

bird со стороны pptp клиента получает пакеты:

а со стороны pptp сервера нет их, только видно что шлет..

в tcpdump со стороны сервера вот так это выглядит:

может быть какой-то фильтр на стороне сервера?

 

Посмотрите по счетчикам в таблице filter в netfilter. Точнее сказать будет сложно.

[bzzztomas77]

если поднимается nwg0, то через него доходят ospf hello, а через pptp - нет.

странная фигня... на pptp-сервере:

Quote

2025-08-28 15:33:50.357 <TRACE> ospf1: HELLO packet sent via nwg0
2025-08-28 15:33:50.357 <TRACE> ospf1: HELLO packet sent via vpn0
2025-08-28 15:33:51.302 <TRACE> ospf1: HELLO packet received from nbr 192.168.3.1 on nwg0
2025-08-28 15:34:00.357 <TRACE> ospf1: HELLO packet sent via nwg0
2025-08-28 15:34:00.357 <TRACE> ospf1: HELLO packet sent via vpn0
2025-08-28 15:34:01.301 <TRACE> ospf1: HELLO packet received from nbr 192.168.3.1 on nwg0

 

на pptp-клиенте:

Quote

2025-08-28 15:34:03.564 <TRACE> ospf1: HELLO packet sent via nwg0
2025-08-28 15:34:03.564 <TRACE> ospf1: HELLO packet sent via ppp2
2025-08-28 15:34:12.633 <TRACE> ospf1: HELLO packet received from nbr 192.168.1.1 on ppp2
2025-08-28 15:34:13.564 <TRACE> ospf1: HELLO packet sent via nwg0
2025-08-28 15:34:13.564 <TRACE> ospf1: HELLO packet sent via ppp2
2025-08-28 15:34:22.633 <TRACE> ospf1: HELLO packet received from nbr 192.168.1.1 on ppp2

 

как будто с каждой стороны только по одному каналу проходит multicast

Quote

Посмотрите по счетчикам в таблице filter в netfilter. Точнее сказать будет сложно.

iptables -t filter -L -nv ?

[bzzztomas77]

и правда multicast не проходит, но непонятно почему

Quote

(config)> show vpn-server 

           tunnel: 
           session-id: 2
        clientaddress: 192.168.13.3
             username: pptpsp
               uptime: 10127

            statistic: 
                    rxpackets: 28889
         rx-multicast-packets: 0
         rx-broadcast-packets: 0
                      rxbytes: 29113488
                     rxerrors: 0
                    rxdropped: 0
                    txpackets: 19673
         tx-multicast-packets: 0
         tx-broadcast-packets: 0
 

 

[Le ecureuil]

Вообще довольно странная ситуация, так как у нас уже кучу лет есть опция DLNA-через-VPN, и она работает, хотя полагается на мультикаст.

[bzzztomas77]

2 hours ago, Le ecureuil said:

Вообще довольно странная ситуация, так как у нас уже кучу лет есть опция DLNA-через-VPN, и она работает, хотя полагается на мультикаст.

через openvpn?

а интерфейс vpn0 (со стороны openvpn сервера) - он private?

в сторону pptp-клиента мультикаст проходит, в обратную сторону - нет.

 

обратил внимание на пару моментов:

1) в iptable мультикаст разрешен для udp, но ospf - это протокол уровня ip (type 89):

Quote

#  iptables -t filter -L -n -v|head -n 20
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  149 85705 _NDM_MULTICAST_INPUT  udp  --  *      *       0.0.0.0/0            224.0.0.0/4         
    6   192 ACCEPT     2    --  *      *       0.0.0.0/0            0.0.0.0/0           
 

2) для openvpn сервера нет вкладки в Firewall, хотел там разрешить все

 

продолжаю флудить.. пардон. вот это помогло:

Quote

iptables -I _NDM_PPTPSRVVPN_IN 1 -j ACCEPT

 

Изменено 28 августа пользователем bzzztomas77

[bzzztomas77]

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

 

[Le ecureuil]

В 28.08.2025 в 17:38, bzzztomas77 сказал:

в iptable мультикаст разрешен для udp, но ospf - это протокол уровня ip (type 89):

Это все меняет. Тогда вам в entware нужно сделать скрипт который по событию netfilter.d будет возвращать эту запись.

[bzzztomas77]

20 minutes ago, Le ecureuil said:

Это все меняет. Тогда вам в entware нужно сделать скрипт который по событию netfilter.d будет возвращать эту запись.

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

if [[ $iface == *vpn* ]]; then
    iptables -A _NDM_ACL_IN -i $iface -d 224.0.0.5 -p 89 -j ACCEPT
fi

 

Изменено 4 сентября пользователем bzzztomas77

[Le ecureuil]

2 часа назад, bzzztomas77 сказал:

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

if [[ $iface == *vpn* ]]; then
    iptables -A _NDM_ACL_IN -i $iface -d 224.0.0.5 -p 89 -j ACCEPT
fi

 

Нет же, почему просто по форуму не поискать для примера?

#!/bin/sh

[ "$type" != "iptables" ] && exit 0   # 'iptables' or 'ip6tables'
[ "$table" != "filter" ] && exit 0   # 'filter', 'nat', 'mangle'

iptables -A _NDM_ACL_IN -i vpn+ -d 224.0.0.5 -p 89 -j ACCEPT

 

[bzzztomas77]

2 minutes ago, Le ecureuil said:

Нет же, почему просто по форуму не поискать для примера?

хорошо, спасибо, но его же потом и удалять нужно, а если несколько vpn интерфейсов? в iptables есть подобие refcount ?

[avn]

1 час назад, Le ecureuil сказал:

Нет же, почему просто по форуму не поискать для примера?

#!/bin/sh

[ "$type" != "iptables" ] && exit 0   # 'iptables' or 'ip6tables'
[ "$table" != "filter" ] && exit 0   # 'filter', 'nat', 'mangle'

iptables -A _NDM_ACL_IN -i vpn+ -d 224.0.0.5 -p 89 -j ACCEPT

 

Когда появится для v6?

_NDM_ACL_IN 

[Le ecureuil]

19 часов назад, avn сказал:

Когда появится для v6?

_NDM_ACL_IN 

Не сегодня и не завтра.

[Le ecureuil]

20 часов назад, bzzztomas77 сказал:

хорошо, спасибо, но его же потом и удалять нужно, а если несколько vpn интерфейсов? в iptables есть подобие refcount ?

Удалять не нужно, само произойдет.

vpn+ как раз значает "любой интерфейс с префиксом vpn", а это как раз префикс для клиентов от pptp-сервера и только их.

[bzzztomas77]

4 minutes ago, Le ecureuil said:

Удалять не нужно, само произойдет.

vpn+ как раз значает "любой интерфейс с префиксом vpn", а это как раз префикс для клиентов от pptp-сервера и только их.

про vpn+ я понимаю. а почему само удалится и когда? если несколько vpn интерфейсов в разное время бывает, это правило удалится только после удаления последнего vpn?

 

[Le ecureuil]

В 05.09.2025 в 10:43, bzzztomas77 сказал:

про vpn+ я понимаю. а почему само удалится и когда? если несколько vpn интерфейсов в разное время бывает, это правило удалится только после удаления последнего vpn?

 

Потому что любое изменение правил со стороны KeeneticOS вызывает их удаление. Фактически правила не модифицируются, а полностью заменяются на новые.