4.0.6, Wireguard: шторм исходящих пакетов при наличии двух рабочих WG-интерфейсов

[vasek00]

Появилась (или была ранее на 4.x) старая болячка "флуд на WG" по описанному п.3 т.е. 

- основной канал PPPoE поднят и он основной

- WG канал в резерве

отключаю основной канал PPPoE на и WG появляется "флуд"

Скрытый текст

под wifi клиентом на WEB роутера не войти, под LAN клиентом без проблем. После восстановления каналов интернета - клиент wifi основного bridge0 сегмента без проблем подключился, почему основного потому что есть доп. сегмент bridge1 с wifi 2.4 и своими клиентами, но про них речь уже ниже.

 

******

Так же заметил проблему после такого эксперимента с октлючением PPPoE канала и флудом на WG. Есть доп.сегмент wifi 2.4 для умного дома и чуток клиентов. Так после описанной выше "болячки" когда все поднялось PPPoE/WG и клиент wifi основного сегмента подключился без проблем, то клиенты доп.сегмента bridge1 умного дома отказались подключаться (в этом сегменте только wifi 2.4 клиенты). Пришлось передернуть Wifi данного сегмента (вкл/выкл.) тогда один клиент подключился сразу же (марка всех одинакова), а другие курили. 

Фев 4 08:36:07 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) had deauthenticated by AP (reason: PTK 4-way handshake timeout).
Фев 4 08:36:12 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:99) had associated successfully.
Фев 4 08:36:12 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) had associated successfully.
Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:99) pairwise key handshaking timeout (msg 1 of 4-way). 
Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:99) had deauthenticated by AP (reason: PTK 4-way handshake timeout). 
Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) pairwise key handshaking timeout (msg 1 of 4-way). 
Фев 4 08:36:18 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(....:5f) had deauthenticated by AP (reason: PTK 4-way handshake timeout). 

через некоторое время еще одному удалось подключиться

Фев 4 08:38:06 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(......:5f) set key done in WPA2/WPA2PSK.
Фев 4 08:38:06 ndhcps DHCPDISCOVER received from .....:5f.
Фев 4 08:38:06 ndhcps making OFFER of 192.168.150.4 to .....:5f.
Фев 4 08:38:06 ndhcps DHCPREQUEST received (STATE_SELECTING) for 192.168.150.4 from ....:5f.
Фев 4 08:38:06 ndm Netfilter::Util::Conntrack: flushed 52 IPv4 connections.
Фев 4 08:38:06 ndhcps sending ACK of 192.168.150.4 to ......:5f.
Фев 4 08:38:07 ndhcps DHCPREQUEST received (STATE_SELECTING) for 192.168.150.4 from ....:5f.
Фев 4 08:38:08 ndhcps sending ACK of 192.168.150.4 to .....:5f.
Фев 4 08:38:08 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(.......:99) had associated successfully. 

с момента первой записи о проблеме на клиентах

Подъем каналов - PPPoE и WG ранее

[I] Feb  4 08:30:06 kernel: br1: port 2(ra1) entered disabled state
[I] Feb  4 08:30:06 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": "base" changed "conf" layer state "running" to "disabled". 
[I] Feb  4 08:30:06 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": interface is down. 
[I] Feb  4 08:30:06 ndm: Core::System::StartupConfig: saving (http/rci). 
[I] Feb  4 08:30:06 kernel: br1: port 2(ra1) entered disabled state
[I] Feb  4 08:30:06 ndm: Network::Interface::Base: "Bridge1": "l2-base" changed "link" layer state "running" to "pending". 
[I] Feb  4 08:30:06 ndm: Hotspot::Discovery::Explorer: "Bridge1": Interface Bridge1 IPv4 neighbour explorer stopped. 
[I] Feb  4 08:30:10 kernel: IPv6: ADDRCONF(NETDEV_UP): ra1: link is not ready
[I] Feb  4 08:30:10 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): ra1: link becomes ready
[I] Feb  4 08:30:10 kernel: br1: port 2(ra1) entered blocking state
[I] Feb  4 08:30:10 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": "base" changed "conf" layer state "disabled" to "running". 
[I] Feb  4 08:30:10 kernel: br1: port 2(ra1) entered listening state
[I] Feb  4 08:30:10 ndm: Network::Interface::Base: "WifiMaster0/AccessPoint1": interface is up. 
[I] Feb  4 08:30:10 ndm: Core::System::StartupConfig: saving (http/rci). 
[I] Feb  4 08:30:10 kernel: br1: port 2(ra1) entered blocking state
[I] Feb  4 08:30:10 kernel: br1: port 2(ra1) entered listening state
[I] Feb  4 08:30:10 ndm: Core::System::StartupConfig: configuration saved. 
[I] Feb  4 08:30:10 ndm: Network::Interface::Base: "Bridge1": "l2-base" changed "link" layer state "pending" to "running". 
[I] Feb  4 08:30:10 ndm: Hotspot::Discovery::Explorer: "Bridge1": Interface Bridge1 IPv4 neighbour explorer started. 
[I] Feb  4 08:30:11 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(.....:99) had associated successfully. 
....

