Gateway oder weitergeleiteter Client? Die Quelladresse lesen

Der Webserver protokolliert eine Adresse, und alle nehmen an, sie gehöre zum Prozess des Gateways selbst. Sie kann zu einem weitergeleiteten Client gehören, dessen private Adresse beim Übersetzungsschritt verschwunden ist. Das Ziel sieht die sichtbare Netzwerkquelle und nichts weiter. Das ist eine Grenzaussage, keine Behauptung, der Ursprung lasse sich nie feststellen.

Was das Ziel tatsächlich sieht

Nehmen Sie einen Client unter 10.20.0.7, ein Gateway mit der Außenadresse 198.51.100.10 und ein Ziel im Internet. Übersetzt das Gateway die Quelle des Clients, zeichnet der Socket des Ziels 198.51.100.10 auf. Die private Adresse ist aus dem Paket verschwunden, und das Ziel kann sie nicht aus diesem Header zurücklesen. Diese Zahlen sind beispielhaft, keine Aufzeichnung aus Ihrem Netz.

Die Beobachtung bleibt nützlich: Sie identifiziert die Netzwerkquelle, die das Ziel zulassen oder blockieren muss. Sie identifiziert nur nicht die Person oder den Prozess dahinter. Für den Betreiber des Ziels entscheidet diese Unterscheidung, ob eine Sperre eine Netzwerkentscheidung oder eine Kontoentscheidung ist.

Der Übersetzungszustand ist für das Ziel nicht sichtbar

Das Gateway führt die Zuordnung zwischen der übersetzten Verbindung und dem ursprünglichen Client, und genau dieser Zustand fehlt dem Ziel. traditionelle NAT-Beschreibung trennt den Übersetzungseintrag von den danach sichtbaren Headern. Eine Seite zu lesen liefert nicht die andere.

Verschiedene Designs liefern verschiedene Belege. Gerouteter Verkehr mit erhaltenen Quelladressen zeigt die echte Adresse des Clients, während ein Anwendungsproxy die Verbindung beendet und eine neue aufbaut. Eine Route mit erhaltener Quelle erfordert außerdem, dass die Adresse des Clients vom Ziel aus zurückgeroutet werden kann, was nicht jede Bereitstellung bietet. Fragen Sie, welches Design bereitgestellt ist, bevor Sie eine Logzeile interpretieren.

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

TTL und Fingerabdrücke sind Hinweise, keine Beweise

Die TTL in IPv4 hängt vom Anfangswert ab, den der Absender wählt, und von der Anzahl der Hops, die das Paket durchlaufen hat. Ohne beide Tatsachen kann ein Wert nicht belegen, dass ein VPN-Hop stattgefunden hat. Ein bekannter zusätzlicher gerouteter Hop unterscheidet ebenfalls nicht zwischen einem LAN-Router, einem Tunnelpfad oder einer anderen Weiterleitungsanordnung. Behandeln Sie eine TTL-Differenz als Frage, nicht als Schlussfolgerung.

Andere Signale verhalten sich genauso. Ein User-Agent-Header kann von der Anwendung gesetzt werden, und zeitliche Ähnlichkeit kann geteilte Infrastruktur statt eine geteilte Person widerspiegeln. Mehrere Nutzer können einen Ausgang teilen, und ein Nutzer kann zwischen Sitzungen den Pfad wechseln. Zusammengenommen mögen mehrere schwache Signale einen genaueren Blick in die Aufzeichnungen eines Gateways rechtfertigen, aber durch Anhäufung werden sie nicht zu starken Belegen.

Autorisieren nach Identität, nicht nach Adresse

Muss das Ziel die Gateway-Administration von der Aktivität entfernter Nutzer trennen, geben Sie diesen Rollen getrennte authentifizierte Identitäten und erlaubte Operationen. Eine gemeinsame öffentliche Quelle kann weiterhin als Netzwerkbeschränkung dienen, ersetzt aber nicht die Authentifizierung des Nutzers oder des Geräts.

Halten Sie die Belege gekennzeichnet: beobachtete Quelle, authentifiziertes Konto, Zeitpunkt und die betrachtete Schlussfolgerung. Übersetzen Sie „hier ist keine innere Quelle sichtbar“ nicht als „nirgends ist eine Zuordnung möglich“. Die Kennzeichnung zählt, wenn jemand, der nicht an der Untersuchung beteiligt war, den Eintrag Monate später liest.

Halten Sie das Datum der Beobachtung und das System fest, das sie erzeugt hat. Ein nicht zugeordneter Logauszug ist später schwer zu verteidigen.