3.8.1 Peak. "шторм" исходящего трафика в Wireguard тунеле при пропадании основного подключения

[project_fcc]

3.8.1 Peak

Настроено: проводное подключение - основное

подключение к VPN-провайдеру по wireguard - резервное

Если основное подключение "падает" (можно отключить подключение  или отключить кабель), то в канале VPN wiregurd наблюдаться резкий рост исходящего трафика  в течение нескольких минут.

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

На kn-1010 на 3.6.12 была аналогичная ситуация. Был запрос в поддержку #568731

[vasek00]

Дополнение к описанию данной проблемы.

Канал интернета PPPoE на нем поднимается WG в сторону cloudflare, все это в основном профиле, т.е. приоритет WG выше чем PPPoE.

1. В WEB выключаю PPPoE ("Проводные подключения") данный канал - просто выкл. Как итог "штормит" WG как на скрине выше, некоторое время потом он пропадает. Такой же эффект наблюдается при выключение кабеля провайдера из WAN порта, до тех пор пока не отработает

[E] Jan 30 11:03:32 pppd[10727]: sendPacket: send: Network is down 
[I] Jan 30 11:03:32 pppd[10727]: Exit. 
[E] Jan 30 11:03:32 ndm: Service: "PPPoE0": unexpectedly stopped. 
[I] Jan 30 11:03:32 ndm: Network::Interface::Ppp: "PPPoE0": connection service standby. 
[I] Jan 30 11:03:32 ndm: Network::Interface::Base: "PPPoE0": interface is up. 
[I] Jan 30 11:03:32 ndm: Network::Interface::Ppp: "PPPoE0": connection service standby. 

т.е. "шторм" пропадает, но

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

[I] Jan 30 11:03:32 ndm: Wireguard::Interface: "Wireguard0": underlying interface "PPPoE0" of peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" is down, reconnecting. 
[I] Jan 30 11:03:32 ndm: Wireguard::Interface: "Wireguard0": has no route to peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" endpoint 162.159.192.1. 
[I] Jan 30 11:03:32 ndm: Wireguard::Interface: "Wireguard0": peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" endpoint "engage.cloudflareclient.com" is unavailable, schedule retry. 
[I] Jan 30 11:03:32 ndm: Wireguard::Interface: "Wireguard0": underlying interface "PPPoE0" of peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" is down, reconnecting. 
[I] Jan 30 11:03:32 ndm: Wireguard::Interface: "Wireguard0": has no route to peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" endpoint 162.159.192.1. 
[I] Jan 30 11:03:32 ndm: Wireguard::Interface: "Wireguard0": peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" endpoint "engage.cloudflareclient.com" is unavailable, schedule retry. 
....

до бесконечности

Включение кабеля все восстанавливает, моментально.

2. Аналогичное поведение при канал интернета прямой кабель (на выделенном LAN порту) так же на нем поднимается WG в сторону cloudflare, все это в основном профиле, т.е. приоритет WG выше. Выключаю в WEB данный канал провайдера и наблюдаю "шторм" некоторое время, при том по netdata на интерфейсе eth2.9 (провайдера) нет активности, но как бы и не должно он ведь в down, а на wg "штормит" 450Мбит в передаче ровно 1мин.

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

Во время шторма

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

    <process>
        <comm>ndm</comm>
        <oom-adj>-16</oom-adj>
        <oom-score>0</oom-score>
        <oom-score-adj>-999</oom-score-adj>
        <state>S (sleeping)</state>
        <pid>507</pid>
        <ppid>1</ppid>
        <vm-size>75592 kB</vm-size>
        <vm-rss>39296 kB</vm-rss>
        <vm-data>51300 kB</vm-data>
        <vm-stk>132 kB</vm-stk>
        <vm-exe>28 kB</vm-exe>
        <vm-lib>22596 kB</vm-lib>
        <vm-swap>0 kB</vm-swap>
        <threads>47</threads>
        <fds>40</fds>
        <statistics>
            <interval>30</interval>
            <cpu>
                <now>73728.919775</now>
                <min>1</min>
                <max>44</max>
                <avg>16</avg>
                <cur>28</cur>
            </cpu>
        </statistics>

          <process>
        <comm>kworker/0:3</comm>
        <oom-adj>0</oom-adj>
        <oom-score>0</oom-score>
        <oom-score-adj>0</oom-score-adj>
        <state>R (running)</state>
        <pid>1317</pid>
        <ppid>2</ppid>
        <threads>1</threads>
        <fds>0</fds>
        <statistics>
            <interval>30</interval>
            <cpu>
                <now>73728.920241</now>
                <min>21</min>
                <max>30</max>
                <avg>28</avg>
                <cur>30</cur>
            </cpu>
        </statistics>

                <process>
        <comm>kworker/1:3</comm>
        <oom-adj>0</oom-adj>
        <oom-score>0</oom-score>
        <oom-score-adj>0</oom-score-adj>
        <state>R (running)</state>
        <pid>1388</pid>
        <ppid>2</ppid>
        <threads>1</threads>
        <fds>0</fds>
        <statistics>
            <interval>30</interval>
            <cpu>
                <now>73728.920280</now>
                <min>0</min>
                <max>14</max>
                <avg>7</avg>
                <cur>12</cur>
            </cpu>
        </statistics>

 

[vasek00]

В догонку при "шторме" с каналом PPPoE+WG, после отключения PPPoE канала в WEB сразу же на интерфейсе nwg0

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

~ # tcpdump -i nwg0

12:41:03.341433 IP 10.10.13.10.65100 > 162.159.192.1.2408: UDP, bad length 1356 > 1296
12:41:03.341440 IP 10.10.13.10.65100 > 162.159.192.1: udp
12:41:03.341460 IP 10.10.13.10.65100 > 162.159.192.1.2408: UDP, bad length 1356 > 1296
12:41:03.341497 IP 10.10.13.10.65100 > 162.159.192.1.2408: UDP, bad length 1356 > 1296
12:41:03.341503 IP 10.10.13.10.65100 > 162.159.192.1: udp
12:41:03.341523 IP 10.10.13.10.65100 > 162.159.192.1.2408: UDP, bad length 1356 > 1296

 

 

[project_fcc]

На 3.8.8 я так понимаю было исправлено:

Цитата

Wireguard: исправлено зацикливание исходящих пакетов при отключении нижележащего WAN-соединения [NDM-852]

Попробовал несколько раз выдернуть кабель wan, на интерфейсе WG уже нет такого "шторма", буквально 1-2 секунд трафик идет, но он незначительный

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