Kva lokale systemloggar avdekkjer om ei VPN-tilkopling
Operativsystemet registrerer tenestestartar, adapterendringar og rutefeil som ein app aldri skriv ned. Les eitt smalt vindauge og korreler det.
Kvar stasjonære datamaskin fører si eiga registrering av kva ein VPN gjorde, og eksporten frå applikasjonen er vanlegvis den minst komplette av dei. Tenestebehandlarar noterer når eininga starta, kjernen noterer når eit grensesnitt dukka opp, og nettverksstakken noterer når ruter ikkje kunne brukast. Ingen av desse fasilitetane veit kva klienten hadde til hensikt, og klienten veit ikkje kva kjernen gjorde med førespurnaden.
Å lese éi slik registrering isolert inviterer til den galne konklusjonen. Les to, frå same minutt, og rekkjefølgja vert synleg.
Tre fasilitetar med tre vokabular
På Linux fangar systemd-journalen livssyklusmeldingar for eininga frå wg-quick@wg0 eller NetworkManager VPN-plugin, og ringbufferen til kjernen ber grensesnitt- og rutemeldingar. På Windows fordeler hendingsloggen historia på system-, WLAN- og fjernåtkomst-leverandørar, kvar med sine eigne identifikatorar. På macOS ber den samla loggen subsystemavgrensa meldingar som den grafiske Console berre delvis viser.
Vokabulariet omset ikkje. Ein hendingsidentifikator frå éin plattform tyder ingenting på ein annan, og eit skjermbilete av ein Windows-dialog beviser ingenting om ei Linux-eining.
Det alle tre deler, er eit tidsstempel, ein kjelde og ein alvorsgrad, og nettopp den trioen gjer korrelasjon mogleg mellom ein klientlogg og ei registrering i operativsystemet. Tilgjengelegheita varierer òg: ein container utan journal, eit trimma Windows-avtrykk eller eit loggnivå som er senka ved bygging kan skjule eit heilt lag.
| 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 |
Kva ei tilkopla linje beviser og ikkje beviser
Ei hending for tenestestart registrerer at den lokale eininga vart bede om å starte og at ho ikkje avslutta med ein gong. Ho registrerer ikkje eit fullført handtrykk, ein gyldig peer-nøkkel eller ei fungerande rute. Å handsame den linja som bevis på ein tunnel er den vanlegaste feillesinga av desse loggane. Linja beviser hensikt og prosesstilstand, og absolutt ingenting om tilgjenge.
Vidaresendingstilstanden er ein eigen observasjon, og han kjem frå rutetabellen og ikkje frå nokon logg.
Ei adapterhending kan forklare ein stille feil: grensesnittet kom opp, adressa vart tildelt, og rutene vart aldri installerte fordi ein policyregel avviste dei. I den sekvensen ser kvar synleg linje sunn ut medan ingenting vert ruta, og den einaste måten å sjå det på er å samanlikne tidsstempla i loggen med rutetabellen i same augneblink. Hald klienten si eiga hendingsrekkjefølgje ved sida av begge, fordi klienten er den einaste kjelda som veit kva han bad om. Dei to fakta du treng saman, dukkar nesten aldri opp på same linje.
Ein seinare gjenoppkopling skriv over den interessante delen av bildet, så fang vindauget ved første feil i staden for etter tre forsøk.
Korreler eit smalt vindauge
Noter forsøkstida med tidssona, og trekk deretter ut dei få minutta rundt. Den første feilen i vindauget kjem nesten alltid før fråkoplinglinja som støttebillettar siterer.
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"'
Kvar kommando svarer på ein annan del av spørsmålet: den første gir livssyklusen, den andre vidaresendingstilstanden, den tredje macOS-nettverkssubsystemet. På Windows filtrerer du systemloggen på leverandørnamn i staden for å rulle gjennom heile kanalen, og eksporterer berre dei samsvarande hendingane.
Hald utdraget lite nok til at ein lesar kan følgje det. Eit vindauge på tjue minutt med fire relevante hendingar støttar ein konklusjon; ein eksport for ein heil dag med tusentals linjer støttar ingenting.
Kvar desse registreringane stoppar
Lokale registreringar skildrar eininga, ikkje vegen. Dei kan ikkje vise kva ein leverandør lagra, om ei økt vart kopla til ein konto, eller kva ein destinasjon såg. Ei fråsegn frå ein leverandør om at dei ikkje fører loggar seier ingenting om operativsystemet på laptoppen din, og ei lokal hending beviser ingenting om dei historiske registreringane til leverandøren.
Dei ber òg meir personopplysningar enn venta: brukarnamn, vertsnamn, monteringsstiar og einingidentifikatorar dukkar opp i vanlege systemmeldingar sjølv når det ikkje finst noko nettlesarinnhald. Fjern dei før du legg ved noko i ein sak, og oppbevar originalen under normale tilgjengekontrollar.
På ei administrert eining ber du IT om det relevante utdraget i staden for å prøve å slette organisasjonslogginga. Det diagnostiske målet er eitt smalt spørsmål svart av to kjelder, ikkje ei fullstendig historie om maskinen.