Это происходит только во время просмотра. У меня один из тех маршрутизаторов, который даже не блокирует входящий трафик, поэтому всю работу должен выполнять брандмауэр моего компьютера. В журнале ниже я использовал Firefox, но это происходит с любым браузером. В моем Firefox HTTP2, веб-воркеры, сервис-воркеры, WebRTC и многое другое отключены/заблокированы, поэтому для меня действительно загадка, как серверам удается запрашивать незапрошенные соединения с моим компьютером. Это происходит на нескольких сайтах при их просмотре, но не на всех.
Date Time Direction Process path Protocol Source IP Src Port Dest. IP Dest.Port Action Window title
17/04 16:23:59 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50755 | 204.79.197.200 | 443 | Allowed | Startpage.com - The world's most private search engine - Mozilla Firefox
17/04 16:23:59 | In | - | TCP | 204.79.197.200 | 443 | 10.0.0.3 | 50730 | Blocked |
17/04 16:23:59 | In | - | TCP | 204.79.197.200 | 443 | 10.0.0.3 | 50735 | Blocked |
17/04 16:23:59 | In | - | TCP | 204.79.197.200 | 443 | 10.0.0.3 | 50735 | Blocked |
17/04 16:25:25 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50766 | 37.252.238.25 | 443 | Allowed | unsolicited incoming connections at DuckDuckGo - Mozilla Firefox
17/04 16:25:25 | In | - | TCP | 37.252.238.25 | 443 | 10.0.0.3 | 50766 | Blocked |
17/04 16:29:50 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50785 | 201.48.71.43 | 443 | Allowed | Bing - Mozilla Firefox
17/04 16:29:51 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50786 | 201.48.71.43 | 443 | Allowed | Bing - Mozilla Firefox
17/04 16:29:51 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50787 | 201.48.71.43 | 443 | Allowed | Bing - Mozilla Firefox
17/04 16:29:51 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50788 | 201.48.71.43 | 443 | Allowed | Bing - Mozilla Firefox
17/04 16:29:54 | In | - | TCP | 201.48.71.43 | 443 | 10.0.0.3 | 50788 | Blocked |
17/04 17:03:12 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50986 | 151.101.1.69 | 443 | Allowed | Super User - Mozilla Firefox
17/04 17:03:12 | Out | C:\program files\mozilla firefox\firefox.exe | TCP | 10.0.0.3 | 50987 | 151.101.1.69 | 443 | Allowed | Super User - Mozilla Firefox
17/04 17:03:18 | In | - | TCP | 151.101.1.69 | 443 | 10.0.0.3 | 50986 | Blocked |
17/04 17:03:18 | In | - | TCP | 151.101.1.69 | 443 | 10.0.0.3 | 50987 | Blocked |
Есть много других примеров, но все они следуют одной и той же схеме: я захожу на сайт, который создает соединение с определенным IP-адресом, затем происходит одна или несколько незапрошенных попыток входящего соединения с того же IP-адреса.
Кто-нибудь знает, что, почему и как это происходит?
решение1
Нет, я думаю, что брандмауэр вашего компьютера вас обманывает.
Судя по выбору локальных и удаленных портов, он, вероятно, видит совершенно нормальные ответные пакеты, которые принадлежат существующему исходящему соединению, но по какой-то причине не может связать их с этим соединением.
Чтобы знать, является ли соединение входящим или исходящим, брандмауэр должен быть с отслеживанием состояния — он обращает внимание на каждый пакет TCP и запоминает соответствующие пары адресов и портов. Например, он знает, что все пакеты с локальным адресом (10.0.0.3, 50766) и удаленным адресом (37.252.238.25, 443) принадлежат исходящему соединению, созданному вашим браузером.
Когда приходит ответный пакет, брандмауэр просматривает свою таблицу подключений и видит, что пара адресов (37.252.238.25, 443) - (10.0.0.3, 50766) уже известна - пакет не является новым подключением, это просто ответ на существующее (исходящее) подключение и его необходимо разрешить.
Но если информация о состоянии по какой-то причине рассинхронизируется — например, сами хосты думают, что соединение все еще открыто, но брандмауэр уже забыл об этом — тогда он не сможет легко определить тип входящего пакета. В этом случае брандмауэр больше незнаетчто входящий пакет принадлежит соединению, которое изначально было исходящим, поэтому в итоге он связывает его с отдельной «входящей» записью.
Например, возможной причиной является то, что ваш компьютер только чтоотправилFIN-пакет «закрытие соединения», но удаленный сервереще не полученоон (потому что передача данных не мгновенная) и продолжает с радостью отправлять вам пакеты. Если ваш брандмауэр сразу же забывает соединение, увидев исходящий FIN, то, конечно, он не сможет распознать эти входящие пакеты как все еще принадлежащие тому же соединению. (Полузакрытые соединения допустимы в TCP, но я бы не стал утверждать, что брандмауэр не осознает этого.)
Иногда это также происходит, когда у брандмауэра очень маленький лимит состояний, например, я видел домашние маршрутизаторы, которые не могут отслеживать более 50 или 100 состояний одновременно (включая не только TCP-соединения, но и потоки UDP — например, каждый DNS-запрос через UDP создает новое состояние, чтобы ответ мог быть пропущен). Аналогично, у некоторых брандмауэров очень короткое время истечения состояния — они могут забыть TCP-соединения, как только они простаивают минуту или две, хотя вполне нормально, что соединение простаивает гораздо дольше.
(Иногда брандмауэры слишком рьяно отвергают то, что оба хоста посчитали бы нормальным. Например, когда браузеры начали экспериментировать с TCP Fast Open, мой домашний маршрутизатор, предоставленный провайдером, в то время заблокировалвсеПакеты TFO основывались на его убеждении, что «пакеты SYN не могут содержать данные» и выдавали «Предупреждение о вторжении» в его журналах каждый раз. Я считаю, что это важная часть того, почему QUIC разрабатывается отдельно от TCP.)