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 точно не нужен для этой задачи, он придуман для другого — для изоляции.
Задача, как она поставлена в вопросе, решается без маркировки трафика.
XST, только что проверил — v2fly в режиме QUIC работает в Туркменистане.
Имейте в виду, что в Туркменистане также заблокированы большинство портов назначения. Используйте стандартные порты UDP, такие как 5060, например.
У Socks5 очень длинный хендшейк, что замедляет время от установки соединения с прокси до получения ответа. Используйте HTTP-прокси, у него хендшейк в 2 раза меньше для HTTPS и такой же, как обычный HTTP, для HTTP-трафика.
Либо используйте более специализированные протоколы. Shadowsocks пересылает все необходимые данные уже в первом пакете, например.
При раздаче на диск ничего не пишется. Чтение диск не убивает.
Частое чтение один и тех же областей также изнашивает память (создаёт дисбаланс уровней у соседних ячеек), но это далеко не столь большая проблема, если речь об SSD, а не об обычной NAND.
По-моему, вопрос поставлен понятно и однозначно. Опция client-to-client автору не поможет, она не уменьшит задержки.