Google IP sendet ein TCP (ACK, PSH) an meinen Router. Wissen Sie warum?

Question

Ich beobachte meinen Verkehr und habe mehrereTCP (ACK, PSH) Verbindungsversuche in der Eingangskette meines Routers, die von meiner Firewall gelöscht werden.

Das Protokoll sieht folgendermaßen aus:

Dropping input: src-mac 9c:80:df:a0:8a:dd, proto TCP (ACK,PSH), 172.217.16.78:443 (google ip) ->192.168.1.2:40382 (my router IP), len 115 

Dies wird offensichtlich verworfen, da meine letzte Regel in meiner Eingabekette das Verwerfen von Paketen ist.

Ich verstehe das TCP-Protokoll nicht gut genug, also entschuldigen Sie, wenn das ein bisschen naiv klingt, aber warum wird die Anfrage an meinen Router weitergeleitet?

Ich habe verschiedene Geräte, die Google-Dienste und wahrscheinlich auch Software von Drittanbietern verwenden, aber es ist mir sehr verwirrend, warum das Paket tatsächlich gesendet wirdZuder Router und nichtnatzu einem Gerät in meinem Netzwerk (das wäre die Vorwärtskette, oder?).

Ich habe bisher keine Verschlechterung der Leistung meiner Geräte in Bezug auf Google-Produkte festgestellt. Software-Updates, Push-Benachrichtigungen usw. scheinen alle ordnungsgemäß zu funktionieren.

Answer 1

Das Phänomen ist etwas komplexer. Ich habe die entsprechenden Logs genauer unter die Lupe genommen und möchte hier meine Vermutung für alle, die sich das auch fragen, teilen.

Die zugehörigen Protokolleinträge zeigen Drops in der Eingabekette mit TCP-Flags ACKund PSH(Push). Dies zeigt an, dass ein Dienst im Netzwerk auf Nachrichten von den Google-Servern wartet (via Push). Aber Moment mal – warum wird das Paket in der Eingabekette protokolliert? Das ist ziemlich einfach zu erklären – wenn der Router (oder wie @chexum bereits erwähnt hat – der Conntrack) keine Verbindungsinformationen über NATed/ PATed-Verkehr hat, sieht das Paket aus wie Verkehr für den Router und nicht für irgendwelche Geräte dahinter. Das erklärt also, warum „Google Verkehr an den Router sendet“.

Die Frage ist jedoch, warum der Router keine Verbindungsinformationen für diese Pakete hat. Und hier kann ich im Moment nur spekulieren: Die Ausfälle werden zu Zeiten beobachtet, in denen die meisten Benutzer im Internet sind. Ich vermute, dass die Antworten von Google zu lange gedauert haben (vielleicht weil es den Verkehr vorher niedriger als andere gepusht hat), sodass die Verbindung abläuft. Die Timeouts auf diesem speziellen Router betragen etwa 10 Sekunden für TCP-Pakete und 5 Sekunden für SYN. Nach einiger Zeit löscht der Conntrack seinen Speicher für alten „ungültigen“ Verkehr und ab diesem Zeitpunkt sieht jeder Verkehr von dieser Verbindung wie Eingangsverkehr aus. Das ist auch eine mögliche Erklärung, warum die ungültigen Regeln nicht ausgelöst werden.

Ich denke, @samuel sollte das noch ein bisschen genauer beobachten und schauen, ob ein Muster erkennbar ist. Aber generell bin ich der Meinung von @chexum, dass diese Rückgänge ignoriert werden können.

Answer 2

Es zeigt deutlich ein von einer Google-IP empfangenes Paket mit einem Quellport von 443.

Es besteht natürlich die Möglichkeit, dass jemand einen Man-in-the-Middle-Angriff mit der IP-Adresse von Google durchführt oder sogar, dass jemand von Google (oder ein Eindringling bei Google) Ihnen Pakete sendet, ja, aber das ist sehr,sehrunwahrscheinlich.

Wahrscheinlicher ist, dass Ihr Paketfilter und/oder das Conntrack-Subsystem (oder eine ähnliche Funktion auf Ihrem Router und/oder Ihrem ISP) bereits Pakete aus dem Paketfluss zwischen Google:443 und YourIP:40382 gesehen hat, die darauf hinweisen, dass die Verbindung bereits geschlossen ist.

Normalerweise werden von Ihnen initiierte Verbindungen nicht von den Paketfiltern protokolliert. Dies gilt jedoch nur für etablierte Verbindungen.

FINWenn die Verbindungen mit einem von beiden Seiten oder von einer Seite geschlossen werden RST, wird die Verbindung nicht mehr als betrachtet ESTABLISHED. Alle von einer Seite verzögerten oder erneut gesendeten Pakete werden dann von Ihrem Paketfilter als neu betrachtet und protokollwürdig, insbesondere wenn der entfernte Conntrack-Eintrag die De-Nation des Pakets an sein richtiges Ziel verhindert.

Dies kommt sehr häufig vor und es besteht wahrscheinlich überhaupt kein Grund zur Sorge. Normalerweise können Sie diese protokollierten Pakete getrost ignorieren.

Wenn Sie ein Muster erkennen und diesem nachgehen möchten, können Sie tcpdumpauf Ihrem System ein Protokoll aller Pakete von ähnlichen IP-Adressen laufen lassen. Wenn Sie dann ein weiteres ähnliches Protokoll sehen, können Sie den TCPdump stoppen und nach dem lokalen Port filtern, um zu sehen, ob Sie tatsächlich wenige Sekunden vor dem Ereignis eine offene Verbindung hatten.

Ein Beispiel für einen TCPdump für das Obige würde etwa so aussehen:

tcpdump -ieth0 -s0 -w /var/tmp/allssl.cap port 443