DigitalForensics

70 13 63 23

VPN‑logs: sessioner, tildelte adresser og datamængder

VPN-logs: sessioner, tildelte adresser og datamængder

Forside › Netværk og logs · Gennemgået oktober 2026 · Af John Nielsen

En VPN-log for fjernadgang binder tre ting sammen, som ellers ligger i hver sin kilde: den konto, der loggede ind, den offentlige IP-adresse, forbindelsen kom fra, og den interne IP-adresse, som VPN-løsningen tildelte. Dertil kommer ofte sessionens start, slut og datamængde. Det gør VPN-loggen til nøglen, når trafik i firewall-, proxy- eller serverlogs fra en intern adresse skal kobles til en bruger, der arbejdede hjemmefra. Men datamængderne dækker kun den trafik, der faktisk gik gennem tunnelen, og en aktiv session er ikke det samme som arbejde.

Haster det? VPN-loggen ligger ofte kun på gatewayen med begrænset plads og overskrives løbende, og uden den kan en intern adresse ikke kobles til en bruger. Kontakt os via akut forensisk sikring; hastesager koster ekstra.

Felterne i en VPN-log

  • Brugernavn · Kontoen, der godkendte sessionen
  • Offentlig kilde-IP · Den adresse, klienten forbandt fra
  • Tildelt intern IP · Adressen fra VPN-puljen, som trafikken bruger i netværket
  • Start og slut · Tidspunkt for oprettelse og afslutning
  • Varighed · Sessionens længde
  • Bytes ind og ud · Datamængde gennem tunnelen hver vej
  • Godkendelsesmetode · Adgangskode, certifikat, MFA eller kombination
  • Klientoplysninger · Klientversion, styresystem, enhedsnavn eller certifikat
  • Afslutningsårsag · Brugeren afbrød, timeout, netværksfejl eller administrator

Hvilke felter der findes, afhænger af produkt og opsætning. Nogle løsninger logger kun start og slut, andre også periodiske opdateringer med løbende tællere. Notér, hvilke felter der var til rådighed, og hvad de præcist betyder i det konkrete produkt.

Typer af VPN

  • Fjernadgang for brugere: En klient på computeren opretter tunnelen, ofte med en kombination af brugerens konto og et certifikat. Det er den type, denne artikel primært handler om.
  • Altid-tilsluttet eller maskintunnel: Computeren opretter tunnelen automatisk, før brugeren logger ind, så den kan nå domænecontrolleren. Sessionen står da med computerens identitet, ikke brugerens.
  • Site-to-site: Forbindelser mellem kontorer eller til en leverandør. De har ingen brugere og vises som en permanent tunnel.
  • Cloudbaseret adgang: Moderne løsninger giver adgang til enkelte applikationer i stedet for hele netværket. De logger ofte pr. applikation og ligner mere en proxy end en klassisk VPN.

Split tunneling og datamængder

Med fuld tunnel går al klientens trafik gennem VPN’en og dermed gennem virksomhedens firewall. Med split tunneling går kun trafik til virksomhedens egne netværk eller udvalgte tjenester gennem tunnelen, mens resten, fx trafik til Microsoft 365 eller private cloudtjenester, går direkte fra brugerens hjemmeforbindelse.

Konsekvensen for en undersøgelse er stor. En lav datamængde i VPN-loggen udelukker ikke, at store mængder data blev hentet fra en cloudtjeneste eller sendt til en privat tjeneste. Og en høj datamængde kan være videomøder, opdateringer eller backup. Gem derfor VPN-profilens konfiguration og ruter fra perioden, så det kan dokumenteres, hvilken trafik der gik gennem tunnelen.

Byte-tællerne er målt på tunnelniveau og indeholder protokoloverhead, kryptering og gentagelser. De kan ikke omsættes direkte til filstørrelser. Brugt med forsigtighed kan de vise, at en session i et bestemt tidsrum havde usædvanlig meget udgående trafik, hvilket peger videre til firewall- og serverlogs for samme interne adresse. Se Firewall-logs teknisk.

Kobling af intern adresse til bruger

Når en intern adresse fra VPN-puljen optræder i en anden log, findes brugeren ved at slå tidspunktet op i VPN-loggen og finde den session, der havde adressen. Puljeadresser genbruges, ofte inden for minutter, så tidspunkterne skal være normaliseret og sessionsgrænserne præcise. En hændelse kort efter, at en session sluttede, kan tilhøre den næste bruger af adressen.

