Hva lokale systemlogger avslører om en VPN-tilkobling
Operativsystemet registrerer tjenestestarter, adapterendringer og rutefeil som en app aldri skriver ned. Les ett smalt vindu og korreler det.
Hver stasjonære datamaskin fører sin egen registrering av hva en VPN gjorde, og eksporten fra applikasjonen er vanligvis den minst komplette av dem. Tjenestebehandlere noterer når en enhet startet, kjernen noterer når et grensesnitt dukket opp, og nettverksstakken noterer når ruter ikke kunne brukes. Ingen av disse fasilitetene vet hva klienten hadde til hensikt, og klienten vet ikke hva kjernen gjorde med forespørselen.
Å lese én slik registrering isolert inviterer til den gale konklusjonen. Les to, fra samme minutt, og rekkefølgen blir synlig.
Tre fasiliteter med tre vokabularer
På Linux fanger systemd-journalen livssyklusmeldinger for enheten fra wg-quick@wg0 eller NetworkManager VPN-plugin, og kjernens ringbuffer bærer grensesnitt- og rutemeldinger. På Windows fordeler hendelsesloggen historien på system-, WLAN- og fjern tilgang-leverandører, hver med sine egne identifikatorer. På macOS bærer den samlede loggen subsystembegrensede meldinger som den grafiske Console bare delvis viser.
Vokabularene oversetter ikke. En hendelsesidentifikator fra én plattform betyr ingenting på en annen, og et skjermbilde av en Windows-dialog beviser ingenting om en Linux-enhet.
Det alle tre deler, er et tidsstempel, en kilde og en alvorlighetsgrad, og nettopp den trioen gjør korrelasjon mulig mellom en klientlogg og en registrering i operativsystemet. Tilgjengeligheten varierer også: en container uten journal, et trimmet Windows-avtrykk eller et loggnivå som er senket ved bygging kan skjule et helt 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 |
Hva en tilkoblet linje beviser og ikke beviser
En hendelse for tjenestestart registrerer at den lokale enheten ble bedt om å starte og at den ikke avsluttet med en gang. Den registrerer ikke et fullført håndtrykk, en gyldig peer-nøkkel eller en fungerende rute. Å behandle den linjen som bevis på en tunnel er den vanligste feillesningen av disse loggene. Linjen beviser hensikt og prosesstilstand, og absolutt ingenting om tilgjengelighet.
Videresendingstilstanden er en egen observasjon, og den kommer fra rutetabellen og ikke fra noen logg.
En adapterhendelse kan forklare en stille feil: grensesnittet kom opp, adressen ble tildelt, og rutene ble aldri installert fordi en policyregel avviste dem. I den sekvensen ser hver synlig linje sunn ut mens ingenting rutes, og den eneste måten å se det på er å sammenligne loggens tidsstempler med rutetabellen i samme øyeblikk. Hold klientens egen hendelsesrekkefølge ved siden av begge, fordi klienten er den eneste kilden som vet hva den ba om. De to fakta du trenger sammen, dukker nesten aldri opp på samme linje.
En senere gjenoppkobling overskriver den interessante delen av bildet, så fang vinduet ved første feil i stedet for etter tre forsøk.
Korreler et smalt vindu
Noter forsøkstiden med tidssonen, og trekk deretter ut de få minuttene rundt. Den første feilen i vinduet kommer nesten alltid før frakoblingslinjen som støttebilletter 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"'
Hver kommando svarer på en annen del av spørsmålet: den første gir livssyklusen, den andre videresendingstilstanden, den tredje macOS-nettverkssubsystemet. På Windows filtrerer du systemloggen på leverandørnavn i stedet for å rulle gjennom hele kanalen, og eksporterer bare de samsvarende hendelsene.
Hold utdraget lite nok til at en leser kan følge det. Et vindu på tjue minutter med fire relevante hendelser støtter en konklusjon; en eksport for en hel dag med tusener av linjer støtter ingenting.
Hvor disse registreringene stopper
Lokale registreringer beskriver enheten, ikke veien. De kan ikke vise hva en leverandør lagret, om en økt ble koblet til en konto, eller hva en destinasjon så. En leverandørs uttalelse om at de ikke fører logger sier ingenting om operativsystemet på laptopen din, og en lokal hendelse beviser ingenting om leverandørens historiske registreringer.
De bærer også mer personopplysninger enn forventet: brukernavn, vertsnavn, monteringsstier og enhetsidentifikatorer dukker opp i vanlige systemmeldinger selv når det ikke finnes noe nettleserinnhold. Fjern dem før du legger ved noe i en sak, og oppbevar originalen under normale tilgangskontroller.
På en administrert enhet ber du IT om det relevante utdraget i stedet for å prøve å slette organisasjonslogging. Det diagnostiske målet er ett smalt spørsmål besvart av to kilder, ikke en fullstendig historie om maskinen.