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 калі вам патрэбна дакладная семантыка значэння.

Падобныя артыкулы