Что то в сети блокирует udp соединение браузера

Обновлено: 24.06.2022

После подключения сети выставил профиль "Сеть предприятия". Отобразилось "Рабочая сеть". Это проделано на обоих компьютерах. Выставил IP 192.168.1.100 и 192.168.2.100 соответственно. Маршрутизатор выставил 1.1 и 2.1 соответсвенно.

Если пытаюсь пинговать друг друга, то пинги не идут.

Как только я на К1 (192.168.1.100) выключаю брендмауэр, то на него пинг идет.

Как только я на К2 (192.168.2.100) выключаю брендмауэр, то на и него пинг идет.

Все компьютеры из "своей" подсети могут пинговать Win7 с всключенным брендмауэром.

Как я предполагаю, Win7 считает другую подсеть уже интернетом.

Как мне заставить брендмауэр Win7 считать определенные сети (в частности 192.168.1.0/24 и 192.168.2.0/24) частными (сетью предприятия)?

P.S. Никаких сторонних приложений на данных компьютерах не установлено. Маршрутизатор (192.168.1.1 + 192.168.2.1) ничего не блокирует.

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

Оскорбление — это любое поведение, которое беспокоит или расстраивает человека или группу лиц. К угрозам относятся любые угрозы самоубийством, насилием, нанесением ущерба и др. Любое содержимое для взрослых или недопустимое на веб-сайте сообщества. Любое изображение, обсуждение наготы или ссылка на подобные материалы. Оскорбительное, грубое или вульгарное поведение и другие проявления неуважения. Любое поведение, нарушающее лицензионные соглашения, в том числе предоставление ключей продуктов или ссылок на пиратское ПО. Незатребованная массовая рассылка или реклама. Любые ссылки или пропаганда сайтов с вирусным, шпионским, вредоносным или фишинговым ПО. Любое другое неуместное содержимое или поведение в соответствии с правилами использования и кодексом поведения. Любое изображение, ссылка или обсуждение, связанные с детской порнографией, детской наготой или другими вариантами оскорбления или эксплуатации детей.

В этой статье данная статья позволяет решить проблему, из-за которой связь uDP блокируется правилом брандмауэра Windows WSFC, когда сетевое подключение прерывается, а затем восстанавливается.

Применяется к: Windows Server 2012 R2
Исходный номер КБ: 2701206

Симптомы

Эта проблема возникает, если входящий UDP-связь включена Windows брандмауэра. Одной из служб, на которые может повлиять эта проблема, является кластеризация Windows сервера (WSFC). Хотя связь с сердцебиением (UDP 3343) может быть включена по умолчанию, связь может быть заблокирована. Когда возникает эта проблема, состояние связи в диспетчере кластера failover отображается как "Недостижимое".

Причина

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

Разрешение 1. Используйте команду netsh

Запустите следующие netsh команды по повышенной командной подсказке:

  • При использовании этого метода служба Кластера может остановиться. Поэтому, если это возможно, необходимо остановить службу кластера перед запуском этого метода, а затем перезапустить службу кластера после выполнения других действий.
  • При использовании этого метода также отключено правило "Кластеры неудачных отключений (UDP-in)".
  • Служба кластера позволяет установить порт брандмауэра UDP при запуске.

Разрешение 2. Использование брандмауэра Windows с помощью надстройки Advanced Security

Запустите надстройку microsoft Management Console Windows брандмауэра с расширенным обеспечением безопасности. Для этого выполните следующие действия:

  • При использовании этого метода служба Кластера может остановиться. Поэтому, если это возможно, необходимо остановить службу кластера перед запуском этого метода, а затем перезапустить службу кластера после выполнения других действий.
  • При использовании этого метода также отключено правило "Кластеры неудачных отключений (UDP-in)".
  • Служба кластера позволяет установить порт брандмауэра UDP при запуске.

Разрешение 3. Отключение службы списков сетей

Чтобы отключить службу службы списков сети, выполните следующие действия:

