Порт 3478 для чего используется

Port 3478 Details

Ubiquiti UniFi Controller uses these ports:
8080 TCP — http port for UAP to inform controller
8443 TCP — https port for controller GUI/API
8880 TCP — http portal redirect port (may also use ports 8881, 8882)
8843 TCP — https portal redirect port
3478 UDP — STUN port (should be open at firewall)

Ubiquiti UniFi Cloud Access uses these ports:
443 TCP/UDP — Cloud Access service
3478/UDP — port used for STUN
8883/TCP — Cloud Access service

Apple FaceTime, Apple Game Center use ports 3478-3497 (UDP).

Playstation 4 game ports:
TCP 1935, 3478-3480
UDP 3074, 3478, 3479

Test Drive Unlimited 2, Motorola Ojo, Call of Duty World at War also use this port (UDP).
Elite Dangerous: Horizons pings port 3478 every 5 minutes.

Notes:
Port numbers in computer networking represent communication endpoints. Ports are unsigned 16-bit integers (0-65535) that identify a specific process, or network service. IANA is responsible for internet protocol resources, including the registration of commonly used port numbers for well-known internet services.
Well Known Ports: 0 through 1023.
Registered Ports: 1024 through 49151.
Dynamic/Private : 49152 through 65535.

TCP ports use the Transmission Control Protocol, the most commonly used protocol on the Internet and any TCP/IP network. TCP enables two hosts to establish a connection and exchange streams of data. TCP guarantees delivery of data and that packets will be delivered in the same order in which they were sent. Guaranteed communication/delivery is the key difference between TCP and UDP.

UDP ports use the Datagram Protocol. Like TCP, UDP is used in combination with IP (the Internet Protocol) and facilitates the transmission of datagrams from one computer to applications on another computer, but unlike TCP, UDP is connectionless and does not guarantee reliable communication; it’s up to the application that received the message to process any errors and verify correct delivery. UDP is often used with time-sensitive applications, such as audio/video streaming and realtime gaming, where dropping some packets is preferable to waiting for delayed data.

When troubleshooting unknown open ports, it is useful to find exactly what services/processes are listening to them. This can be accomplished in both Windows command prompt and Linux variants using the «netstat -aon» command. We also recommend runnig multiple anti-virus/anti-malware scans to rule out the possibility of active malicious software. For more detailed and personalized help please use our forums.

Что такое STUN-сервер?

STUN-сервер (Simple Traversal of User Datagram Protocol [UDP-протокол пользовательских датаграмм] через сервер NAT [транслятор сетевых адресов]) позволяет клиентам NAT (т.e. компьютерам за сетевым экраном) устанавливать сеансы связи с провайдером VOIP, находящимся за пределами локальной сети.

STUN-сервер позволяет клиентам находить свой адрес общего доступа, тип NAT, за которым они находятся и порт Интернета, связываемый NAT с конкретным локальным портом. Эта информация используется для настройки связи UDP между клиентом и провайдером VOIP и организации сеанса. Протокол STUN определяется стандартом RFC 3489.

Соединение с сервером STUN устанавливается через UDP-порт 3478, однако сервер предлагает клиентам выполнить проверку также и альтернативного IP и номера порта (у серверов STUN есть два IP-адреса). В RFC говорится, что выбор порта и IP является произвольным.

Сервер 3CX поддерживает сервис STUN для SIP-клиентов – достаточно просто установить АТС.

Гайд по настройке Wi-Fi роутера для стабильной работы игровых сервисов Статьи редакции

Как избавиться от некоторых проблем с PSN, Xbox Live и Steam.

Материал подготовлен при поддержке «Дом.ru»

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

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

В этой статье перечислены самые простые и распространённые способы заставить нормально работать PSN, Xbox Live, Steam и сетевые функции Nintendo Switch. Их советуют сами производители консолей и владельцы игровых сервисов, кроме того, они помогли многим пользователям.

