O IP do Google envia um TCP (ACK, PSH) para meu roteador. Sabe por quê?

Question

Estou monitorando meu tráfego e notei váriosTCP (ACK,PSH) tentativas de conexão na cadeia de entrada do meu roteador, que são descartadas pelo meu firewall.

O registro fica assim:

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, isso foi descartado porque minha última regra na minha cadeia de entrada é descartar pacotes.

Não entendo bem o protocolo TCP, desculpe se isso é um pouco ingênuo, mas por que a solicitação é direcionada ao meu roteador?

Tenho vários dispositivos que usam serviços do Google e provavelmente também software de terceiros, mas é muito confuso para mim por que o pacote é realmente enviadoparao roteador e nãonadapara um dispositivo na minha rede (que seria a cadeia direta, certo?).

Ainda não notei uma experiência degradada com meus dispositivos em relação aos produtos do Google. Atualizações de software, notificações push, etc., parecem funcionar corretamente.

Answer 1

O fenômeno é um pouco mais complexo. Fiz algumas pesquisas nos registros correspondentes e quero compartilhar meu palpite aqui para todos que também estão se perguntando.

As entradas de log relacionadas mostrando quedas na cadeia de entrada com sinalizadores TCP ACKe PSH(push). Isso indica que algum serviço da rede está aguardando mensagens dos servidores do Google (via. push). Mas espere – por que o pacote está logado na cadeia de entrada? Isso é bastante fácil de explicar - se o roteador (ou como @chexum já mencionou - o conntrack) não tiver informações de conexão sobre o tráfego NATed/ PATed, o pacote parecerá tráfego para o roteador e não para qualquer dispositivo por trás dele. Isso explica por que "o Google está enviando tráfego para o roteador".

Mas a questão é por que o roteador não possui informações de conexão para esses pacotes. E aqui só posso especular por enquanto: As quedas são observadas em horários onde a maioria dos usuários está na internet. Meu palpite é que as respostas do Google demoraram muito (talvez porque antes empurravam o tráfego para menos do que outras) para que a conexão expirasse. Os tempos limite neste roteador específico são cerca de 10s para pacotes TCP e 5s para pacotes SYN. Depois de mais algum tempo, o conntrack removerá sua memória sobre o tráfego "inválido" antigo e, a partir desse momento, todo tráfego desta conexão parecerá tráfego de entrada. Essa também é uma explicação possível porque as regras inválidas não são acionadas.

Acho que @samuel deveria observar um pouco mais e ver se algum padrão é reconhecível. Mas geralmente tenho a opinião de @chexum de que essas gotas são ignoráveis.

Answer 2

Mostra claramente um pacote recebido de um IP do Google, com porta de origem 443.

É claro que existe a possibilidade de alguém fazer um ataque man-in-the-middle com o endereço IP do Google, ou mesmo que alguém do (ou invadido) Google esteja enviando pacotes para você, sim, mas isso é muito,muitoimprovável.

O mais provável é que o seu filtro de pacotes e/ou o subsistema conntrack (ou uma funcionalidade semelhante no seu roteador e/ou no seu ISP) já tenha visto pacotes do fluxo de pacotes entre google:443 e yourip:40382 mostrando a conexão para já esteja fechado.

Normalmente, as conexões iniciadas por você não são registradas pelos filtros de pacotes, mas isso só vale para conexões estabelecidas.

Quando as conexões são fechadas FINde ambos os lados ou RSTde qualquer um dos lados, a conexão não é mais considerada ESTABLISHED. Quaisquer pacotes atrasados ​​ou reenviados por qualquer um dos lados serão considerados novos e dignos de registro pelo seu filtro de pacotes, especialmente se a entrada conntrack removida impedir a desnatação do pacote para seu destino adequado.

Isso é muito comum, provavelmente não há razão para se preocupar, geralmente você pode ignorar com segurança esses pacotes registrados.

Se você vir algum padrão e quiser investigar, você pode continuar em tcpdumpexecução no seu sistema registrando todos os pacotes de endereços IP semelhantes e, quando vir mais um log semelhante, poderá interromper o tcpdump e filtrar a porta local para ver se você realmente teve uma conexão aberta apenas alguns segundos antes do evento.

Um exemplo de tcpdump para o acima seria algo como:

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