Сброс VPN и IPsec сессий

[CBLoner]

Ultra II. v2.07(AAUX.6)B0

Работает вроде норм, но раз пятый уже замечаю - пытаюсь зайти на веб морду - думает от 10 до 40 секунд, потом все же открывает логин пароль. Ошибок в логах никаких нет, инет при этом работает! Закономерность пока не выявил, может веб сервер засыпает?

Не планируется ли во вкладках "VPN сервер" и "IPSEC VPN" сделать кнопку сброса соединения PPTP или сброса активного туннеля?

[Drusja]

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

[Le ecureuil]

Не планируется ли во вкладках "VPN сервер" и "IPSEC VPN" сделать кнопку сброса соединения PPTP или сброса активного туннеля?

Опишите подробнее, что вы имеете в виду и как это должно работать.

[CBLoner]

Не планируется ли во вкладках "VPN сервер" и "IPSEC VPN" сделать кнопку сброса соединения PPTP или сброса активного туннеля?

Опишите подробнее, что вы имеете в виду и как это должно работать.

Все просто, иногда по разным причинам зависает VPN туннель и его надо принудительно разорвать. Причем если IPSEC стоит на автоподнятии, то он сам восстановиться!

Скрин с железки NetGear FVS318 прилагаю, сейчас как раз юзаю ее в связке с сабжем!

Также иногда надо принудительно выкинуть прицепившегося пользователя по PPTP. Причины разные, от зависшего девайса с той стороны, до кривых рук пользователя, а каждый раз через веб морду включать или выключать VPN сервер - не айс. Сделать такую же кнопку, как на скрине - напротив соединения... "Drop" или "Завершить сеанс"

По мне так фишка крайне юзабельна, на NetGear периодически часто пользуюсь!

[CBLoner]

Так предложение актуальное и находит поддержку? 

[Le ecureuil]

Подождем еще немного голосов здесь, пока кроме вас никому не нужно

Но вообще реализуемо при должном спросе.

[Илья Ганжин]

Поддерживаю, я когда то уже просил эту фичу, тогда вопрос проигнорировали)

[Le ecureuil]

Если и будет реализовано, то в ближайшее время только в CLI.

[CBLoner]

Но есть шанс, что на веб "морду" все же вынесут кнопулю?

Ну пускай хотя бы через CLI... А там дальше будем ныть и просить!

[CBLoner]

Ну как с сабжем?

[Le ecureuil]

1 час назад, cbloner сказал:

Ну как с сабжем?

Только что обсуждали.

Задача такая стоит в очереди, но приоритет у нее не самый высокий.

Так что пока терпение и терпение, но скорее всего будет сделано.

[CBLoner]

Это про правила firewall? Ну это можно наверное как частность... а тут я про кнопку именно на текущих/активных VPN туннелей.

Терпения у нас вагон.... Но все же интересно 2-3 месяца, пол года или год?! 

[Le ecureuil]

5 часов назад, cbloner сказал:

Это про правила firewall? Ну это можно наверное как частность... а тут я про кнопку именно на текущих/активных VPN туннелей.

Терпения у нас вагон.... Но все же интересно 2-3 месяца, пол года или год?! 

Я и имел в виду сброс активных сессий на pptp и ipsec серверах.

[CBLoner]

НУ это типа кто-то приконектился по PPTP и его принудительно отключить? И так же подняли туннель, он завис и его сбросить (а он там автоматом сам поднимется)!?

[hellonow]

@Le ecureuil @ndm Поддерживаю на счет кнопки. Сегодня подобное словил на v2.08(AAFS.3)A12: на VPN-сервере Giga II зависла VPN-сессия клиента Lite III revA с PPTP-подключением от провайдера. В коннекте VPN-сервера вижу:

В логах VPN-клиента Lite III revA:

Dec 23 10:29:40ndmService: "PPTP1": unexpectedly stopped.
Dec 23 10:29:40ndmNetwork::Interface::Base: "PPTP1": interface is up.
Dec 23 10:29:43pptp[8379]Plugin pptp.so loaded.
Dec 23 10:29:43pptp[8379]PPTP plugin version 0.8.3 compiled against pppd 2.4.4-4
Dec 23 10:29:43pptp[8379]pppd 2.4.4-4 started by root, uid 0
Dec 23 10:29:43ndmNetwork::Interface::PPTP: "PPTP1": added host route to 81.5.116.194 via PPTP0.
Dec 23 10:29:43pptp[8381]IP: 81.5.116.194 
Dec 23 10:29:43pptp[8381]control connection
Dec 23 10:29:43pptp[8381]unix_sock
Dec 23 10:29:43pptp[8382]enable echo requests (30:3)
Dec 23 10:29:43pptp[8382]Sent control packet type is 1 'Start-Control-Connection-Request' 
Dec 23 10:29:43pptp[8382]Received Start Control Connection Reply
Dec 23 10:29:43pptp[8382]Client connection established.
Dec 23 10:29:44pptp[8382]Sent control packet type is 7 'Outgoing-Call-Request' 
Dec 23 10:29:44pptp[8382]Received Outgoing Call Reply.
Dec 23 10:29:44pptp[8382]Outgoing call established (call ID 372, peer's call ID 800). 
Dec 23 10:29:44ndmkernel: Fast VPN ctrl: setup for src 81.5.116.194
Dec 23 10:29:44pptp[8379]Using interface ppp1
Dec 23 10:29:44pptp[8379]Connect: ppp1 <--> pptp (81.5.116.194)
Dec 23 10:29:44pptp[8379]CHAP authentication succeeded
Dec 23 10:29:44pptp[8379]MPPE 40-bit stateless compression enabled
Dec 23 10:29:44pptp[8379]local  IP address 172.16.2.40
Dec 23 10:29:44pptp[8379]remote IP address 192.168.170.1
Dec 23 10:29:44pptp[8379]primary   DNS address 192.168.170.1
Dec 23 10:29:44pptp[8379]secondary DNS address 192.168.170.1
Dec 23 10:29:44ndmNetwork::Interface::Base: "PPTP1": interface is up.
Dec 23 10:29:44ndmNetwork::Interface::Base: "PPTP1": interface is up.
Dec 23 10:29:44ndmNetwork::Interface::PPP: adding nameserver 192.168.170.1.
Dec 23 10:29:44ndmDns::Manager: name server 192.168.170.1 added, domain (default).
Dec 23 10:29:44ndmNetwork::Interface::IP: "PPTP1": IP address is 172.16.2.40/32.
Dec 23 10:29:44pptp[8379]LCP terminated by peer (MPPE disabled)
Dec 23 10:29:44pptp[8379]Connect time 0.0 minutes.
Dec 23 10:29:44pptp[8379]Sent 0 bytes, received 0 bytes.
Dec 23 10:29:44pptp[8382]Call disconnect notification received (call id 800)
Dec 23 10:29:44pptp[8382]Received Stop Control Connection Request.
Dec 23 10:29:44pptp[8382]Sent control packet type is 4 'Stop-Control-Connection-Reply' 
Dec 23 10:29:44pptp[8382]Closing connection (shutdown)
Dec 23 10:29:44pptp[8382]Sent control packet type is 12 'Call-Clear-Request' 
Dec 23 10:29:44pptp[8382]Closing connection (call state)
Dec 23 10:29:44pptp[8379]Modem hangup
Dec 23 10:29:44pptp[8379]Connection terminated.
Dec 23 10:29:44ndmkernel: Fast VPN ctrl: release for src 81.5.116.194
Dec 23 10:29:44pptp[8379]Exit.

никогда такого не было. Проверьте пожалуйста. 2.08.A.12.0-4 не ставил из-за web багов. Пришлось перезапускать VPN-сервер.

Изменено 20 сентября, 2017 пользователем enpa

[CBLoner]

Будет кнопка?


Отправлено с моего iPad используя Tapatalk

[Le ecureuil]

13 часа назад, cbloner сказал:

Будет кнопка?


Отправлено с моего iPad используя Tapatalk

Висит в списке задач, но с невысоким приоритетом  Мы не забыли

[CBLoner]

Ой спасибо спасибо ;-)))

[soft_warrior]

вопрос так и остается актуальным

имеется такая же радость, но с другим оборудованием на другом конце.

подвисает канал на 2фазе шифрования ipsec ikev1 - возможно кинетик просто не принимает обновленные ключи корректно. водвитает гдето за 10-15 минут до сроков обновления ключа фазы 2... от установленного времени жизни зависит.

это так же подтверждено "событийно" на 4.2.1-4.2.3 прошивках. ультра, ультра 2, 4G (KN-1212)

в роутере фактически нет накакого контроля живости линии внутри фазы 2 - если та сторона просто перестает получать/отправлять данные - ничего не происходит.

к сожалению не получаеся создать "вручную" из консоли автопинговалку для ребута туннеля ip-ip / ipsec....

- можно только "переключателем" дернуть или дропнуть соединение на другой стороне,

но и его только на web можно добыть, а в том же приложении на адроиде этой категории соединений просто нет в списке.

[Le ecureuil]

11 час назад, soft_warrior сказал:

в роутере фактически нет накакого контроля живости линии внутри фазы 2 - если та сторона просто перестает получать/отправлять данные - ничего не происходит.

А покажите-ка логи. У вас DPD включен? Потому что при отсутствии трафика он вступает в работу и отключает зависшие сессии.

[soft_warrior]

6 часов назад, Le ecureuil сказал:

А покажите-ка логи. У вас DPD включен? Потому что при отсутствии трафика он вступает в работу и отключает зависшие сессии.

DPD - обнаружение неработающего пира - включено

при чем мой кинетик - инициирующий соединение.

лог с текущей даты начиная утра... незначимые строки постарался убрать, ip заменить на ххх.ххх.ххх.nnn

туннелей рабочих 7 шт, все ipsec ikev1

конфигурация одинаковая.