Перед отключением службы списков сети следует учитывать, что это действие вносит следующие изменения:

  • По умолчанию Windows брандмауэр будет выбирать общедоступный профиль. Поэтому в общедоступный профиль должны быть добавлены правила, установленные для профилей домена или частных пользователей.
  • Центр общего доступа к сети не отображает типы профилей или состояние сетевого подключения.
  • Значок сетевого подключения больше не отображается на панели задач Windows.

Изменения, которые происходят после отключения службы списков сети, ограничиваются отображением сетевых сведений. Они не влияют на поведение системы.

Статус

Корпорация Майкрософт подтвердила, что это известная проблема в Windows Брандмауэре.

Новый компьютер, со свежеустановленными Windows 7 Home Basic, антивирусом и фаерволлом, подключил к сети с помощью ADSL модема в режиме роутера.

Тем не менее, не смог загрузить ни одну страницу.

Посмотрел логи фаерволла. Там заблокированные исходящие UDP соединения процесса System, порт назначения 65535, адрес назначения - DNS, предоставленные провайдером. Разрешил эти подключения - всё заработало, сайты загружаются. Отмечу также, что этот процесс пытается подключиться к некоторым из посещаемых сайтов, вполне респектабельных, а также к IP обновления антивируса. (Я разрешил эти соединения только для DNS, прочее блокируется - тем не менее, все работает).

При внимательном изучении логов обнаружил, что вначале System пытается подключитья к 224.0.0.252 (UDP исходящий порт 49152, порт назначения 65535). Этот мультикастовый адрес использует сервис под названием LLMNR (только в описании сказано, что LLMNR использует 5355 порт). Отключил LLMNR в реестре - исходящих на 224.0.0.252 больше нет, но System продолжает долбиться на 65535 порт DNS.

Стал отключать разные службы, пытаясь определить, не даст ли это какого-то результата. Оказалось, что включение и выключение службы DNS клиент оказывает воздействие.

Первый вариант - служба DNS клиент включена . System (PID 4) пытается соединиться с DNS, порт назначения 65535, исходящий порт 49152. Если это подключение заблокировать, сайты не загружаются. Обращений к IP сайтов не происходит. В активных подключениях нет никаких соединений с DNS, в том числе svchost.exe на 53 порт.

Если разрешить подключение System UDP исходящее на 65535 порт DNS, то всё загружается. В активных подключениях есть svchost.exe, исходящее UDP подключение к 53 порту DNS.

Второй вариант - служба DNS клиент выключена . System (PID 4) пытается соединиться с DNS, порт назначения 65535, исходящий порт 49152. Если это подключение заблокировать, сайты загружаются. Весь софт, взаимодействующий с сетью, запрашивает подключение к DNS (UDP порт назначения 53). В активных подключениях нет svchost.exe. Обновления Windows не происходит (возвращает ошибку), хотя для svchost.exe есть разрешение на соединение с диапазоном IP Windows update. В логах фаерволла нет записей о блокировании svchost.

netstat -a дает, в частности, такую строку UDP 0.0.0.0:49152 *:* netstat -abn говорит что (дословно не помню, но по смыслу) "не удается определить владельца этого подключения".

Буду признателен, если мне пояснят, что же это за подключение, зачем оно лезет в сеть.

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

В 2017 году большинство популярных веб-игр типа agar.io использует для передачи данных WebSockets через TCP. Если бы в браузерах был встроенный UDP-аналог WebSockets, то это бы сильно улучшило работу с сетями в этих играх.

Вводная информация

К сожалению, новый комплект стандартов веб-разработки не отвечает потребностям многопользовательских игр или слишком сложен в реализации.

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

Проблема

Веб создан поверх TCP, который является протоколом с сохранением порядка пакетов. Для надёжной доставки данных в нужном порядке в условиях утери пакетов TCP должен хранить самые новые данные в очереди, ожидая повторной отправки утерянных пакетов. В противном случае данные будут доставлены в неправильном порядке.