Для примера в статье взяты роутеры провайдера «Дом.ru» серии Archer производства TP-Link — их интерфейс будет показан в скриншотах ниже. В ходе написания статьи ни один роутер не пострадал!

Главное правило геймера: провод — твой друг. Если есть возможность подсоединить консоль, ПК, ТВ-приставку, телевизор и другие сетевые устройства через Ethernet-кабель — это стоит сделать. Из-за безумной загрузки диапазона частот в современных домах Wi-Fi на частоте 2,4 ГГц будет захлёбываться уже в соседней комнате. А 5 ГГц может просто не пройти через три железобетонные стены из-за короткой длины радиоволны.

Не стоит забывать и о том, что в старых PS4 («толстушках») был очень плохой Wi-Fi-модуль, качество приёма у которого оставляло желать лучшего. В новых PS4 Slim и Pro такой проблемы уже нет.

Кроме того, довольно слабый Wi-Fi-модуль стоит в Nintendo Switch. Он тоже может легко потерять сигнал буквально в соседней комнате. И если в случае со старой PS4 ещё можно воспользоваться проводом, то Switch спасёт только переходник с USB на Ethernet, но это подходит только для стационарного режима игры.

Первое, что нужно сделать для настройки — зайти в панель управления роутера. Достаточно подсоединиться к нему с помощью Wi-Fi или Ethernet-провода, а потом ввести его адрес в строке браузера. Адрес можно получить из информации о сетевом соединении в операционной системе. В большинстве случаев это адреса 192.168.1.1 или 192.168.0.1.

Информацию о том, какой именно адрес нужно набрать для доступа к роутеру, можно посмотреть в настройках сети.

Windows: Панель управления → Сеть и Интернет → Wi-Fi → Кликнуть по сети, к которой подключено устройство.

Mac: Приложение «Системные настройки» → Сеть → Выбрать соответствующее подменю

Роутер спросит логин администратора и пароль — если их никогда не меняли, то можно найти эту информацию в инструкции или на сервисной наклейке на самом устройстве.

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

Для присуждения статического адреса PS4 нужно сначала найти и записать её MAC-адрес из карты сети на главной странице панели администратора роутера. Он выглядит примерно так — a0:b1:c2:d3:e4:f5. Если консоль не подсоединена или появились трудности с нахождением карты сети внутри админки, то можно включить PS4 и посмотреть в разделе «Информация» её параметры, там есть два MAC-адреса — для Wi-Fi и проводного соединения.

Далее нужно перейти в настройки Network роутера, а там найти пункт DHCP. В разделе статических IP следует выбрать уже подсоединённую PS4 или ввести её MAC-адрес вручную, а после этого присудить ей новый IP. Если пул адресов подсети выглядит как 192.168.1.XXX, то можно присудить PS4, например, вот такой адрес — 192.168.1.155. Если же пул адресов вида 192.168.0.XXX, то адрес PS4 будет такой — 192.168.0.155.

Число в конце может быть от 2 до 255 — обычно этот диапазон прописан тут же в настройках DHCP. Естественно, нужно разом присудить всем важным устройствам в доме статические IP.

Следующее, что нужно сделать — проверить, активен ли режим UPnP. По умолчанию он включён во всех современных роутерах. Но на всякий случай лучше найти UPnP в настройках NAT Forwarding и удостовериться, что он включен.

Теперь главное — разобраться с переадресацией портов. В домашней сети есть внешние порты, по которым идёт трафик из интернета. А ещё у каждого устройства внутри сети тоже есть порты. Роутер в большинстве случаев сам выбирает, куда перенаправлять трафик из внешнего порта сети во внутренний порт устройства. Для корректной работы всех сетевых сервисов нужно заставить роутер чётко выполнять инструкции и пускать весь трафик так, как было задумано, без самовольного распределения.

