IP‑adresser som bevis: NAT, CGNAT, VPN og geolokationens fejl

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

En IP-adresse i en log viser, hvilket netværkspunkt en forbindelse så ud til at komme fra, set fra den server, der skrev loggen. Den viser ikke, hvilken person eller hvilken enhed der stod bag. Mellem enheden og serveren kan der være adresseoversættelse i routeren, hos internetudbyderen og i en VPN- eller proxytjeneste, og geolokationen, der står ved siden af adressen i mange logs, er et estimat fra en kommerciel database. Det er derfor næsten altid forkert at læse “login fra Tyskland” eller “samme IP som medarbejderens hjem” som en konklusion. Det er et spor, der skal underbygges.

Den grundlæggende pointe om, at en IP-adresse peger på en forbindelse og ikke på en person, er gennemgået for advokater i Routerens log og IP-tildeling. Her går vi i dybden med teknikken.

Lagene mellem enhed og server

Lokalt netværk med NAT · Alle enheder bag routeren deler én offentlig adresse
CGNAT hos internetudbyderen · Mange kunder deler én offentlig adresse, adskilt af portnumre
Mobilnet · Adresser deles og skifter ofte, og udgangspunktet kan ligge langt fra brugeren
Firmanetværk og proxy · Alle ansatte kan fremstå med samme adresse
VPN · Serveren ser VPN-tjenestens udgangsadresse
Privatlivsrelæer i styresystemer og browsere · Serveren ser relæets adresse
Cloud og CDN · Serveren ser cloud- eller CDN-udbyderens adresse, hvis forbindelsen går derigennem

Hvert lag reducerer, hvad adressen kan sige. Et login fra en adresse, der tilhører en mobiloperatør, kan stamme fra en hvilken som helst kunde hos operatøren i et større område.

CGNAT og portnumre

Ved carrier-grade NAT deler internetudbyderen én offentlig IPv4-adresse mellem mange kunder og adskiller dem med portnumre. Internt bruger udbyderen typisk adresser fra det delte adresserum 100.64.0.0/10. For at en udbyder overhovedet kan pege på én kunde ud fra en CGNAT-adresse, kræves både adressen, det præcise tidspunkt og kildeporten. Mange servere logger ikke kildeporten. Uden den kan adressen ofte ikke føres videre til et abonnement. Om og hvor længe en udbyder gemmer porttildelingerne, afhænger af udbyderens systemer og af de regler, der gælder for udbyderen, og udlevering til brug i en civil sag er begrænset. Den juridiske side er beskrevet i Anonym modpart: hvem står bag profilen eller mailen?.

Når en log skal bruges til at identificere en forbindelse, er spørgsmålet derfor ikke kun “hvilken IP?”, men også “hvilken port, og hvor præcist er tidspunktet?”. Et ur, der går et minut forkert, kan på en travl CGNAT-adresse pege på en anden kunde.

IPv6

Med IPv6 får de fleste hjem og firmaer et helt præfiks, og enhederne danner selv deres adresse inden for det. Moderne styresystemer bruger midlertidige adresser, der skifter med jævne mellemrum, af hensyn til privatlivet. Præfikset kan derfor pege på en forbindelse, mens den fulde adresse kun kortvarigt peger på en enhed. To forskellige IPv6-adresser fra samme præfiks kan være samme enhed på forskellige tidspunkter eller to enheder i samme hjem.

VPN, relæer og proxy

En VPN-tjeneste skjuler brugerens egen adresse, og mange tjenester deler hver udgangsadresse mellem mange brugere. Kommercielle VPN-tjenester har ofte servere i mange lande, og brugeren kan vælge land frit. Det er en almindelig, harmløs forklaring på “login fra et ukendt land”. Privatlivsfunktioner i styresystemer og browsere sender også trafik via relæer med adresser, der kun groft svarer til brugerens region.

Firmaets egen VPN giver den modsatte effekt: Medarbejderen fremstår med firmaets adresse, uanset hvor medarbejderen sidder. Firmaets VPN-log er da den kilde, der kan koble forbindelsen til en konto og en offentlig adresse; se VPN-logs: sessioner, tildelte adresser og datamængder.

Geolokation

