Вероятно, вы путаете порт источника клиента и порт источника сервера. Порт источника сервера при ответных пакетах будет 5900, если сервер работает на этом порту.
meDveD_spb, я не знаю, как работает zerotier, но полагаю, что он устанавливает прямые соединения, если это возможно, соответственно не маршрутизирует весь трафик через сервер.
Почему вы задаёте этот вопрос сюда, на площадку общих вопросов и ответов, а не производителю ноутбука, который его спроектировал и имеет исчерпывающую информацию о его функциональности?
Ваш ноутбук, судя по информации в интернете, не имеет выхода DisplayPort через USB type C.
meDveD_spb, это не то, что нужно. Автор хочет установить прямые соединения клиент-клиент, не маршрутизирутизируя трафик через сервер вообще (в физическом, а не логическом смысле).
возможно ли настроить сервер\клиентов так, чтобы при общении клиентов миновался сервер и задержки связанные с ним?
По-моему, вопрос поставлен понятно и однозначно. Опция client-to-client автору не поможет, она не уменьшит задержки.
meDveD_spb, топикстартер спрашивает про маршрутизацию между клиентами напрямую, минуя сервер. Опция client-to-client никак не меняет сетевую маршрутизацию трафика (все пакеты всё равно будут маршрутизироваться через сервер OpenVPN, создавая задержку и уменьшая скорость), просто их обработка будет выполняться самим openvpn-демоном, а не ядром ОС.
meDveD_spb, опция, отключающая отправку пакетов от клиента другому клиенту через сетевые подсистемы ядра операционной системы. Пакеты от клиента к клиенту будут маршрутизироваться средствами самого openvpn-сервера, а не netfilter.
sh_023, можно, OpenWRT позволяет реализовать схемы подключения гибко, любой сложности.
Назначте отдельный vlan для порта Wi-Fi в меню switch, сконфигурируйте его соответствующим образом в интерфейсах, укажите правильную зону firewall.
Данил Тунев, не понимаю ваш вопрос. Клиентская программа получит пакет, как только он дойдёт до клиента и обработается ядром. Pacing актуален только на отправляющей стороне.
но а как же поступит ос если он придет не полностью: отбросит пакет?
Несмотря на то, что теоретически пакет может быть фрагментирован где-либо по пути, если он не помещается в MTU (и тогда приложение получит пакет либо целиком, либо никак, даже если до хоста дошел только один IP-фрагмент), практически в реальном интернете, скорее всего, никак она его не получит, если пакет не пролез в MTU где-либо на пути.
Shape0173, в вопросе нигде не сказано про адрес источника, и изначально я понял его буквально так, как он написан (словно автору нужно маршрутизировать трафик в локальные сети разных провайдеров, как это было в городских сетях двухтысячных, metropolitan area network), но, вероятно, вы правы, речь про адрес собственной локальной подсети, а не сети для маршрутизации.
В такой ситуации потребуется раздельные таблицы маршрутизации и правило для маршрутизации подсети источника через ту или иную таблицу. Маркировка пакетов была бы необходима при желании использовать один и тот же адрес для выхода через разные сети (балансировка трафика), либо для приёма входящих соединений через обоих провайдеров в случае проброса порта на устройство с одним локальным IP-адресом (а не двумя, на каждого провайдера), но с указанными условиями не вижу необходимости в маркировке пакетов или применения VRF.
Гарри, vrf точно не нужен для этой задачи, он придуман для другого — для изоляции.
Задача, как она поставлена в вопросе, решается без маркировки трафика.
не имея белого IP