Gateway eller videresend klient? Slik les du kjeldadressa

Nettserveren loggar éi adresse, og alle føreset at ho høyrer til prosessen til gatewayen sjølv. Ho kan høyra til ein videresend klient som mista den private adressa si i omsetjingssteget. Destinasjonen ser den synlege nettverkskjelda og ingenting meir. Det er ei grensefråsegn, ikkje ei påstand om at opphavet aldri kan fastslåast.

Kva destinasjonen faktisk ser

Ta ein klient på 10.20.0.7, ein gateway med den ytre adressa 198.51.100.10 og ein destinasjon på internettet. Viss gatewayen omset kjelda til klienten, registrerer sockelen til destinasjonen 198.51.100.10. Den private adressa er borte frå pakken, og destinasjonen kan ikkje lesa ho tilbake frå den headeren. Tala er illustrative, ikkje eit opptak frå nettverket ditt.

Observasjonen er framleis nyttig: han identifiserer nettverkskjelda som destinasjonen må tillata eller blokkera. Han identifiserer berre ikkje personen eller prosessen bak. For operatøren av destinasjonen avgjer denne skilnaden om ei blokkering er eit nettverksvedtak eller eit kontovedtak.

Omsetjingstilstanden er ikkje synleg for destinasjonen

Gatewayen held på koplinga mellom den omsette sambandet og den opphavlege klienten, og nettopp denne tilstanden manglar destinasjonen. den tradisjonelle NAT-skildringa skil omsetjingsoppføringa frå headerane som er synlege etterpå. Å lesa den eine sida gir deg ikkje den andre.

Ulike design gir ulike prov. Ruta trafikk med bevarde kjeldadresser viser den verkelege adressa til klienten, medan ein applikasjonsproxy avsluttar sambandet og opprettar eit nytt. Ei rute med bevart kjelde krev òg at adressa til klienten kan rutast tilbake frå destinasjonen, noko ikkje kvar utrulling tilbyr. Spør kva design som er rulla ut før du tolkar ei logglinje.

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

TTL og fingeravtrykk er spor, ikkje prov

TTL i IPv4 avheng av startverdien avsendarøren vel og av talet på hopp pakken har passert. Utan begge fakta kan ein verdi ikkje prova at eit VPN-hopp har skjedd. Eit kjent ekstra ruta hopp klarer heller ikkje å skilja ein LAN-rutar, ein tunnelrute eller ei anna videresending. Handsam ein TTL-skilnad som eit spørsmål, ikkje ein konklusjon.

Andre signal oppfører seg likt. Ein User-Agent-header kan setjast av applikasjonen, og tidslikskap kan spegla delt infrastruktur snarare enn ein delt person. Fleire brukarar kan dela éin utgang, og éin brukar kan byta rute mellom økter. Samla kan fleire svake signal rettferdiggjera eit nærare blikk på loggane til ein gateway, men dei vert ikkje sterke prov av å hopa seg opp.

Autoriser etter identitet, ikkje etter adresse

Viss destinasjonen må skilja gatewayadministrasjon frå aktiviteten til fjernbrukarar, gje desse rollene separate autentiserte identitetar og tillatne operasjonar. Ei delt offentleg kjelde kan framleis tena som ei nettverksavgrensing, men ho er inga erstatning for å autentisera brukaren eller eininga.

Hald prova merkte: den observerte kjelda, den autentiserte kontoen, tidspunktet og slutninga som vert vurdert. Ikkje set om «inga indre kjelde synleg her» til «inga tilskriving mogleg nokon stad». Merket betyr noko når nokon som ikkje var del av granskinga les posten månader seinare.

Registrer datoen for observasjonen og systemet som produserte han. Eit ikkje-tilskrive loggutdrag er vanskeleg å forsvara seinare.