VPN мёртвы пасля сну: тунель зваліўся ці праграма састарэла?

Вечка адкрываецца, значок бесправадной сеткі вяртаецца, а VPN усё яшчэ паказвае падключэнне. Затым першая ўнутраная старонка завісае да сканчэння чакання, і новая ўкладка робіць тое ж самае. Тры розныя рэчы могуць стварыць гэтую карціну, і ім патрэбныя тры розныя выпраўленні: тунель, які не перажыў сон, профіль, які ніхто не прасіў актываваць зноў, або праграма, якая ўсё яшчэ трымае сесію, што памерла некалькі гадзін таму. Параўноўваць іх хутчэй, чым нешта пераўсталёўваць.

Тры рэчы могуць зламацца пасля абуджэння

Першы кандыдат — сам тунель. Інтэрфейс можа яшчэ існаваць з адрасам, пакуль сувязь з пірам знікла, і таму індыкатар не з'яўляецца доказам працоўнага шляху. Рукаяціск, старэйшы за сон, — гэта прыкмета, і каб яе ўбачыць, дастаткова адной каманды.

Другі — актывацыя. Многія кліенты перападключаюцца самі; некаторыя не робяць гэтага, і профіль, які не просяць вярнуцца, проста стаіць і выглядае наладжаным. Гэтая няўдача маўклівая па задуме, бо нічога не выдала памылку.

Трэці — праграма. Укладка браўзера, сесія SSH або злучэнне з базай даных могуць перажыць змену сеткі як дэскрыптар файла, пакуль транспарт пад імі мёртвы. Тады новая сесія працуе ідэальна, і гэта кажа вам, што тунель быў у парадку ўвесь час.

Параўнайце трох, перш чым нешта змяняць, бо выпраўленні не перакрываюцца. Перазапуск кліента, які ніколі не прасілі запусціць зноў, марнуе доказы, якія вам былі патрэбныя. Запішыце, якому кандыдату адпавядае сімптом, перш чым чапаць канфігурацыю. Гэтае адно сказ вырашае рэшту расследавання.

Першае: ці вярнуўся тунель?

Глядзіце на інтэрфейс і стан піра, а не на ўласны тэкст стану кліента. Інтэрфейс з адрасам і без нядаўняга рукаяціску — гэта тунель, які існуе толькі на словах.

ip -brief addr show
wg show
ip route show table all | head -20

Калі інтэрфейса няма зусім, тунель не перажыў, і пытанне становіцца такім: хто павінен быў яго вярнуць. Калі ён ёсць, але рукаяціск стары, сувязь з пірам трэба аднавіць, і кліент можа чакаць трафіку, каб яе запусціць.

Праверце таксама маршруты і налады DNS. Тунель можа вярнуцца без сваіх маршрутаў, і гэта стварае заблытаны стан, калі інтэрфейс працуе, а ўнутраныя імёны ўсё яшчэ вырашаюцца праз няправільны сервер.

Другое: ці прасіў хто-небудзь яго вярнуцца?

Менавіта тут параўнанне апраўданае. Профіль плагіна OpenVPN і ўласнае злучэнне WireGuard апрацоўваюцца NetworkManager па-рознаму, і даведнік па наладах злучэння ясна кажа, што connection.autoconnect не актывуе профілі VPN; механізм падняцця VPN разам са злучэннем — гэта connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Калі ручное перападключэнне выпраўляе праблему кожны раз, гэта подпіс адсутнай актывацыі, а не зламанага тунеля. Журнал звычайна пакажа, як інтэрфейс апускаецца і нішто яго не вяртае.

Супраціўляйцеся жаданню адразу дадаць хук сну. Хук, які зпрацоўвае раней, чым сетка аднавілася, спаборнічае з тым самым працэсам, якому спрабуе дапамагчы, і ператварае паўторную праблему ў перамежную.

Трэцяе: ці трымае праграма стары стан?

Адкрыйце зусім новую сесію да той жа мэты, перш чым чапаць VPN. Калі новая сесія працуе, а старая не, тунель у парадку, і праграма трымае мёртвае злучэнне.

Гэта самая танцная з трох праверак і тая, якую найчасцей прапускаюць, бо акно збою проста на экране. Закрыйце яго, адкрыйце зноў і адзначце, ці засталася праблема. Калі новая сесія працуе, цалкам спыніце даследаванне тунеля. Калі яна таксама не працуе, праграма — сімптом, а не прычына.

Некаторыя праграмы аднаўляюцца самі пасля чакання, і таму сімптом можа выглядаць так, быццам ён выправіў сябе праз некалькі хвілін. Такія паводзіны паказваюць на праграму, а не на тунель, і гэта варта запісаць асобна. Каллега, які кажа, што яно само выправілася, апісвае гэты ўзор, а не шчаслівую выпадковасць.

Зрабіце параўнанне паўторным

Трымайце зменныя малымі: адна сетка доступу, адна працягласць сну і адзін і той жа першы запыт кожны раз. Затым запішыце два вынікі: ці выпраўляе гэта ручное перападключэнне і ці вяртае збой чарговы сон.

Менавіта апошняе назіранне надзейней за ўсё раздзяляе трох кандыдатаў. Працоўная новая сесія пасля няўдалай старой — гэта не праблема тунеля, і ніякая пераўсталёўка кліента гэтага не зменіць.

Пастаянны keepalive WireGuard трапляе ў гэтую карціну толькі як keepalive для адлюстравання NAT. Ён шле пакеты, каб трымаць адлюстраванне адкрытым; ён не замінае машыне засынаць і не можа працягваць слаць, пакуль працэс прыпынены.

Запішыце ў тыкеце, што вы знайшлі: які з трох быў зламаны, што яго выправіла і як вы гэта паўтарылі. Наступны чалавек, які ў панядзелак адкрые вечка, падзякуе вам, і адказ не давядзецца шукаць з нуля.