Google IP отправляет TCP (ACK, PSH) на мой роутер. Знаете почему?

Question

Я отслеживаю свой трафик и заметил несколькоTCP (ACK, PSH) попытки подключения по входной цепочке моего маршрутизатора, которые отклоняются моим брандмауэром.

Лог выглядит так:

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 

Очевидно, что это отбрасывается, потому что мое последнее правило в моей цепочке ввода — отбрасывать пакеты.

Я не очень хорошо понимаю протокол TCP, поэтому извините, если это немного наивно, но почему запрос направляется на мой маршрутизатор?

У меня есть несколько устройств, которые используют сервисы Google и, возможно, стороннее программное обеспечение, но для меня очень запутанно, почему пакет на самом деле отправляется.кмаршрутизатор и ненат'едк устройству в моей сети (которое будет прямой цепочкой, верно?).

Я пока не заметил ухудшения работы моих устройств в отношении продуктов Google. Обновления ПО, push-уведомления и т. д., похоже, работают правильно.

Answer 1

Феномен несколько сложнее. Я провел небольшое исследование в соответствующих журналах и хочу поделиться своей догадкой здесь для всех, кому тоже интересно.

Соответствующие записи журнала показывают сбросы во входной цепочке с флагами TCP ACKи PSH(push). Это указывает на то, что некоторая служба в сети ожидает сообщений от серверов Google (через. push). Но подождите - почему пакет регистрируется во входной цепочке? Это довольно легко объяснить - если маршрутизатор (или, как уже упомянул @chexum - conntrack) не имеет информации о подключении к NATed/ PATed трафику, пакет выглядит как трафик для маршрутизатора, а не для каких-либо устройств за ним. Так что это объясняет, почему "google отправляет трафик на маршрутизатор".

Но вопрос в том, почему маршрутизатор не имеет информации о подключении для этих пакетов. И здесь я могу только предполагать на данный момент: сбросы наблюдаются в то время, когда большинство пользователей находятся в Интернете. Я предполагаю, что ответы Google заняли слишком много времени (возможно, потому что он раньше push-трафик был ниже, чем у других), поэтому соединение истекло. Тайм-ауты на этом конкретном маршрутизаторе составляют около 10 секунд для пакетов TCP и 5 секунд для SYN. Еще через некоторое время conntrack удалит свою память о старом «недействительном» трафике, и с этого времени каждый трафик из этого соединения будет выглядеть как входящий трафик. Это также одно из возможных объяснений того, почему недействительные правила не срабатывают.

Я думаю, что @samuel должен понаблюдать за этим немного больше и посмотреть, можно ли распознать какую-либо закономерность. Но в целом я разделяю мнение @chexum, что эти капли можно игнорировать.

Answer 2

На нем четко виден пакет, полученный с IP-адреса Google, с исходным портом 443.

Конечно, существует вероятность того, что кто-то проводит атаку «человек посередине» с IP-адресом Google, или даже что кто-то из Google (или взломал его) отправляет вам пакеты, да, но это очень,оченьвряд ли.

Более вероятно, что ваш пакетный фильтр и/или подсистема conntrack (или аналогичная функция на вашем маршрутизаторе и/или на вашем интернет-провайдере) уже увидели пакеты из потока пакетов между google:443 и yourip:40382, показывая, что соединение уже закрыто.

Обычно инициированные вами соединения не регистрируются пакетными фильтрами, но это справедливо только для установленных соединений.

Когда соединения закрываются с помощью FINс обеих сторон или RSTс любой из сторон, соединение больше не рассматривается ESTABLISHED. Любые пакеты, задержанные или повторно отправленные любой из сторон, будут затем считаться новыми и заслуживающими регистрации вашим пакетным фильтром, особенно если удаленная запись conntrack препятствует денатурации пакета по его надлежащему назначению.

Это очень распространенное явление, вероятно, нет никаких причин для беспокойства, обычно вы можете спокойно игнорировать эти зарегистрированные пакеты.

Если вы заметили какую-либо закономерность и хотите ее исследовать, вы можете запустить tcpdumpв своей системе журнал всех пакетов с похожих IP-адресов. Затем, когда вы увидите еще один похожий журнал, вы можете остановить tcpdump и отфильтровать его по локальному порту, чтобы увидеть, действительно ли соединение было открыто всего за несколько секунд до события.

Пример tcpdump для вышеприведенного примера будет выглядеть примерно так:

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