Gateway eller videresendt klient? Sådan læses kildeadressen

Webserveren logger én adresse, og alle antager, at den tilhører gatewayens egen proces. Den kan tilhøre en videresendt klient, hvis private adresse forsvandt i oversættelsestrinnet. Destinationen ser den synlige netværkskilde og intet mere. Det er en grænseerklæring, ikke en påstand om, at oprindelsen aldrig kan fastslås.

Hvad destinationen faktisk ser

Tag en klient på 10.20.0.7, en gateway med den udvendige adresse 198.51.100.10 og en destination på internettet. Hvis gatewayen oversætter klientens kilde, registrerer destinationens socket 198.51.100.10. Den private adresse er væk fra pakken, og destinationen kan ikke læse den tilbage fra den header. Tallene er illustrative, ikke en optagelse fra dit netværk.

Observationen er stadig nyttig: den identificerer den netværkskilde, som destinationen skal tillade eller blokere. Den identificerer bare ikke personen eller processen bag den. For destinationens operatør afgør denne forskel, om en blokering er en netværksbeslutning eller en kontobeslutning.

Oversættelsestilstand er ikke synlig for destinationen

Gatewayen holder koblingen mellem den oversatte forbindelse og den oprindelige klient, og netop denne tilstand mangler destinationen. den traditionelle NAT-beskrivelse adskiller oversættelsesregistret fra de headere, der er synlige bagefter. At læse den ene side giver dig ikke den anden.

Forskellige design giver forskellige beviser. Routet trafik med bevarede kildeadresser viser klientens rigtige adresse, mens en applikationsproxy afslutter forbindelsen og opretter en ny. En rute med bevaret kilde kræver også, at klientens adresse kan routes tilbage fra destinationen, hvilket ikke enhver udrulning tilbyder. Spørg, hvilket design der er udrullet, før du fortolker en loglinje.

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL og fingeraftryk er spor, ikke bevis

TTL i IPv4 afhænger af den startværdi, afsenderen vælger, og af antallet af hop, pakken har passeret. Uden begge fakta kan en værdi ikke bevise, at et VPN-hop er sket. Et kendt ekstra routet hop formår heller ikke at skelne en LAN-router, en tunnelrute eller en anden videresendelsesordning. Behandl en TTL-forskel som et spørgsmål, ikke en konklusion.

Andre signaler opfører sig på samme måde. En User-Agent-header kan sættes af applikationen, og tidsmæssig lighed kan afspejle delt infrastruktur snarere end en delt person. Flere brugere kan dele én udgang, og én bruger kan skifte ruter mellem sessioner. Samlet kan flere svage signaler berettige et nærmere kig på en gateways registreringer, men de bliver ikke stærke beviser ved at hobe sig op.

Autoriser efter identitet, ikke efter adresse

Hvis destinationen skal skelne gatewayadministration fra fjernbrugeraktivitet, skal du give disse roller separate autentificerede identiteter og tilladte handlinger. En delt offentlig kilde kan stadig tjene som en netværksbegrænsning, men den er ingen erstatning for at autentificere brugeren eller enheden.

Hold beviserne mærkede: den observerede kilde, den autentificerede konto, tidspunktet og den slutning, der overvejes. Oversæt ikke «ingen indre kilde synlig her» til «ingen tilskrivning mulig nogetsteds». Mærkaten betyder noget, når nogen, der ikke var en del af undersøgelsen, læser registret måneder senere.

Registrér datoen for observationen og det system, der producerede den. Et ikke-tilskrevet loguddrag er svært at forsvare senere.