Тут начинается самое интересное. Каждый популярный игровой сервис рекомендует свой набор портов, которые нужно открывать внутри домашней сети для консолей или ПК. Более того, у всех популярных сетевых игр тоже есть свои пулы портов — их тоже стоит открыть. Начнём с открытия портов для консоли PS4. На сетевом жаргоне этот процесс называется «пробросить порты».

Внутри раздела «Переадресация портов» (NAT Forwarding) нужно найти меню «Виртуальный сервер» (Virtual Server), где предложено добавить в таблицу строки со следующими параметрами: IP-адрес устройства (который был присуждён ранее), первый порт, второй порт, тип порта (TCP, UDP или оба сразу).

В обеих графах портов нужно упоминать одни и те же числа, так как цель этого процесса как раз в соответствии внутреннего порта PS4 внутри сети и внешнего порта домашней сети. Для стабильной работы PSN нужно ввести туда следующие последовательности чисел:

• TCP: 80, 443, 1935, 3478, 3479, 3480, 9295
• UDP: 3478, 3479, 9296, 9297, 9303

Порты 3478 и 3479 нужно прописать как для TCP, так и для UDP. Если роутер это поддерживает, то можно указать позицию Both («оба»).

Порты 9ххх нужны для корректной работы функций Remote Play и Share Play. Они могут заработать и так, но если наблюдаются проблемы и ошибки с ними, то стоит открыть эти порты.

Теперь очередь за Xbox One. Нужно не забыть, что для него будет использоваться другой внутренний IP, а не тот же, что и для PS4 — распространённая ошибка при настройке открытия портов. Для корректной работы Xbox Live Microsoft советует¹ пробросить следующие порты:

• TCP: 53, 80, 3074
• UDP: 53, 88, 500, 3074, 3544, 4500

Далее следует Switch — Nintendo предлагает² пробросить такой диапазон портов:

• UDP: 1:65535

Стоит отметить, что здесь не единичные порты, а целый диапазон. Большинство роутеров воспринимает диапазон портов в формате xxxx:xxxx, то есть через двоеточие.

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

Так что это стоит делать на свой — и риск. Ещё одно решение — открыть порты не внутри роутера, а через брендмауэр Windows для клиента Steam. Посмотреть, как это сделать, можно на сайте³ Microsoft.

Так или иначе, сама Valve советует⁴ пробросить следующие порты, причём с пометками о том, для чего это нужно.

Для корректной работы базовой части магазина и скачивания контента:

• TCP: 80, 443, 27015:27030
• UDP: 27015:27030

Для работы матчмейкинга Steam, домашнего стриминга игр с устройства на устройство (In-Home Streaming) и сервисных команд клиента:

• UDP: 4380, 27000:27015, 27031:27037

Для корректной работы p2p-сети и голосового чата в Steam:

• UDP: 3478, 4379

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

Вся боль p2p разработки

Добрый день, хабрасообщество! Сегодня я хотел бы рассказать о волшебном и чудесном проекте компании Тензор — удаленном помощнике. Это система удаленного доступа, связывающая миллионы клиентов и операторов в рамках общей клиентской базы СБИС. Удаленный помощник уже сейчас тесно интегрирован с online.sbis.ru. Каждый день мы регистрируем более десяти тысяч подключений и десятки часов сессионного времени в сутки.В этой статье мы расскажем о том, как мы устанавливаем p2p соединения, и что делать, если этого сделать не удается.

Опыт — сын ошибок трудных

Систем удаленного доступа существует достаточно много. Это и всевозможные вариации бесплатных VNC, и достаточно мощные и предлагающие широкий набор функционала платные решения.Изначально наша компания использовала адаптацию одного из таких решений — UltraVNC. Это отличная бесплатная система, которая позволяет подключиться к другому ПК, зная его IP. Вариант того, как стоит поступать, если ПК имеет непрямой доступ к сети интерне, уже мелькал на просторах Хабра, и мы не будем затрагивать эту тему. Этого решения будет достаточно только до достижения сравнительно небольшого количества одновременных подключений. Шаг влево, шаг вправо, и начинается головняк с масштабированием, удобством использования, интеграцией в систему и сложностью доработок, которые, конечно, появляются в процессе жизненного цикла ПО, с чем мы и столкнулись.

