Автоматический переход VPN туннеля с резервного интернет канала на основной канал

[Etreac]

Добрый день.

 

Есть две локации с роутерами Кинетик

 

1. Локация1 - Keenetic1 Ultra SE (интернет через кабель PPPoE [Белый IP])

2. Локация2 - Keenetic2 Hero 4G (интернет через кабель PPPoE [Белый IP] + резервный интернет через сим-карту)

 

Между ними создан VPN канал IPsec VPN по данной инструкции:

https://help.keenetic.com/hc/ru/articles/360000422620-IPSec-VPN-клиент-сервер

 

Keenetic1 (IPSec)----Инет1/Инет2----(IPSec)Keenetic2

 

Обнаружил следующую проблему:

 

Туннель Локация1 - Локация2 работает без сим карты отлично. После добавления сим-карты в качестве резервного интернета, в какой то момент весь трафик туннеля начинает идти через сим-карту, хотя это подключение стоит в резерве и включен интернет через основной канал и он в норме. Я так понимаю в какой-то момент идет переход VPN туннеля на резервный канал, а потом на основной не возвращается.

 

На сим-карте заканчивается трафик, туннель переходит в статус «нет соединения». При выключении сим-карты в интерфейсе роутера туннель восстанавливается, также восстанавливается после перезагрузки роутера.

 

Поддержка кинетика ответила: Да, на данный момент есть такая особенность реализации, что когда туннель установился через резерв, то он более не перейдёт сам на основной канал. Только с помощью администрирования вручную!

 

Le ecureuil, Хочу попросить у вас помощи в решении данной проблемы.

[vasek00]

Есть такое поведение на ПО 3.8. При схеме

Keenetic1 (IPSec)----Инет1/Инет2----(IPSec)Keenetic2 

На Keenetic2 два канала : один PPPoE второй провод на LAN порту (eth2.9), поднят IPSec между роутерами. При проверке было обнаружено

1. Отключение провода основного провайдера PPPoE на Keenetic2 и переход на резервный канал eth2.9, туннель так же переключился и работал по резервному каналу через eth2.9.

2. Подключение провода основного провайдера PPPoE на Keenetic2 вернул его в работу как основного НО ТУННЕЛЬ так и остался висеть на eth2.9 (так как проблем на этом канале не было)

3. При отключение резервного канала eth2.9 например через WEB или в cli туннель поднимается на основном канале все ОК.

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

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

 

При проверки такой же работы но на wireguard туннеля все отрабатывается штатно и правельно.

Изменено 13 февраля, 2022 пользователем vasek00

[SySOPik]

21 час назад, vasek00 сказал:

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

Есть такая проблема, IPSec едет на резервный канал и там висит. Я писал в ТП, проблему подтвердили, но пока что в будущем будет доработка. Есть костыль, прописать на клиенте IPSec статический маршрут до IP серверного кинетика через основное подключение. Тогда запросы побегут через основной канал, однако скорей всего через резерв не взлетит.

[vasek00]

9 минут назад, SySOPik сказал:

Есть такая проблема, IPSec едет на резервный канал и там висит. Я писал в ТП, проблему подтвердили, но пока что в будущем будет доработка. Есть костыль, прописать на клиенте IPSec статический маршрут до IP серверного кинетика через основное подключение. Тогда запросы побегут через основной канал, однако скорей всего через резерв не взлетит.

Доработка да, вопрос только в том будет ли она или нет.

 

Если дорабатывать самим как пишет ТП Только с помощью администрирования вручную!

В настройках туннеля есть параметры   "l2tp-server lcp echo 30 3" контроля соединения 30сек и 3 fail

crypto map tun--e
    set-peer 1хх.ххх.ххх.ххх
    set-profile tun--e
    set-transform tun--e
    match-address _WEBADMIN_IPSEC_tun--e
    set-tcpmss pmtu
    connect
    nail-up
    reauth-passive
    virtual-ip no enable
    l2tp-server lcp echo 30 3
    l2tp-server no enable
    enable

При выключение основного канала переход на резервный все ОК с подъемом туннеля, т.е. канал рухнул и туннель туда же, переключение на резервный и туннель поднялся. При возврате же на основной контроль туннеля "l2tp-server lcp echo 30 3" не видит проблем на нет и поэтому работает на резерве, маршруты согласно настроек туннеля (удаленная сеть и локальная). При down данного резервного канала (автоматом переход на основной) и выжидание данного "l2tp-server lcp echo 30 3" туннель поднимается на основном как и положено, потом просто надо включить резервный канал.

Для скрипта нужно устанавливать Entware и как вариант есть что-то hook типа /ndm/wan.d контроль WAN порта - любые изменения и имеем переменную $interface и так же /ndm/ifipchanged.d и параметров по более в частности $system_name (он такой же как и $interface) и $connected : $up : $global. Для примера выше например

echo "$id : $system_name : $address : $link : $connected : $up : $global" >> /opt/tmp/table;

ndm/ifipchanged.d
GigabitEthernet0/Vlan9 : eth2.9 : 10.10.10.13 : up : yes : up : 65482

ndm/ifipchanged.d
PPPoE0 : ppp0 : ххх.ххх.ххх.ххх : up : yes : up : 65508

Но есть маленькая фишка по времени обработки скриптов hook

Фев 14 11:18:36 ndm Opkg::Manager: /opt/etc/ndm/wan.d/start.sh: timed out.
Фев 14 11:18:36 ndm Process: killing all processes in "Opkg shell" group... 

Контроль через cron как то не серьезно, хотя просто уронить резерв и подождав 90-100сек. поднять резерв.

 

Возможно можно как то перезапустить туннель IPSec типа как в WEB но команду пока не нашел.

 

 

 

 

[vasek00]

Нашел для перезапуска

crypto map tun--e
...
    set-profile tun--e
...
    l2tp-server no enable
    no enable


crypto map tun--e
...
    set-profile tun--e
...
    l2tp-server no enable
    enable