Gateway eller vidarebefordrad klient? Att läsa källadressen

Webbservern loggar en adress, och alla antar att den tillhör gatewayens egen process. Den kan tillhöra en vidarebefordrad klient vars privata adress försvann i översättningssteget. Destinationen ser den synliga nätverkskällan och inget mer. Det är ett gränspåstående, inte ett påstående att ursprunget aldrig kan fastställas.

Vad destinationen faktiskt ser

Ta en klient på 10.20.0.7, en gateway med den yttre adressen 198.51.100.10 och en destination på internet. Om gatewayen översätter klientens källa registrerar destinationens socket 198.51.100.10. Den privata adressen är borta från paketet, och destinationen kan inte läsa tillbaka den från den headern. Siffrorna är illustrativa, inte en inspelning från ditt nätverk.

Observationen är fortfarande användbar: den identifierar den nätverkskälla som destinationen måste tillåta eller blockera. Den identifierar bara inte personen eller processen bakom. För destinationens operatör avgör den skillnaden om en blockering är ett nätverksbeslut eller ett kontobeslut.

Översättningstillståndet är inte synligt för destinationen

Gatewayen håller mappningen mellan den översatta anslutningen och den ursprungliga klienten, och just det tillståndet saknar destinationen. den traditionella NAT-beskrivningen skiljer översättningsposten från de headers som syns efteråt. Att läsa ena sidan ger dig inte den andra.

Olika konstruktioner ger olika bevis. Routad trafik med bevarade källadresser visar klientens riktiga adress, medan en applikationsproxy avslutar anslutningen och skapar en ny. En rutt med bevarad källa kräver också att klientens adress kan routas tillbaka från destinationen, vilket inte varje utrullning erbjuder. Fråga vilken konstruktion som är utrullad innan du tolkar en logglinje.

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

TTL och fingeravtryck är spår, inte bevis

TTL i IPv4 beror på det startvärde avsändaren väljer och på antalet hopp paketet har passerat. Utan båda fakta kan ett värde inte bevisa att ett VPN-hopp har skett. Ett känt extra routat hopp lyckas inte heller skilja en LAN-router, en tunnelväg eller ett annat vidarebefordringsupplägg. Behandla en TTL-skillnad som en fråga, inte en slutsats.

Andra signaler beter sig likadant. En User-Agent-header kan sättas av applikationen, och tidslikhet kan spegla delad infrastruktur snarare än en delad person. Flera användare kan dela en utgång, och en användare kan byta väg mellan sessioner. Samlade kan flera svaga signaler motivera en närmare titt på en gateways loggar, men de blir inte starka bevis genom att hopas.

Auktorisera efter identitet, inte efter adress

Om destinationen måste skilja gatewayadministration från fjärranvändares aktivitet, ge dessa roller separata autentiserade identiteter och tillåtna operationer. En delad offentlig källa kan fortfarande tjäna som en nätverksbegränsning, men den ersätter inte autentisering av användaren eller enheten.

Håll bevisen märkta: den observerade källan, det autentiserade kontot, tidpunkten och slutsatsen som övervägs. Översätt inte «ingen inre källa synlig här» till «ingen tillskrivning möjlig någonstans». Märkningen spelar roll när någon som inte var del av utredningen läser posten månader senare.

Registrera datumet för observationen och systemet som producerade den. Ett icke-tillskrivet loggutdrag är svårt att försvara senare.