Kion lokaj sistemaj protokoloj malkaŝas pri VPN-konekto
La operaciumo registras servajn startojn, adaptilajn ŝanĝojn kaj vojerarojn, kiujn aplikaĵo neniam skribas. Legu unu mallarĝan fenestron kaj kunrilatigu ĝin.
Ĉiu labortablo tenas sian propran registron pri tio, kion faris VPN, kaj la eksportaĵo de la aplikaĵo kutime estas la plej nekompleta el ili. Servadministrantoj notas, kiam unuo ekfunkciis, la kerno notas, kiam interfaco aperis, kaj la retstako notas, kiam vojoj ne povis esti aplikitaj. Neniu el tiuj instalaĵoj scias, kion la kliento intencis, kaj la kliento ne scias, kion la kerno faris kun ĝia peto.
Legi unu tian registron izolite invitas la malĝustan konkludon. Legu du, el la sama minuto, kaj la sinsekvo fariĝas videbla.
Tri instalaĵoj kun tri vortaroj
En Linux la ĵurnalo systemd kaptas unuociklajn mesaĝojn de wg-quick@wg0 aŭ de la VPN-kromprogramo NetworkManager, kaj la cirkla bufro de la kerno portas interfacajn kaj vojigajn mesaĝojn. En Windows la eventa protokolo dividas la rakonton inter sistemaj, WLAN kaj fora aliro provizantoj, ĉiu kun propraj identigiloj. En macOS la unuigita protokolo portas mesaĝojn limigitajn al subsistemo, kiujn la grafika Console nur parte montras.
La vortaroj ne tradukiĝas. Eventa identigilo de unu platformo signifas nenion sur alia, kaj ekrankopio de Windows-dialogaĵo pruvas nenion pri Linux-unuo.
Kion ĉiuj tri kunhavas estas tempstampo, fonto kaj graveco, kaj ĝuste tiu triopo ebligas korelacion inter klienta protokolo kaj operaciuma registro. Ankaŭ disponebleco varias: ujo sen ĵurnalo, stumpigita Windows-bildo aŭ protokolnivelo malaltigita dum konstruado povas kaŝi tutan tavolon.
| 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 |
Kion pruvas konektita linio kaj kion ne
Serva starta evento registras, ke la loka unuo estis petita ekfunkcii kaj ke ĝi ne tuj eliris. Ĝi ne registras finitan manpremon, validan samtavolan ŝlosilon aŭ funkciantan vojon. Trakti tiun linion kiel pruvon de tunelo estas la plej ofta mislego de tiuj protokoloj. La linio pruvas intencon kaj procesan staton, kaj tute nenion pri atingeblo.
La plusenda stato estas aparta observo, kaj ĝi venas el la vojiga tabelo kaj ne el iu ajn protokolo.
Adaptila evento povas klarigi silentan fiaskon: la interfaco leviĝis, la adreso estis atribuita, kaj la vojoj neniam estis instalitaj ĉar politika regulo malakceptis ilin. En tiu sinsekvo ĉiu videbla linio aspektas sana dum nenio estas vojigata, kaj la sola maniero vidi tion estas kompari la tempstampojn de la protokolo kun la vojiga tabelo en la sama momento. Tenu la propran eventan ordon de la kliento apud ambaŭ, ĉar la kliento estas la sola fonto, kiu scias, kion ĝi petis. La du faktoj, kiujn vi bezonas kune, preskaŭ neniam aperas en la sama linio.
Pli posta rekonekto superskribas la interesan parton de tiu bildo, do kaptu la fenestron ĉe la unua fiasko anstataŭ post tri provoj.
Kunrilatigu mallarĝan fenestron
Registru la provan tempon kun ĝia horzono, poste eltiru la kelkajn minutojn ĉirkaŭ ĝi. La unua eraro en la fenestro preskaŭ ĉiam antaŭas la malkonektan linion, kiun citas subtenaj biletoj.
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"'
Ĉiu komando respondas al malsama parto de la demando: la unua donas la vivciklon, la dua la plusendan staton, la tria la macOS-retan subsistemon. En Windows filtru la sisteman protokolon laŭ provizanta nomo anstataŭ rulumi la tutan kanalon, kaj eksportu nur la kongruajn eventojn.
Tenu la eltiraĵon sufiĉe malgranda, ke leganto povu sekvi ĝin. Fenestro de dudek minutoj kun kvar rilataj eventoj subtenas konkludon; eksportaĵo por tuta tago kun miloj da linioj subtenas nenion.
Kie tiuj registroj haltas
Lokaj registroj priskribas la aparaton, ne la vojon. Ili ne povas montri, kion provizanto konservis, ĉu seanco estis parigita al konto, aŭ kion vidis celo. Aserto de provizanto, ke ĝi ne tenas protokolojn, diras nenion pri la operaciumo sur via tekkomputilo, kaj loka evento pruvas nenion pri la historiaj registroj de la provizanto.
Ili ankaŭ portas pli da personaj datumoj ol oni atendas: uzantnomoj, gastignomoj, muntaj vojoj kaj aparatidentigiloj aperas en ordinaraj sistemaj mesaĝoj eĉ kiam neniu retuma enhavo ĉeestas. Forigu ilin antaŭ ol aldoni ion al bileto, kaj tenu la originalon sub normalaj alirkontroloj.
Sur administrata aparato, petu la rilatan eltiraĵon de la IT-fako anstataŭ provi viŝi organizan protokoladon. La diagnoza celo estas unu mallarĝa demando respondita de du fontoj, ne kompleta historio de la maŝino.