Этот принцип называется блокировкой начала очереди. Он создаёт раздражающую разработчиков и почти трагикомичную ситуацию. Самые новые данные, которые им нужны, ждут повторной пересылки старых данных, но на момент получения пересланных данных они уже устаревают и становятся бесполезными.

На практике это означало, что для каждой игры разрабатывался собственный протокол поверх UDP, реализующий весь необходимый функционал, и отправляющий бóльшую часть данных ненадёжным способом без сохранения порядка. Это обеспечивало максимально быструю доставку временны́х данных без ожидания повторной передачи утерянных пакетов.

А что же нужно сделать в случае с веб-играми?

Главная проблема веб-игр сегодня заключается в том, что разработчики игр не имеют возможности воспользоваться в браузере наилучшим решением, выбранным игровой индустрией. Вместо этого веб-игры отправляют игровые данные по TCP, что приводит к низкой отзывчивости.

Использование TCP совершенно необязательно, эту проблему можно было решить «по щелчку пальцев», если бы у веб-игр появилась возможность отправлять и принимать UDP-пакеты.

А что такое WebSockets?

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

К сожалению, поскольку WebSockets реализован поверх TCP, данные всё равно подвержены блокировке начала очереди.

Что такое QUIC?

Важнейшая черта QUIC — поддержка множественных потоков данных. Клиент или сервер может неявным образом создавать новые каналы, увеличивая идентификатор канала (channel id).

Концепция каналов обеспечивает два больших преимущества:

  1. Позволяет избежать отправки запросов подтверждения подключения при каждом создании нового запроса.
  2. Устраняет блокировку начала очереди между несвязанными потоками данных.

Что такое WebRTC?

WebRTC — это набор протоколов, обеспечивающих соединение типа «точка-точка» (peer-to-peer) между браузерами для таких областей применения, как потоковое воспроизведение аудио и видео.

Замечу, что WebRTC поддерживает канал данных, который можно настроить на «ненадёжный» режим, что позволяет осуществлять через браузер ненадёжную передачу данных без сохранения порядка.

Так почему же в современных браузерных играх 2017 года до сих пор используется WebSockets?

Причина заключается в том, что в многопользовательских играх существует тенденция перехода от передачи peer-to-peer к клиент-серверной модели. И хотя WebRTC позволяет удобно отправлять ненадёжные «беспорядочные» данные из браузера в браузер, он терпит крах, когда требуется передача данных между браузером и выделенным сервером.

Проблема возникает из-за чрезвычайной сложности WebRTC. Причины этой сложности понятны: WebRTC в первую очередь был разработан для обмена данными peer-to-peer между браузерами, поэтому для обхода NAT и передачи пакетов он в худшем случае требует поддержки STUN, ICE и TURN.

Но с точки зрения разработчиков игр вся эта сложность ложится на них мёртвым грузом, ведь STUN, ICE и TURN совершенно не нужны для обмена данными с выделенными серверами, имеющими публичные IP-адреса.

«Я чувствовал, что нам нужна UDP-версия WebSockets. Это единственное, о чём мы мечтали».
Матеус Валадарес (Matheus Valadares), создатель agar.io

Если вкратце, то разработчики игр любят простоту, и решение типа «WebSockets for UDP» привлекает их гораздо больше, чем сложность WebRTC.

Почему бы просто не разрешить отправлять UDP?

Последний вариант решения проблемы — просто позволить пользователям отправлять и получать UDP-пакеты непосредственно через браузер. Разумеется, это абсолютно ужасная идея и есть веские причины тому, почему этого никогда нельзя допустить.

Каким может быть решение?

Но что, если подойти с другого конца? Вместо попыток навести мосты от мира веба к играм мы можем начать с нужных играм техник и доработать их до решения, хорошо работающего в вебе.