После ожидания все подключились

Фев 4 08:41:02 ndm Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint1": STA(......:99) set key done in WPA2/WPA2PSK.
Фев 4 08:41:02 ndhcps DHCPDISCOVER received from .....:99.
Фев 4 08:41:02 ndhcps making OFFER of 192.168.150.2 to ......:99.
Фев 4 08:41:02 ndhcps DHCPDISCOVER received from ......:99.
Фев 4 08:41:02 ndhcps making OFFER of 192.168.150.2 to ......:99.
Фев 4 08:41:02 ndhcps DHCPREQUEST received (STATE_SELECTING) for 192.168.150.2 from ......:99.
Фев 4 08:41:02 ndm Netfilter::Util::Conntrack: flushed 60 IPv4 connections.
Фев 4 08:41:03 ndhcps sending ACK of 192.168.150.2 to .....:99. 

Время на раздумье около 10минут при таком поведение хватило.

В итоге делаю вывод что оценка интернет каналов (состояние) приводит ????? на других интерфейсов не связанных с данными каналами - например bridge1 доп.сегмент в котором только 2.4 wifi.

Все как бы ОК но в WEB роутера "шторка" с надписью "Потеря соединения с интернет центром". Придется перезапустить его.

Настройки доп.сегмента простые

Скрытый текст

interface Bridge1
    description HomeSmart
    include GigabitEthernet0/Vlan3
    include WifiMaster0/AccessPoint1
    mac access-list type permit
    mac access-list address .....:af
    mac access-list address .....:99
    mac access-list address .....:5f
    mac access-list address .....:00
    mac access-list address .....:c1
    mac access-list address .....:e0
    security-level protected
    ip address 192.168.150.101 255.255.255.0
    ip dhcp client dns-routes
    ip dhcp client name-servers
    up

interface WifiMaster0/AccessPoint1
    mac access-list type none
    security-level protected
    authentication wpa-psk ns3 ***
    encryption enable
    encryption wpa2
    ip dhcp client dns-routes
    ip dhcp client name-servers
    ssid Smart
    up

 

 

[hellonow]

@vasek00 спасибо, воспроизвелось и в другом сценарии, когда WG маршрутизируется через WISP. Достаточно в down перевести интерфейс WifiMaster1/WifiStation0, как почти сразу начинается шторм.

[KCAHDEP]

Возможно продолжение ошибки из этой же оперы. есть pppoe ростелеком и 2 wg туннеля (warp и proton), оба активные с доступом в интернет и 1 из них используется как основной через него идет весь трафик, второй используются как резервный (переключаю по необходимости клиентов в сети) При падении, отключении, переподключении ростелекома роутер так же показывает график 

Скрытый текст

в логе вот такое 
 

Скрытый текст

это уже после обновления на 4.0.7 до обновления график загрузки был 500-600мбит. 

 

Edited February 7 by KCAHDEP

[KCAHDEP]

На последней альфе шторм так и продолжается при двух активных wg туннелях. 

[roman_sh]

В 07.02.2023 в 11:41, KCAHDEP сказал:

Возможно продолжение ошибки из этой же оперы. есть pppoe ростелеком и 2 wg туннеля (warp и proton), оба активные с доступом в интернет и 1 из них используется как основной через него идет весь трафик, второй используются как резервный (переключаю по необходимости клиентов в сети) При падении, отключении, переподключении ростелекома роутер так же показывает график 

  Скрыть содержимое

в логе вот такое 
 

  Показать содержимое

это уже после обновления на 4.0.7 до обновления график загрузки был 500-600мбит. 

 

Этот глюк я наблюдаю уже давно. Еще на 3 версии прошивок он был.

У меня на LTE модеме при перезагрузке, когда модем установил соединение с сетью, но по какой то причине данные в интернет не передает еще некоторое время, WireGuard точно такой же график рисует.

То есть:

1. В интерфейсе показывает что соединение с LTE установлено, назначены IP адреса во внешнюю сеть и т.д.

2. Интернет не работает (по какой причине не знаю, никогда в этот момент логи не смотрел, думал глюк на стороне провайдера)

3. WireGuard включен - и до появления соединения он будет показывать полную теоретическую загрузку исходящего канала, даже если соединение такаих скоростей не поддерживает (в моем случае около 70 Мбит)

[hellonow]

@KCAHDEP @roman_sh @vasek00 еще раз всем спасибо. Гарантировано получилось воспроизвести с WG-интерфейсами, которые идут друг за другом в профиле политик по умолчанию - таблица маршрутизации _254.

Когда отключаем интерфейс - подключение для доступа в интернет с маршрутом по умолчанию, то на последующем WG-интерфейсе возникает шторм исходящих пакетов. Исправление планируется в будущих версиях draft.