VPN постоянно ли прекъсва? Действайте в този ред

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

Първа стъпка: запишете интервала и текста на грешката

Започнете със собствения дневник на клиента, а не с таблото на доставчика. При Linux клиент дневникът на услугата плюс живото състояние на тунела покрива голяма част от това:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Запишете времевите марки на последния успешен ръкостиск и момента, в който трафикът е спрял, а не само момента, в който иконата е сменила цвят. GUI клиент, който казва „прекъснато“ след факта, може да съобщава за състояние, което ядрото е достигнало секунди по-рано.

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

Втора стъпка: сменете една променлива, а не профила

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

Лаптоп с Ethernet порт ви дава второ сравнение, което напълно изважда Wi-Fi от картината. Ако тунелът се държи и при двата варианта, първоначалната мрежа за достъп заслужава внимание: роуминг между точки за достъп, домашен рутер с изтичаща таблица за транслация или връзка нагоре, която нулира дълготрайни потоци.

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

Трета стъпка: свържете интервала със слой

Дължината на добра сесия е най-информативното единично число, с което разполагате. Сверете я с този списък, преди да пипате таймерите:

• Прекъсване след сън или възобновяване: състоянието на тунела е преживяло спирането, но интерфейсът не. Проверете поведението на клиента при повторно свързване след възобновяване и дали услугата рестартира тунела или чака трафик.
• Прекъсване само при бездействие: нещо по средата е изтекло потока. Точно за този случай съществуват keepalive.
• Прекъсване при фиксирана възраст на сесията: събитие за повторно удостоверяване или подмяна на ключ, а не отказ на пътя. Явният отказ в дневника точно на този интервал е признакът.
• Прекъсване при големи трансфери или големи страници: подозирайте MTU и фрагментация, а не таймер за бездействие.

За случая на бездействие настройките са специфични за протокола и двете страни имат значение. На OpenVPN keepalive 10 60 на сървъра изпраща ping на всеки 10 секунди и рестартира връзката след 60 секунди без такъв; WireGuard клиентите зад NAT използват PersistentKeepalive = 25 в блока на партньора. OpenVPN също преговаря отново канала за данни по таймер, reneg-sec, който по подразбиране е 3600 секунди в 2.x.

Не копирайте агресивни стойности от ръководството на друг доставчик. Кратко изчакване при мобилна връзка със загуби произвежда именно прекъсванията, които е трябвало да предотврати, а изпратените от сървъра стойности имат предимство пред зададените в профила на клиента.

Четвърта стъпка: сравнете една поддържана алтернатива

Ако операторът публикува и UDP, и TCP профил, пуснете същото устройство и мрежа срещу другия. Използвайте действителния съответстващ файл, вместо да редактирате транспорта в копиран профил. Стабилен TCP профил по път, където UDP се нулира, стеснява проблема до този път; той не доказва, че TCP е по-добрият транспорт навсякъде.

Същата логика важи за крайните точки. Опитайте друг сървър и дръжте първоначалния резултат до него. Ако само един изход нулира сесии, това е доказателство за тази крайна точка, а не причина да преправяте всеки адаптер на лаптопа.

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

Проверете поправката и запазете възможността за връщане назад

Поправка се проверява чрез възпроизвеждане на първоначалния тригер, а не чрез успешна връзка. Оставете тунела в бездействие след стария интервал на отказ, спрете и възобновете веднъж и след това проверете възрастта на ръкостиска и адреса на изхода:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

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

Ако дневникът остане чист, а тунелът все още прекъсва на повтарящ се интервал, следващата спирка е сървърната страна за тази сесия. Вземете със себе си идентификатора на сесията на клиента и точния час на прекъсването, защото точно тази двойка прави сървърния дневник търсим. Опциите за връзка на протокола са документирани в ръководството за OpenVPN 2.6 когато ви трябва точната семантика на дадена стойност.