Меня зовут Гленн Фидлер (Glenn Fiedler), я занимаюсь разработкой игр в течение последних 15 лет. Бóльшую часть этого времени я специализировался в сетевом программировании. Я получил огромный опыт, работая над динамичными экшн-играми. Последней игрой, над которой я работал, была Titanfall 2.

Около месяца я прочитал эту статью на Hacker News: WebRTC: будущее веб-игр.

В ней создатель agar.io Матеус Валадарес рассказывал, что WebRTC слишком сложен для него, и он продолжает использовать в своих играх WebSockets.

Я задумался: ведь наверняка должно быть более простое решение, чем WebRTC?

Мне стало интересно, как бы выглядело такое решение?

По моему мнению решение должно обладать следующими свойствами:

  1. Оно должно устанавливать соединение, чтобы его нельзя было использовать в DDoS-атаках и для поиска брешей в безопасности.
  2. Шифрование, потому что в 2017 году ни одна игра или приложение не должны отправлять незашифрованные пакеты.
  3. Аутентификация, потому что выделенные серверы должны принимать соединения только от клиентов, авторизованных в бекэнде.

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

netcode.io

Решение к которому я пришёл — это netcode.io

netcode.io — простой сетевой протокол, позволяющий клиентам безопасно подключаться к выделенным серверам и обмениваться данными по UDP. Он ориентирован на подключения, шифрует и подписывает пакеты, а также обеспечивает поддержку аутентификации, чтобы к выделенным серверам могли подключаться только авторизованные клиенты.

Он предназначен для таких игр, как agar.io, которым требуется разнести игроков с основного веб-сайта на экземпляры выделенных серверов. Каждый из серверов имеет ограничение на максимальное количество игроков (в базовой реализации — до 256 игроков на экземпляр сервера).

Основная идея заключается в том, что веб-бэкенд выполняет авторизацию. Когда игрок захочет поиграть, бекэнд осуществляет вызов REST для получения токена подключения, который передаётся выделенному серверу как часть запроса подтверждения подключения по UDP.

Токены подключения имеют малый срок жизни и полагаются на общий приватный ключ между веб-бекэндом и экземплярами выделенных серверов. Преимущество этого подхода заключается в том, что к выделенным серверам могут подключаться только авторизованные пользователи.

netcode.io выигрывает у WebRTC в простоте. В нём применяется схема только с выделенными серверами, поэтому использовать ICE, STUN и TURN не требуется. Благодаря реализации шифрования, подписей и аутентификации с помощью libsodium он позволяет избежать сложностей полной реализации DTLS, при этом обеспечивая тот же уровень безопасности.

За прошлый месяц я создал базовую реализацию netcode.io на C. Она выпущена под лицензией BSD из трёх пунктов. За несколько месяцев я надеюсь усовершенствовать эту реализацию, написать спецификацию и поработать с другими разработчиками над портированием netcode.io на различные языки.

Как это работает

Токен подключения состоит из двух частей:

  1. Приватная часть, зашифрованная и подписанная общим приватным ключом с помощью примитива AEAD из libsodium. Его невозможно считать, модифицировать или подделать в клиенте.
  2. Публичная часть, предоставляющая информацию, необходимую клиенту для подключения. Например, ключи шифрования для UDP-пакетов и список адресов серверов, к которым можно подключиться, а также другую информацию, относящуюся к части «связанных данных» AEAD.

При подключении к выделенному серверу клиент периодически отправляет по UDP пакет запроса на подключение. Этот пакет содержит приватные данные токена подключения, а также дополнительные данные для AEAD, например, информацию о версии netcode.io, идентификатор протокола (64-битное число, уникальное для каждой конкретной игры), временну́ю метку срока действия токена подключения и порядковый номер примитива AEAD.

Когда выделенный сервер получает по UDP запрос на подключение, он сначала с помощью примитива AEAD проверяет валидность содержимого пакета. Если какие-то публичные данные в пакете запроса на подключение были изменены, то проверка сигнатуры выдаст ошибку. Это не позволит клиентам изменять временну́ю метку срока действия токена подключения, а также позволит быстро отклонять токены с истёкшим сроком.