Den offentlige kilde-IP kan vise, hvorfra brugeren forbandt, men med de forbehold, der gælder for alle offentlige adresser: mobilnet, CGNAT, hoteller og private VPN-tjenester. Se IP-adresser som bevis.

Fejlkilder i fortolkningen

  • Automatisk genforbindelse. Klienter opretter nye sessioner efter dvale, netværksskift eller kortvarige fejl. Mange korte sessioner er ofte teknik, ikke adfærd.
  • Inaktive sessioner. En session kan være åben i timer uden brugeraktivitet, hvis timeout er lang, eller hvis baggrundsprocesser holder den i live.
  • Delte konti og maskintunneler. Sessioner uden personlig konto kan ikke kobles til en person.
  • MFA-godkendelse fra telefon. At sessionen blev godkendt med en app, viser, at nogen godkendte på den registrerede enhed, ikke at det var kontoens ejer, der sad ved computeren.
  • Tidszoner og forskel mellem VPN-koncentratorens ur og andre systemer.

VPN-logs og arbejdstid

VPN-logs bruges nogle gange til at belyse arbejdstid i en ansættelsestvist. Teknisk kan de vise, hvornår en session var aktiv, og hvor meget data der gik gennem den. De kan ikke vise, om der blev arbejdet. Med split tunneling og cloudbaserede systemer kan meget arbejde ske helt uden VPN, og en åben session kan stå uden aktivitet. Brug sammen med andre kilder, fx loginlogs fra fagsystemer og dokumentaktivitet, og beskriv begrænsningerne. Den juridiske side er beskrevet i Arbejdstid og overarbejde: logdata som bevis.

VPN-logs og dataudtræk ved fratræden

I sager om data taget ved fratræden kan VPN-loggen vise, om medarbejderen havde forbindelse til netværket uden for normal arbejdstid i de sidste uger, og hvilken intern adresse der skal undersøges i fil- og serverlogs. Den indgår typisk som én af flere kilder i den samlede plan; se Data taget ved fratræden: den tekniske undersøgelsesplan.

Når VPN-løsningen drives af en leverandør

Mange mindre virksomheder har VPN i en firewall, som en IT-leverandør administrerer. Loggen kan da ligge i leverandørens centrale logsystem eller kun i firewallens lokale buffer. Bed leverandøren om eksport og bevarelse straks, og bed om en beskrivelse af, hvordan eksporten er lavet. Notér, om leverandøren selv har ændret opsætningen i perioden, fx skiftet godkendelsesmetode eller opdateret firmware.

Sikring

  1. Eksportér VPN-loggen fra koncentratoren, firewallen eller den cloudbaserede løsning for hele perioden, gerne bredere end den formodede hændelse.
  2. Hent videresendte kopier fra syslog-server eller SIEM-system, som ofte dækker længere tid.
  3. Gem konfigurationen: VPN-profiler, split tunneling-ruter, adressepuljer, timeout, godkendelsesmetoder og logindstillinger.
  4. Hent godkendelseslogs fra RADIUS eller identitetsudbyderen, hvis VPN-login går derigennem.
  5. Notér tidszone og tidssynkronisering.
  6. Beregn hashværdier for eksporterne.

Hvad VPN-loggen kan og ikke kan bevise

VPN-loggen kan vise, at en konto havde en session fra en bestemt offentlig adresse i et bestemt tidsrum med en bestemt intern adresse og en bestemt datamængde gennem tunnelen. Den kan koble interne adresser i andre logs til en konto. Den kan ikke vise indhold, filer eller arbejde, og den kan ikke alene vise, hvem der brugte kontoen. Den grundlæggende forklaring af VPN-logs for ikke-teknikere findes i Firewall-, VPN- og loginlogs.

Dokumentation

Angiv produkt og version, logkilder, felter og deres betydning, tidszone, periode, eksportmetode og hashværdier. Beskriv VPN-profilens opsætning i perioden, især split tunneling og timeout, fordi den afgør, hvad datamængder og sessionslængder kan bruges til. Hvis adressepuljen er lille, og adresser genbruges hurtigt, skal det fremgå, hvordan koblingen til en bestemt session er foretaget, og hvor stor tidsmargin der er brugt. Vedlæg også de godkendelseslogs, der understøtter, hvem der loggede ind.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Netværk og logs

Læs også: Firewall-logs teknisk: sessioner, NAT og tidsstempler · Proxy- og webfilterlogs

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik

John Nielsen, IT-sagkyndig

Brug for en forensisk undersøgelse?

Skriv kort, hvilke systemer eller enheder det drejer sig om, og om noget haster, så vender jeg tilbage. Kun civile sager.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.