Итак, было принято решение изобрести свой велосипед создать свою систему управления удаленными рабочими столами, которую можно было бы интегрировать в общую экосистему СБИС. Конечно, самый простой способ связать 2 ПК, который не использует только ленивый — по числовому идентификатору. В нашей реализации мы используем рандомные 6-и знаковые номера без привязки к конкретному клиенту.

Один очень известный человек однажды сказал:

В самом начале нашего пути, эта цитата была очень похожа на правду: было понимание каким образом можно «познакомить» друг с другом клиента и оператора. Но на практике все оказалось не совсем тривиально.

Введение в p2p

Для связи 2х устройств мы используем сигнальный сервер — посредник, доступ к которому есть у обеих сторон. Его роль заключается в регистрации и возможности обмена информацией между участниками в режиме реального времени. Через него без лишних хлопот мы производим обмен endpoint’ами (связка IP-адрес и порт, точка доступа) с целью установки соединения.

Этот сигнальный сервер, именуемый у нас remote helper manager(RHM) — пул написанных на nodejs систем, обеспечивающих отказоустойчивую работу всего сервиса. Нууу, точнее, как «отказоустойчивую» … мы на это надеемся :). Подключение к одному из серверов происходит по принципу round-robin. Таким образом клиент и оператор могут быть подключены к разным серверам, и вся механика по их синхронизации и координации полностью снята с десктопного приложения.

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

Кстати, не поступайте как мы – не стреляйте себе в ногу: если используете 443 TCP порт — используйте TLS, а не чистый трафик. Все больше и больше брандмауэров его блокируют и разрывают соединение, причем, нередко на стороне провайдера.

Самые распространенные в сети интернет протоколы обмена информацией — это UDP и TCP. UDP — быстр и легок, однако лишен нативной возможности гарантировать доставку пакетов и их очередность. TCP лишен этих недостатков, однако чуть более сложен в процессе установки p2p соединения. А с последними тенденциями, как мне кажется, прямое tcp соединение и вовсе может кануть в лету.

Далеко не всегда установка p2p соединения зависит от умения работать с сетевыми протоколами. По большей части эта возможность зависит от конкретных сетевых настроек, чаще: типа NAT(Network address translation) и/или настроек файрвола.

Принято разделять NAT на 4 типа, каждый из которых отличаются правилами трансляции пакетов из внешней сети конечному пользователю:

• Symmetric NAT
• Cone/Full Cone NAT
• Address restricted cone NAT
• Port restricted cone NAT

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

Чтобы узнать свой IP-адрес и порт на внешнем устройстве (для простоты назовем его маршрутизатором), мы используем STUN (Session traversal utilities for NAT) и TURN (Traversal using relay NAT) сервера. STUN – для определения внешних IP: порт(endpoint) на UDP протокола, TURN – для TCP.

Почему так, ведь гораздо проще было бы получить внешний IP с нашего же сигнального сервера?

Здесь имеется как минимум 4 аргумента «за»:

1. Возможность прозрачного расширения списка серверов (как своих, так и общедоступных) для сбора endpoint’ов, таким образом повысить отказоустойчивость системы.
2. Взаимодополняемость и широкое распространение протоколов STUN и TURN позволяет уделять минимум внимания на сбор endpoint’ов и ретрансляцию трафика.
3. STUN и TURN протоколы очень похожи. Разобравшись с архитектурой STUN пакетов, TURN идет уже по «накатанной». А использование TURN дают нам возможность ретрансляции трафика при провале попытки установить прямое подключение.
4. У нас уже использовался STUN/TURN сервер «coturn» в проекте видеозвонков, а значит можно было «заюзать» их мощности с минимальными вливаниями в «железо».

Как же строится общение с сервером по STUN/TURN протоколу