Если токен подключения валиден, то он расшифровывается. Внутри он содержит список адресов выделенных серверов, для которых он валиден. Это не позволяет вредоносным клиентам использовать один токен для подключения ко всем доступным серверам.

Сервер также проверяет, не был ли токен подключения уже использован, выполняя поиск краткой истории HMAC токена. Если совпадение найдено, то запрос на подключение игнорируется. Благодаря этому один токен нельзя использовать для подключения нескольких клиентов.

Кроме того, сервер допускает подключение только одного клиента с одним IP-адресом и портом в любой момент времени. Также одновременно к серверу может быть подключен только один клиент по уникальному client id. Идентификатор client id — это 64-битное целое число, уникальным образом идентифицирующее клиента, авторизованного веб-бекэндом.

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

С этого момента все пакеты, передаваемые между клиентом и сервером, шифруются этими ключами. Если в течение короткого промежутка времени (например, пяти секунд) UDP-пакеты от адреса не поступают, то связка адреса и ключей шифрования становится недействительной.

Затем сервер проверяет, есть ли на сервере место для клиента. Каждый сервер поддерживает определённый максимум клиентов. Например, в игре на 64 игроков будет 64 места для подключения клиентов. Если сервер заполнен, он отвечает пакетом отказа на запрос подключения. Это позволяет клиентам быстро узнавать о том, что сервер заполнен и нужно переместиться на следующий сервер в списке.

Если на сервере есть место для клиента, то сервер не предоставляет это место сразу. Вместо этого он хранит адрес + HMAC токена подключения клиента как потенциального клиента. Затем сервер отвечает пакетом вызова подключения, содержащим токен вызова. Токен вызова — это блок данных, зашифрованных случайным ключом. Ключ выпускается в момент запуска сервера.

Рандомизация ключа гарантирует отсутствие проблем с безопасностью, возникающих при шифровании токенов вызова нескольких серверов одним порядковым числом (серверы не координируются друг с другом). Кроме того, пакет вызова подключения значительно меньше пакета запроса на подключение, что позволяет избежать использования протокола для DDoS-атак типа «усиление».

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

В противном случае сервер назначает клиенту свободное место на сервере и отвечает пакетом поддержки подключения, который сообщает клиенту, что ему выделено место на сервере. Такое место называется индексом клиента. В многопользовательских играх он обычно используется для идентификации клиентов, подключённых к серверу. Например, клиенты 0, 1, 2, 3 в игре на четырёх игроков соответствуют игрокам 1, 2, 3 и 4.

Теперь сервер считает, что клиент подключен и что ему можно отправлять пакеты полезной нагрузки. В этих пакетах содержатся данные, относящиеся к игре. Пакеты доставляются без сохранения порядка. Единственный недостаток такого способа в том, что поскольку клиент перед тем, как получить индекс клиента и убедиться в полном подключении, он должен сначала получить пакет поддержки подключения, а сервер отслеживает, подтверждён ли клиент, проверяя место для каждого клиента.

Флаг подтверждения для каждого клиента изначально имеет значение false и становится true, когда сервер получает от клиента пакет поддержки подключения или пакет полезной нагрузки. Пока клиент не подтверждён, при каждой отправке пакета полезной нагрузки этому клиенту предварительно отправляется и пакет поддержки соединения. Это гарантирует статистическую вероятность того, что клиент знает свой индекс и будет полностью подключён до получения первого пакета полезной нагрузки, что минимизирует количество циклов установки подключения.

После того, как подключение клиента и сервера полностью выполнено, они могут обмениваться UDP-пакетами в обоих направлениях. Обычно игровые протоколы отправляют введённую игроком информацию от клиента к серверу с большой скоростью, например, 60 раз в секунду, а состояние мира от сервера к клиенту немного реже, например, 20 раз в секунду. Однако в самых современных AAA-играх скорость обновления данных сервера увеличена.

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

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

