Gateway eller videresendt klient? Slik leser du kildeadressen

Nettserveren logger én adresse, og alle antar at den tilhører gatewayens egen prosess. Den kan tilhøre en videresendt klient hvis private adresse forsvant i oversettelsestrinnet. Destinasjonen ser den synlige nettverkskilden og ingenting mer. Det er en grenseerklæring, ikke en påstand om at opprinnelsen aldri kan fastslås.

Hva destinasjonen faktisk ser

Ta en klient på 10.20.0.7, en gateway med den ytre adressen 198.51.100.10 og en destinasjon på internettet. Hvis gatewayen oversetter klientens kilde, registrerer destinasjonens socket 198.51.100.10. Den private adressen er borte fra pakken, og destinasjonen kan ikke lese den tilbake fra den headeren. Tallene er illustrative, ikke et opptak fra nettverket ditt.

Observasjonen er fortsatt nyttig: den identifiserer nettverkskilden som destinasjonen må tillate eller blokkere. Den identifiserer bare ikke personen eller prosessen bak. For destinasjonens operatør avgjør denne forskjellen om en blokkering er en nettverksbeslutning eller en kontobeslutning.

Oversettelsestilstanden er ikke synlig for destinasjonen

Gatewayen holder koblingen mellom den oversatte forbindelsen og den opprinnelige klienten, og nettopp denne tilstanden mangler destinasjonen. den tradisjonelle NAT-beskrivelsen skiller oversettelsesposten fra headerne som er synlige etterpå. Å lese den ene siden gir deg ikke den andre.

Ulike design gir ulike bevis. Rutet trafikk med bevarte kildeadresser viser klientens virkelige adresse, mens en applikasjonsproxy avslutter forbindelsen og oppretter en ny. En rute med bevart kilde krever også at klientens adresse kan rutes tilbake fra destinasjonen, noe ikke enhver utrulling tilbyr. Spør hvilket design som er rullet ut før du tolker en logglinje.

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

TTL og fingeravtrykk er spor, ikke bevis

TTL i IPv4 avhenger av startverdien avsenderen velger og antallet hopp pakken har passert. Uten begge fakta kan en verdi ikke bevise at et VPN-hopp har skjedd. Et kjent ekstra rutet hopp klarer heller ikke å skille en LAN-ruter, en tunnelrute eller en annen videresendingsordning. Behandle en TTL-forskjell som et spørsmål, ikke en konklusjon.

Andre signaler oppfører seg likt. En User-Agent-header kan settes av applikasjonen, og tidslikhet kan gjenspeile delt infrastruktur snarere enn en delt person. Flere brukere kan dele én utgang, og én bruker kan bytte rute mellom økter. Samlet kan flere svake signaler berettige et nærmere blikk på loggene til en gateway, men de blir ikke sterke bevis ved å hope seg opp.

Autoriser etter identitet, ikke etter adresse

Hvis destinasjonen må skille gatewayadministrasjon fra fjernbrukeraktivitet, gi disse rollene separate autentiserte identiteter og tillatte operasjoner. En delt offentlig kilde kan fortsatt tjene som en nettverksbegrensning, men den er ingen erstatning for å autentisere brukeren eller enheten.

Hold bevisene merket: den observerte kilden, den autentiserte kontoen, tidspunktet og slutningen som vurderes. Ikke oversett «ingen indre kilde synlig her» til «ingen tilskrivning mulig noe sted». Merket betyr noe når noen som ikke var en del av undersøkelsen leser posten måneder senere.

Registrer datoen for observasjonen og systemet som produserte den. Et ikke-tilskrevet loggutdrag er vanskelig å forsvare senere.