Geolokationsdatabaser bygger på registreringsdata fra de regionale internetregistre, oplysninger fra udbydere, målinger og egne heuristikker. De er nyttige til at se, om en adresse tilhører en dansk bredbåndsudbyder eller et datacenter i udlandet. De er upålidelige på by- og gadeniveau, de opdateres med forsinkelse, og forskellige databaser kan give forskellige svar for samme adresse.

Særligt fejlbehæftet er:

mobiladresser, der kan placeres i operatørens hovedby,
cloud- og datacenteradresser, der placeres ved udbyderens registrerede adresse,
adresser, der er flyttet mellem lande eller udbydere,
koordinater uden usikkerhed: Et punkt på kortet midt i et land er ofte bare landets midtpunkt.

Brug geolokation til at stille spørgsmål, ikke til at besvare dem. Angiv i rapporten, hvilken database og hvilken dato opslaget er lavet med, og supplér med registreringsdata og ASN.

ASN, registrering og omvendt opslag

Et opslag i internetregistrenes data viser, hvilken organisation adressen er tildelt, og hvilket autonomt system (ASN) der annoncerer den. Det er ofte mere nyttigt end geolokation: Det skelner mellem en privat bredbåndsforbindelse, en mobiloperatør, en hostingudbyder og en kendt VPN-tjeneste. Omvendt DNS-opslag kan give et værtsnavn, der antyder type eller område, men det er sat af udbyderen og ikke garanteret. Notér tidspunktet for opslaget, for tildelinger ændres.

Adresser fra platformens egen infrastruktur

I cloudlogs optræder ofte adresser, der tilhører platformen selv: Microsofts, Googles eller Amazons egne netværk. Det sker, når en tjeneste handler på brugerens vegne, fx synkronisering, mobilapps, der går gennem leverandørens servere, eller automatiseringer. En sådan adresse siger intet om, hvor brugeren var. Slå adressens ASN op, før den tolkes.

Inde i netværket: hvilken enhed?

Har adressen tilhørt virksomhedens eget netværk, kan interne logs ofte føre videre: firewallens NAT-tabel viser, hvilken intern adresse der lå bag, og DHCP- og Wi-Fi-logs viser, hvilken enhed der havde den interne adresse. Fremgangsmåden er beskrevet i DHCP, Wi-Fi og NAC. Kæden bliver aldrig stærkere end det svageste led, og den ender stadig ved en enhed, ikke en person.

Mønstre frem for enkeltadresser

Én adresse er svag. Et mønster over tid er stærkere. Bruger en konto i måneder de samme to eller tre adresser fra en dansk bredbåndsudbyder og en dansk mobiloperatør, og dukker der pludselig logins op fra en hostingudbyder i et andet land, er afvigelsen interessant, uanset hvad geolokationen siger. Omvendt er et enkelt login fra en VPN-adresse hos en medarbejder, der ofte rejser, ikke påfaldende. Byg derfor en oversigt over alle adresser for kontoen i en længere periode med ASN og type, før enkelte adresser fremhæves. Fremgangsmåden for loginlogs i Microsoft 365 er beskrevet i Entra ID-loginlogs.

Hvad en IP-adresse kan og ikke kan vise

En IP-adresse kan sammen med tidspunkt og port vise, at en forbindelse kom fra et bestemt netværkspunkt. Den kan understøtte en konklusion, når den passer med andre uafhængige spor: samme enhed, samme konto, samme mønster. Den kan sjældent alene vise, hvor en person var, eller hvem personen var. Kobling til et abonnement hos en udbyder kræver data, som kun udbyderen har, og som normalt kun udleveres ad retlig vej; den juridiske side er beskrevet i Krav for fildeling baseret på IP-adresser.

Når virksomheden ser et login fra et ukendt land, er det første skridt at sikre loggen; se Login fra et ukendt land. Hvordan adressen derefter vurderes, afhænger af lagene ovenfor.

Dokumentation

Angiv for hver adresse kilden og dens tidszone, tidspunktet med præcision, kildeport hvis den findes, ASN og registreret organisation med opslagsdato, geolokationsdatabase og version, og hvilke alternative forklaringer der er overvejet: VPN, relæ, mobilnet, CGNAT, firmanetværk og platformens egen infrastruktur.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Netværk og logs

Læs også: Logfiler og logrotation: sikring før data forsvinder · DHCP, Wi-Fi og NAC: hvilken enhed havde IP-adressen?

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For advokater · 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