Заключение

В популярных веб-играх типа agar.io передача данных осуществляется через WebSockets поверх TCP, поскольку в контексте клиент-серверной структуры с выделенными серверами WebRTC использовать сложно.

Один из вариантов решений для Google — сделать интеграцию поддержки каналов данных WebRTC для выделенных серверов гораздо более простой для разработчиков игр.

Или же можно использовать netcode.io, применяющий намного более простое решение типа «WebSockets для UDP». Если стандартизировать его и встроить в браузеры, это тоже может решить проблему.


Гленн Фидлер (Glenn Fiedler) — основатель и президент The Network Protocol Company. Он предоставляет услуги по настройке сетевой части игр. До основания компании Гленн был ведущим программистом Respawn Entertainment, где работал над Titanfall 1 и 2.

hint000

5d32669818677495584016.jpg


для входящих и для исходящих нужно будет два отдельных правила (см. параметр "Направление")

Upd. Насколько это работоспособно - отдельный вопрос. Подобные роутеры в основном использую как тупые точки доступа внутри локальной сети, только wi-fi на них настраиваю и выключаю dhcp. Возможности защиты у подобных роутеров игрушечные. Но согласен, что за неимением чего-то более серьезного можно попытаться и на таком настроить.

5d32ccc9a2c7e228199348.jpg

Спасибо за ваш ответ, прошу прощения, у меня еще больше вопросов сейчас возникло.
Именно это пробовал делать (в целом, доступ к интернету для свех девайсов блокировался вообще), возник вопрос. Я указываю в целях режим IP, правильно ли оставлять поле адресов пустым, если меня интересуют любые подключения ?

5d32ce85bc023818663150.jpg

В правилах фильтрации, если я правильно понял, мы запрещаем пакетам проходить.

Также, пришла в голову еще одна мысль, а нельзя ли подключить роутер к пк, настроить фаервол и раздать wifi на другие девайсы ?

hint000

Нет. Если вы поставите по умолчанию "запретить", то вам придётся явно прописывать всё, что нужно разрешить. Вы же наоборот хотите прописать явно то, что нужно блокировать. А значит по умолчанию нужно разрешить.

скорее всего да, если роутер не ругается на пустые поля. Почти наверное там внутри (за ширмой интерфейса, в прошивке роутера) сидит iptables, а он на отсутствующий параметр реагирует как раз так, как вы и ожидаете (т.е. нормально).

тут не совсем понятно, какую схему работы вы предполагаете, ваши слова можно интерпретировать по разному. В принципе, я много лет в разных офисах настраиваю сеть так: подобные роутеры-мыльницы только раздают wi-fi, WAN-порт на них не задействован; в качестве роутера беру какой-нибудь самый старый ПК, добавляю туда сетевую карту и устанавливаю Linux. Получается ПК-роутер с офигенно широкими возможностями. Файервол на нём - тот самый iptables, только не ограниченный вот таким куцым интерфейсом, а позволяющий рулить сетью как захочется. Но, конечно, настраивается всё это из командной строки и в текстовых конфигурационных файлах - если это не пугает. Это всё в условиях офиса, когда выделенный бюджет не просто мал, а скорее близок к нулю. При нормальном бюджете можно побаловаться с какими-нибудь Cisco, но я таких организаций не встречал (кроме банков). В домашних же условиях всё проще - роутер MicroTik какой-нибудь 951 или 952, за глаза хватит возможностей.

hint000, Большое спасибо за подробные ответы. Настройка tp-link результатов не дала, максимум что удалось - запретить вообще все подключения ко всем девайсам в локальной сети. Пожалуй буду заказывать Mikrotik.

hint000, здравствуйте, могли бы мне помочь в настройки роутера ? Если да? То как с вами можно связаться ?

Читайте также: