La IP de Google envía un TCP (ACK, PSH) a mi enrutador. ¿Se sabe por qué?

Question

Estoy monitoreando mi tráfico y noté variosTCP (ACK, PSH) intentos de conexión en la cadena de entrada de mi enrutador, que mi firewall elimina.

El registro se ve así:

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 

Obviamente esto se descarta porque mi última regla en mi cadena de entrada es descartar paquetes.

No entiendo lo suficientemente bien el protocolo TCP, lo siento si esto es un poco ingenuo, pero ¿por qué la solicitud se dirige a mi enrutador?

Tengo varios dispositivos que utilizan los servicios de Google y probablemente también software de terceros, pero me resulta muy confuso saber por qué se envía realmente el paquete.ael enrutador y noNacidoa un dispositivo en mi red (que sería la cadena de reenvío, ¿verdad?).

Todavía no he notado una experiencia degradada con mis dispositivos con respecto a los productos de Google. Las actualizaciones de software, las notificaciones automáticas, etc. parecen funcionar correctamente.

Answer 1

El fenómeno es algo más complejo. Investigué un poco en los registros correspondientes y quiero compartir mi suposición aquí para todos los que también se lo pregunten.

Las entradas de registro relacionadas que muestran caídas en la cadena de entrada con indicadores TCP ACKy PSH(push). Esto indica que algún servicio en la red está esperando mensajes de los servidores de Google (vía .push). Pero espera, ¿por qué el paquete se registra en la cadena de entrada? Eso es bastante fácil de explicar: si el enrutador (o como ya mencionó @chexum, el conntrack) no tiene información de conexión sobre NATed/ PATtráfico ed, el paquete parece tráfico para el enrutador y no para ningún dispositivo detrás de él. Eso explica por qué "Google está enviando tráfico al enrutador".

Pero la pregunta es por qué el enrutador no tiene información de conexión para estos paquetes. Y aquí sólo puedo especular por ahora: las caídas se observan en los momentos en que la mayoría de los usuarios están en Internet. Supongo que las respuestas de Google tardaron demasiado (tal vez porque antes empujaban el tráfico a un nivel más bajo que otros), por lo que la conexión se agotó. Los tiempos de espera en este enrutador en particular son de aproximadamente 10 segundos para paquetes TCP y 5 segundos para SYN. Después de un tiempo más, el conntrack eliminará su memoria sobre el tráfico antiguo "no válido" y, a partir de ese momento, cada tráfico de esta conexión parece tráfico de entrada. Ésa también es una posible explicación de por qué no se activan las reglas no válidas.

Creo que @samuel debería observarlo un poco más y ver si se reconoce algún patrón. Pero en general comparto la opinión de @chexum de que estas gotas son ignorables.

Answer 2

Muestra claramente un paquete recibido de una IP de Google, con un puerto de origen 443.

Por supuesto, existe la posibilidad de que alguien realice un ataque de intermediario con la dirección IP de Google, o incluso que alguien de (o acceda) a Google le esté enviando paquetes, sí, pero esto es muy,muyimprobable.

Lo más probable es que su filtro de paquetes y/o el subsistema conntrack (o una funcionalidad similar en su enrutador y/o en su ISP) ya hayan visto paquetes del flujo de paquetes entre google:443 y yourip:40382 que muestran la conexión a estar cerrado ya.

Por lo general, las conexiones iniciadas por usted no se registran en los filtros de paquetes, pero eso solo se aplica a las conexiones establecidas.

Cuando las conexiones se cierran con un FINdesde ambos lados o RSTdesde cualquier lado, la conexión ya no se considera ESTABLISHED. Cualquier paquete retrasado o reenviado por cualquiera de las partes será considerado nuevo y digno de registro por su filtro de paquetes, especialmente si la entrada conntrack eliminada impide la desnatación del paquete a su destino adecuado.

Esto es muy común, probablemente no haya ningún motivo para preocuparse; generalmente puede ignorar con seguridad esos paquetes registrados.

Si ve algún patrón y desea investigar, puede seguir ejecutando tcpdumpen su sistema el registro de todos los paquetes de direcciones IP similares, luego, cuando vea un registro similar más, puede detener el tcpdump y filtrar por el puerto local para ver. si efectivamente tenías una conexión abierta unos segundos antes del evento.

Un ejemplo de tcpdump para lo anterior sería algo como:

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