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 и фрагментација, а не во тајмер за мирување.
За случајот на мирување, поставките зависат од протоколот и двата краја се важни. keepalive 10 60 на OpenVPN на серверот испраќа пинг на секои 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 кога ви треба точното значење на некоја вредност.