из глюков что были на 2.16..хх версии, но на 4.2.1/4.2.3 не проверял - нельзя было сделать разные фразы шифрования на разные туннели, бралась от первого инициировавшего начало соединения и просто ко всем применялась, сейчас даже не проверял.

второе и далее направления маршрутизации для туннеля на ту сторону, если даже в настройках есть и заполнено, то на туннель никак не применяется, отается только одно - первое по сортировке из них

в текущие сутки зависаний было два, заходил на web и делал выкл вкл для туннеля.

в 7 ровно, но это мог быть разрыв провайдера.

в 12:20-12:30 - один туннель

в 12:30- соединился зависший еще с прошлых суток sklad.spb [xx.xxx.xx.2] 

прожил 10 мин 2 сек и отвалися в 12:40 без помощи, но в статусе на интерфейсе кинетика он был "все хорошо", соединение есть. и прямо сейчас с ним все хорошо, но связи нет (на той стороне пассив - сообщает что нет связи).

в 13:50-13:55 - третий туннель

log-2024-11-28__3.txt

Изменено 29 ноября, 2024 пользователем soft_warrior

[Le ecureuil]

1. Все "глюки, что берется неправильный proposal" - это на самом деле из-за принципиального устройства IKEv1. Если нет строгой необходимости, то использовать его сейчас не стоит примерно никогда в первую очередь из-за подобных вопросов. Также возникающие в логе NO_PROPOSAL_CHOSEN очень похожи на проблемы выбора proposal в IKEv1.

2. Судя по  логу, у вас в 13.53 отлично срабатывает DPD и все реконнектится. Проблем визуально не видно.

Nov 29 13:53:59 ipsec: 13[JOB]DPD check timed out, enforcing DPD action
Nov 29 13:53:59 ndm:ipsec::Configurator: ""office.msk-co1"": remote peer is down."
Nov 29 13:53:59 ndm:ipsec::CryptoMapInfo: ""office.msk-co1"": crypto map active IKE SA: 0, active CHILD SA: 0, down."
Nov 29 13:53:59 ndm:ipsec::Configurator: ""office.msk-co1"": fallback peer is not defined, retry."
Nov 29 13:53:59 ndm:ipsec::Configurator: ""office.msk-co1"": schedule reconnect."
Nov 29 13:53:59 ndm:ipsec::CryptoMapInfo: ""office.msk-co1"": crypto map active IKE SA: 0, active CHILD SA: 0."
Nov 29 13:53:59 ndm:ipsec::CryptoMapInfo: ""office.msk-co1"": crypto map active IKE SA: 0, active CHILD SA: 0."
Nov 29 13:53:59 ipsec: 13[IKE]restarting CHILD_SA office.msk-co1

Еще раз настою, что в случае с несколькими туннелями при любой возможности стоит переходить на IKEv2 и задавать идентификаторы в виде текстовых строк (хотя бы email / fqdn), и не использовать IP-адреса для этой цели.

[soft_warrior]

В 02.12.2024 в 12:06, Le ecureuil сказал:

1. Все "глюки, что берется неправильный proposal" - это на самом деле из-за принципиального устройства IKEv1. Если нет строгой необходимости, то использовать его сейчас не стоит примерно никогда в первую очередь из-за подобных вопросов. Также возникающие в логе NO_PROPOSAL_CHOSEN очень похожи на проблемы выбора proposal в IKEv1.

меня больше интерсует "проникновение" информации о фразе шифрования из одного туннеля в другой... 

В 02.12.2024 в 12:06, Le ecureuil сказал:

2. Судя по  логу, у вас в 13.53 отлично срабатывает DPD и все реконнектится. Проблем визуально не видно.

тут вопрос даже не про неверно срабатывающий DPD, а то что туннели как то влияют друг на друга - изза своей многочисленности?

В 02.12.2024 в 12:06, Le ecureuil сказал:

Еще раз настою, что в случае с несколькими туннелями при любой возможности стоит переходить на IKEv2 и задавать идентификаторы в виде текстовых строк (хотя бы email / fqdn), и не использовать IP-адреса для этой цели.

к сожалению IKEv2 на той стороне не поддерживается и это единственный совместимый протокол туннелей

 

ну и тут возможно из той же оперы:

роутер Keeenetic Ultra II - прошивка 4.2.1.

при объемном постоянном пинге (10к - 30к фрагменированный пакет) в туннели и/или из них до роутера при таких настройках туннелей роутер периодически стал уходить в жесткий ребут.

что никак не радует.

просто пинг в инет на хост - никаких проблем нет.

хотя раньше я долго не пытался "нагружать" именно туннели и именно большим пакетом пинга...

но опять же и перекачки данных туда/обратно на 700мБитах - вообще проблем ни разу не возникало.

опять же в туннель не попадает второй маршрут из настроек - тоже глюк.

Изменено 3 декабря, 2024 пользователем soft_warrior

[Le ecureuil]

Принудительное завершение сессии в cli реализовано в следующей версии 4.3 через команду "session-logout", она доступна для vpn-server, sstp-server, oc-server, crypto map l2tp-server и crypto map virtual-ip. ID сессии берется из show соответствующего сервера.