vpnc - продолжает отключаться через 24 минуты

Существует сообщение об ошибке, решающее эту проблему, датированное 2010-10-28, но, к сожалению, до сих пор не решено. Кажется, что время отключения несколько индивидуально, хотя сообщенное время по-прежнему превышает 24 минуты.

Статья указывает на исправление, описанное здесь, которое требует перекомпиляции vpnc.

Если ваша проблема связана с повторным вводом кода, то в статье о повторном вводе статьи с 0.5.3 утверждается, что ошибка является новой для версии 0.5.3 и не существует в 0.5.1.

[РЕДАКТИРОВАТЬ}

Кажется, что вернуться к 0.5.1 не работает для вас. Также кажется, что разъединения vpnc распространены во многих дистрибутивах Linux.

Я обнаружил исправление проблемы с отключением vpnc выше версии 0.5.x, которая предполагает, что, возможно, нужно вернуться даже к 0.4.x. В любом случае в статье предлагается исправление, которое, вероятно, не относится к вашему случаю, но вы можете попробовать:

В конце концов мы также должны отключить DPD на стороне клиента (vpnc), чего мы можем достичь двумя способами:

• добавить ключ командной строки «--dpd-idle 0» при вызове «vpnc»
• еще лучше добавить эту строку в файл конфигурации: «Тайм-аут простоя DPD (наша сторона) 0»

Дополнительная информация: man vpnc

Похожая информация поступает от поддержки RedHat: Ошибка 484114 - VPN отключается каждые 5 минут .

Вы можете попробовать перейти на vpnc 0.4.x, но я начинаю задумываться, не является ли проблема на вашей стороне или с некоторыми настройками сервера vpn: 24 минуты слишком точны.

Попробуйте изменить режим прохождения NAT на cisco-udp, это решило его для меня

NAT Traversal Mode cisco-udp 

Мой полный конфиг выглядит так

IPSec gateway VPNHOSTIP IPSec ID SAMPLESHAREDUSER IPSec secret SAMPLESHAREDKEY Xauth username SAMPLEUSER Xauth password SAMPLEUSERPASS IKE Authmode psk #IKE DH Group dh2 # this is the default DNSUpdate no DPD idle timeout (our side) 0 NAT Traversal Mode cisco-udp 

Мое подключение к VPN все еще работает через 20 часов.

I had the same problem, and none of the suggested solutions worked for me. In the end, I gave up on vpnc and tried the ShrewSoft vpn client. It's a bit of a hassle because you have to compile it yourself (and manually install any missing dependencies -- in my case, cmake, libedit2, flex, and bison). But it seems to work fine.

At the time of writing, you can download it from https://www.shrew.net/download/ike

Вы можете посмотреть на --nat-keepaliveвариант, возможно, попробовать--nat-keepalive 1200

В какой-то момент это была известная ошибка, не уверенная, была ли она когда-либо исправлена.

У меня та же проблема, http://dietrichschroff.blogspot.com/2011/07/linux-vpn-client-disconnect-every-600s.html, кажется, упоминает, что проблема может быть связана с используемой группой DH. Чтобы изменить DH Group на 5, в вашем конфигурационном файле добавьте

IKE DH Group dh5 

Варианты для этого изменения конфигурации

IKE DH Group <dh1/dh2/dh5> 

На домашней странице проекта VPNC не упоминается, что это известная проблема, но я предполагаю, что «перекодировка фазы2» все еще не так стабильна (основываясь на сообщениях об ошибках). Также обратите внимание, что

• фаза1 - повторный ввод отсутствует

Обновленная версия 0.5.3 (как последняя версия SVN исходного проекта) выпуска VPNC на github включает в себя:

• Добавляет возможность отвечать на вопросы XAuth с помощью внешнего скрипта
• Добавляет процедуры очистки, которые запускаются в случае неожиданного отключения
• Добавляет обходной путь для сценария, когда концентратор задает вопрос Xauth как запрос пароля.
• Добавляет патч Михая Матиеса для обнаружения мертвых пиров ( http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2010-De December/003492.html )

Я также рекомендовал бы охрану часов в качестве оптимального решения для переподключений https://github.com/dcantrell/vpncwatch/network, если очень желателен автоматический режим и удаленная сторона все еще может вызывать (не связанные с программным обеспечением) разъединения.

PS

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

Наконец, существует возможность использования собственного клиента ( anyconnect ) для Linux. Одним из недостатков является то, что возможности конфигурации на стороне клиента, такие как обновление записи DNS и отсутствие маршрута по умолчанию, сильно ограничены. Другой, разъединения все еще будут иметь место, но в очень редких случаях.

У меня та же проблема на Ubuntu 12.04, и с VPNC он отключается ровно через 24 минуты.

Я попробовал "Shrew Soft", который я установил из центра программного обеспечения. Мне удалось настроить VPN с помощью файла .pcf, который я получил из своего ИТ-отдела. Тогда я получил точно такую ​​же проблему.

Тем не менее, с помощью «Shrew Soft» вы можете настроить несколько вещей. То, что заставляет мое соединение оставаться постоянным, это настройка в Phase1-rekeying. Я изменил значение «Key Life Time Limit» с 86400 (24 часа) до 600 секунд. Я предполагаю, что есть ошибка где-то, где она использует 24 минуты вместо 24 часов.

Я предложил исправление для повторного ввода IKE-фазы на основе предыдущей отправки исправления, которое делает мое инициированное vpnc-соединение стабильным в течение нескольких дней по отношению к головному устройству ASA. Моя продолжительность жизни фаза 1 24h так же успешно и смены ключей держит соединение в живых. Например

• переключает SA фазы 2 (IPsec) -и-
• переключает SA фазы 1 (ISAKMP).