Защо vpnc прекъсва на 24 минути и какво да промените

Тунелът ви умира на повтарящ се интервал и това е таймер, който се отчита, а не лош кабел. Двадесет и четири минути са 1440 секунди, кръгла стойност, каквато носи профил или политика на централния възел. После същата конфигурация се проваля срещу същия концентратор всеки път, докато всяка друга мрежа работи, и никакво тестване на връзката не го променя.

Три условия решават кой таймер е вашият: дали клиентът се отказва от бездействаща сесия, дали обменът за подновяване на ключове е отказан и дали транслиращ шлюз е пренаписал инкапсулацията.

Кой таймер притежава прекъсването

Измерете интервала при поне три повторни свързвания, преди да пипате настройка. Разсейване от секунди сочи към загуба на връзка или безжично роуминг; стойност, която всеки път попада в рамките на няколко секунди от същата отметка, сочи към стойност от политика. Дължината на сесията също казва кой я е прекратил, защото изтичане на времето от страна на клиента и изтриване от страна на сървъра оставят различни последни редове в изхода за отстраняване на грешки. Трите повторни свързвания показват и дали интервалът се измества изобщо, което едно измерване не може да покаже.

Запишете числото до централния възел, с който сте говорили. След като интервалът е стабилен, остава изборът между три причини и точно една променена настройка на повторно свързване ги запазва различими.

Случай първи: клиентът изоставя бездействаща сесия

vpnc изпълнява собствена проверка за мъртъв партньор и тази проверка може да убие сесия, която концентраторът все още смята за жива, особено когато между двамата стои транслиращ шлюз. Средството от страна на клиента в документацията е таймерът да се изключи локално и централният възел да решава кога партньорът е изчезнал. И двата реда по-долу принадлежат в профила на vpnc или в командния ред и двата не зависят от настройките за криптиране.

DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp

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

Случай втори: подновяването на ключове е отказано

Ако интервалът оцелее след промяната на DPD, кандидат става подновяването на ключове във фаза 1. По-старите сборки на vpnc се справяха с подновяването по-небрежно от сегашните и обичайното разногласие е групата Diffie-Hellman. Налагането на група, която централният възел вече приема, струва един ред и едно повторно свързване, което го прави евтин експеримент, а не промяна на политика.

IKE DH Group dh5

Валидни имена на групи са dh1, dh2 и dh5. Група, която концентраторът отхвърля, дава незабавен провал и това пак е информация: казва ви, че централният възел е придирчив и първоначалната група вероятно е била правилна.

Случай трети: транслацията пренаписва инкапсулацията

Зад транслиращ шлюз UDP инкапсулацията на Cisco и режимът, базиран на стандарти, не са взаимозаменяеми. Грешният избор често дава тунел, който се установява, пропуска трафик и после изтича по време под натоварване, което изглежда като проблем с честотната лента и не е. Променете само режима, после се свържете отново и измерете прекъсването пак. Опитайте другия режим само след като първите два случая са изключени.

Фронтендовете добавят собствено объркване тук. NetworkManager няма да предложи тип връзка vpnc, докато пакетът на приставката не е инсталиран, а липсващата приставка се показва като сив бутон „Добавяне“, а не като грешка. Фронтендът на KDE пази същите стойности в собствен профил, затова потвърдете, че демонът чете това, което сте редактирали.

Профил, който се свързва добре от командния ред, но не от работния плот, е проблем на фронтенда, а не на таймера.

Проверете обмена, който се проваля, преди третата промяна

Стартирайте клиента с изход за отстраняване на грешки и прочетете последния обмен преди прекъсването. Изтриване на фаза 1 непосредствено преди разпадането означава, че клиентът е подновил ключовете и му е било отказано. Изтриване на фаза 2 на същото място означава, че тунелът е бил разглобен от другата страна и настройките на клиента ви не са причината.

vpnc --debug 3 office

Проверете също за втори мрежов демон, когато тунелът оцелява, но трафикът спира. Два мениджъра, които пишат таблицата за маршрутизация, дават същия симптом от работния плот и напълно различен журнал.