Што лакальныя сістэмныя журналы кажуць пра злучэнне VPN
Аперацыйная сістэма фіксуе запускі службаў, змены адаптараў і збоі маршрутаў, якія праграма ніколі не запісвае. Прачытайце адно вузкае акно і суаднясіце яго.
Кожны працоўны стол вядзе ўласны запіс пра тое, што рабіў VPN, і экспарт праграмы звычайна самы няпоўны з іх. Мэнэдары службаў адзначаюць, калі юніт запусціўся, ядро адзначае, калі з'явіўся інтэрфейс, а сеткавы стек адзначае, калі маршруты не ўдалося ўжыць. Ніводзін з гэтых сродкаў не ведае, што меў на ўвазе кліент, а кліент не ведае, што ядро зрабіла з яго запытам.
Чытанне аднаго такога запісу ў ізаляцыі схіляе да няправільнай высновы. Прачытайце два, з той самай хвіліны, і паслядоўнасць становіцца бачнай.
Тры сродкі з трыма слоўнікамі
У Linux журнал systemd захоплівае паведамленні жыццёвага цыклу юніта ад wg-quick@wg0 або плагіна VPN NetworkManager, а колавы буфер ядра нясе паведамленні інтэрфейса і маршрутызацыі. У Windows журнал падзей раздзяляе гісторыю паміж пастаўшчыкамі сістэмных, WLAN і аддаленага доступу, кожны са сваімі ідэнтыфікатарамі. У macOS аб'яднаны журнал нясе паведамленні падсістэм, якія графічная Console паказвае толькі часткова.
Слоўнікі не перакладаюцца. Ідэнтыфікатар падзеі адной платформы нічога не значыць на іншай, а здымак экрана дыялога Windows нічога не даказвае пра юніт Linux.
Агульнае ўсіх трох — гэта адзнака часу, крыніца і ўзровень значнасці, і менавіта гэтая тройка робіць магчымым суаднясенне кліенцкага журнала з запісам аперацыйнай сістэмы. Даступнасць таксама розніцца: кантэйнер без журнала, усячоны вобраз Windows або ўзровень журнала, зніжаны падчас зборкі, могуць схаваць цэлы пласт.
| Facility | What it records | What it cannot show |
|---|---|---|
| systemd journal | Unit start and stop, helper output, exit status | Whether packets actually reached the peer |
| Kernel and netlink | Interface creation, address assignment, route changes | Why the client asked for that configuration |
| Windows event log | Provider-specific connection and adapter events | Anything the provider chose not to log |
Што даказвае падключаны радок і што не
Падзея запуску службы фіксуе, што лакальны юніт папрасілі запусціць і што ён не выйшаў адразу. Яна не фіксуе завершанага рукапаціскання, сапраўднага ключа партнёра або працоўнага маршруту. Успрымаць гэты радок як доказ тунэля — найбольш распаўсюджанае памылковае чытанне такіх журналаў. Радок даказвае намер і стан працэса, і зусім нічога пра дасягальнасць.
Стан перасылкі — гэта асобнае назіранне, і яно прыходзіць з табліцы маршрутызацыі, а не з якога-небудзь журнала.
Падзея адаптара можа патлумачыць ціхі збой: інтэрфейс падняўся, адрас быў прызначаны, а маршруты ніколі не ўсталявалі, бо правіла палітыкі іх адхіліла. У гэтай паслядоўнасці кожны бачны радок выглядае здаровым, пакуль нішто не маршрутызуецца, і адзіны спосаб убачыць гэта — параўнаць адзнакі часу журнала з табліцай маршрутызацыі ў той самы момант. Трымайце ўласны парадак падзей кліента побач з абодвума, бо кліент — адзіная крыніца, якая ведае, што ён запытаў. Два факты, патрэбныя разам, амаль ніколі не з'яўляюцца ў адным радку.
Пазнейшае перападключэнне перазапісвае цікавую частку гэтай карціны, таму фіксуйце акно пры першым збоі, а не пасля трох спробаў.
Суаднясіце вузкае акно
Запішыце час спробы разам з яго часавым поясам, затым выцягніце колькі хвілін вакол яго. Першая памылка ў акне амаль заўсёды папярэднічае радку адключэння, які цытуюць заяўкі падтрымкі.
journalctl -u wg-quick@wg0 --since "today 09:00" --until "today 09:20" ip route show table all | grep wg0 log show --last 20m --predicate 'subsystem == "com.apple.network"'
Кожная каманда адказвае на розную частку пытання: першая дае жыццёвы цыкл, другая — стан перасылкі, трэцяя — сеткавую падсістэму macOS. У Windows фільтруйце сістэмны журнал па назве пастаўшчыка, а не пракручвайце ўвесь канал, і экспартуйце толькі адпаведныя падзеі.
Трымайце вытрымку дастаткова малой, каб чытач мог яе прасачыць. Акно ў дваццаць хвілін з чатырма значнымі падзеямі падмацоўвае выснову; экспарт за цэлы дзень з тысячамі радкоў не падмацоўвае нічога.
Дзе гэтыя запісы спыняюцца
Лакальныя запісы апісваюць прыладу, а не шлях. Яны не могуць паказаць, што захаваў пастаўшчык, ці была сесія суаднесена з уліковым запісам або што ўбачыў пункт прызначэння. Заява пастаўшчыка пра тое, што ён не захоўвае журналаў, нічога не кажа пра аперацыйную сістэму на вашым ноўтбуку, а лакальная падзея нічога не даказвае пра гістарычныя запісы пастаўшчыка.
Яны таксама нясуць больш персанальных даных, чым чакалася: імёны карыстальнікаў, імёны хастоў, шляхі мантавання і ідэнтыфікатары прылад з'яўляюцца ў звычайных сістэмных паведамленнях, нават калі няма ніякага змесціва аглядання. Выдаліце іх, перш чым нешта далучыць да заяўкі, і захоўвайце арыгінал пад звычайным кантролем доступу.
На кіраванай прыладзе запытайце адпаведную вытрымку ў ІТ, а не спрабуйце ачысціць арганізацыйныя журналы. Дыягнастычная мэта — адно вузкае пытанне, на якое адказваюць дзве крыніцы, а не поўная гісторыя машыны.