Этапы получения endpoint’ов задокументированы в RFC #3489, #5389, #5766 и #6062.
Все сообщения к STUN или TURN протоколу имеют следующий вид:

1. 12 байта на тип сообщения
2. 22 байта на его длину (размер всех последующих атрибутов)
3. 12 байт — для рандомного идентификатора для TURN и 16 байт — для STUN пакетов. Их размер отличается на 4 байта — эти данные зарезервированы для TURN пакета под константный MagicCookie.

1. 2 байта на тип атрибута
2. 2 байта на его длину
3. самого значения атрибута

Как выглядит сбор endpoint’а для UDP протокола:

1. Коннект к серверу
2. Отправка пакета, содержащего binding request:
   
3. Получение пакета, содержащего binding response:
   />
4. Парсинг пакета и извлечение mapped-address:
   0x00 0x01 — Тип атрибута, соответствующий MAPPED-ADDRESS
   0x00 0x08 — Совокупная длина атрибута
   0x00 0x01 — Версия протокола, соответствующая IPv4
   0x30 0x39 – Порт, со значением 12345

Сбор endpoint’а для TCP несколько отличается, т.к. получаем мы его по TURN протоколу. Почему именно так? Все объясняется минимизацией количества сокетов, подключенных к TURN-серверу, а значит, потенциально большее количество людей смогут «висеть» на одном сервере ретрансляции трафика.

Для сбора кандидата по TURN протоколу необходимо:

1. Подключиться к серверу.
2. Отправить пакет, содержащий allocation request.
3. При необходимости авторизации на TURN сервере в ответ мы получим allocate failure с 401 ошибкой. В таком случае необходимо будет повторить allocation request с указанием имени пользователя и атрибута Message Integrity, генерируемого на основании самого сообщения, имени пользователя, пароля и атрибута realm, взятого из полученного от сервера ответа.
4. Далее сервер в случае успешной регистрации присылает allocate success response с атрибутом выделенного порта на TURN-сервере, а также XOR-MAPPED-ADDRESS – тем самым публичным endpoint’ом на TCP протоколе. Для дальнейшей работы с IP каждый октет надо «заксорить» (XOR — операция логического исключения ИЛИ) аналогичным байтом из константного атрибута MagicCookie: 0x21 0x12 0xA4 0x42
5. В случае дальнейшей работой с этим TURN соединением необходимо каждый раз продлять регистрацию, отправляя refresh request. Сделано это для отбрасывания «мертвых» коннектов.

Конечно, это сейчас кажется простым и понятным, но оглядываясь назад, когда смотришь в RFC и понимаешь, что без подсказок wireshark’а дальше дело не сдвинется с мертвой точки — готовишься к погружению в… В общем, вспоминается один бородатый анекдот:

Как установить соединение?

Самое простое – это организация UDP hole punch’а.
Для этого необходимо искусственно создать правила маршрутизации на своем NAT.

Достаточно просто организовать серию передачи пакетов на удаленный endpoint и дождаться от него ответ. Несколько пакетов необходимы для создания соответствующего правила на NAT’е и избавления от «гонки», кто кому первым доставит соответствующий пакет. Ну и потерю на UDP никто не отменял.

Далее обменялись контрольными фразами и можно считать, что соединение установлено.

Чуть-чуть сложнее – организация TCP hole punch, хотя общая идеология остается точно такой же.

Сложность заключается в том, что только 1 сокет по умолчанию может занимать свой локальный endpoint, а попытка подключения к другому адресу приведет к автоматическому разрыву соединения с первым. Однако существуют опции сокета, это ограничение снимающие: REUSE_ADDRESS и EXCLUSIVEADDRUSE. После взведения первой и сбрасывания второй опции на сокете другие сокеты смогут занимать тот же самый локальный endpoint.

Ну и остается сущий пустяк – забиндиться на локальный endpoint, открытый сокетом при коннекте с TURN’ом, ну и попытаться подключиться к endpoint’у удаленной стороны.

Ну и еще чуть сложнее, но не менее важная для стабильной установки соединения – ретрансляция трафика.

1. Т.к. регистрация на TURN’е у нас уже имеется, все, что нам необходимо – это добавить в разрешения на TURN’е регистрацию удаленной стороны. Для этого отправляем пакет CreatePermission с указанием удаленной регистрации.
2. Инициатор соединения отправляет пакет ConnectRequest с указанием «заксоренного» endpoint’а удаленной регистрации и подписывает пакет MessageIntegrity.
3. Если все хорошо и удаленная сторона отправляла CreatePermission с вашей регистрацией, то инициатору придет connect success response, а клиенту – connection attempt. И в том, и в другом случае во входящем пакете будет присутствовать атрибут connection-id.
4. Далее за непродолжительный промежуток времени необходимо новым сокетом подключиться к тому же IP и порту TURN сервера, что и первоначальный сокет (в классическом исполнении TURN сервера могут слушать как 3478, так и 443 tcp порты) и отправить пакет ConnectionBind с нового сокета с указанием connection-id, полученного ранее.
5. Дождаться пакета, содержащего connection bind success response, и вуаля – соединение установлено. При этом да, используется 2 сокета — управляющий, который отвечает за поддержание соединения, и транспортный, с которым можно работать как при прямом соединении – все, что будет отправлено или получено, должно обрабатываться как есть.

Почему мы унесли прямое udp на второе место?

Что ж, UDP при всей своей легкости и скорости обладает существенным недостатком: отсутствием гарантии доставки и очередности. И если с видеопотоком еще как-то с этим можно было бы смириться (наличие графических артефактов), то вот с передачей файлов тут несколько серьезней.

Для обеспечения гарантии и очередности был реализован механизм, схожий с reliable UDP, который да, потребляет несколько больше ресурсов, но и дает желаемое.
Как же мы вышли из ситуации? Для начала необходимо узнать MTU (maximum transmission unit) – то есть максимально большой размер udp пакета, который может быть отправлен без фрагментирования на проходящих узлах.

Для этого принимаем за максимальный размер пакета 512 байт и выставляем сокету опцию IP_DONTFRAGMENT. Отправляем пакет и ждем его подтверждения. Если в течение фиксированного времени мы получили ответ, то увеличиваем максимальный размер и повторяем итерацию. Если же в конечном итоге подтверждения мы не дождались, то начинаем процедуру уточнения размера MTU: начинаем не существенно понижать максимальный размер блока и ожидаем стабильного подтверждения в течение 10 раз. Не получили подтверждение – снизили MTU и по новой запускаем цикл.
Оптимальный размер MTU найден.

Далее проводим сегментирование: нарезаем весь большой блок на множество маленьких с указанием начального номера сегмента и конечного номера сегмента, характеризующего пакет. После разбиения добавляем сегменты в очередь отправки. Отправка сегмента производится до тех пор, пока удаленная сторона не сообщит нам о том, что получила его. Интервал повторной отправки используем как 1.2*максимальный размер ping’а, полученного при нахождении MTU.
На принимающей стороне смотрим полученный сегмент, добавляем во входящую очередь и пробуем собрать ближайший пакет. Если получилось – чистим очередь и пробуем собрать следующий.

Тут, конечно, самые внимательные из вас, кто «дожил» до этого абзаца, могут смело заметить: а почему не использовать кодек x264 или x265? — и будут частично правы. Честно говоря, мы тоже склонны его заюзать, тогда можно поступиться этим велосипедом на udp. Но как быть, скажем, с передачей бинарных файлов? В этом случае мы опять возвращаемся к необходимости гарантии доставки и очередности пакетов.

В заключение хочется отметить, что с такой организацией подключений мы имеем не более 2-3% несостоявшихся подключений в день, большую часть из которых составляют неверные настройки прокси или файрвола, настроив которые соединение осуществляется без проблем.

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