ValdikSS

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

Существуют адаптеры, поддерживающие 600 МГц Pixel Clock, с ними 1920×1080p будет работать на 240 Гц, 2560×1440 на 144 Гц.

Вот пример (почему-то заявлено 165@1080p): https://www.amazon.com/gp/product/B0752D33PJ/

Вам либо нужно настроить роутер-шлюз на маршрутизацию нужных вам VPN-подсетей через шлюз-VPN (тогда сам роутер-шлюз будет правильно маршрутизировать трафик внутрь VPN), либо в настройках DHCP-сервера локальной сети указать опцию 121 Classless Static Route, с указанием подсети VPN и адресом роутера VPN, чтобы клиенты знали о наличии VPN-шлюза в сети и сами маршрутизировали трафик на него.

Первое настраивается статическими правилами маршрутизации в самом роутере, второе настраивается опциями DHCP-сервера локальной сети. Настройка DHCP предпочтительней в плане скорости и нагрузки на роутер-шлюз.

Вот информация по чипсетам карт, а вот сами рекомендуемые карты.

Чаще всего это некий алгоритм обнаружения устройств сети, например, для их отображения в веб-интерфейсе.

Вот мой вопрос в тех. поддержку Keenetic, где происходило точно такое же, и их ответ:

¿А для чего нужна эта функция именно в такой реализации?

Чтобы оперативно менять статус подключенных клиентов при их отключении. Полное сканирование сети может занять очень много времени, например, если задать сеть с маской /16 или /8. Если оно не требуется, можно его отключить.

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

Советую отключать подобные функции, генерирующие большой «флуд» в сети, в особенности если интервал между сканированиями короткий — это всегда увеличивает энергопотребление устройств с батареями, они вынуждены отвечать на каждый ARP/NDP-запрос, даже в состоянии сна.

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

Отключите сканирование сети.
https://www.thewindowsclub.com/how-to-disable-back...

tar -cz /home/target | sshpass -p 'pwd' ssh -p 23 username@server.com 'cd /unpack/me/here && tar -zx'

Наиболее простой вариант для вашего случая (предотвратить доступ к данным, если диск вне вашего компьютера) — включить полнодисковое шифрование. В Windows достаточно активировать Bitlocker, если он у вас не включён, в режиме с TPM.
Ключ шифрования хранится в TPM: либо в отдельном чипе на вашей материнской плате, либо в чипсете. Диск вне вашего компьютера нельзя* расшифровать, а в вашем компьютере не придётся даже вводить пароль на запуск.

Современные процессоры шифруют AES скоростями в гигабайты в секунду. На моём Intel 1340p aes-xts выдаёт 7 ГБ/с, на i5-4570 — 2 ГБ/с.
С вашим SATA SSD (600 МБ/с макс.) расходы на шифрование не будут заметны, производительность не ухудшится.

ip route add default dev eth1 table 1000
ip route add ip.диапазон.для.gre dev gre0 table 1000
ip rule add from ip.диапазон.для.gre lookup 1000

как обьяснить клиенту, что сервер может быть по 2 адресам?

Добавьте две секции <connection> в конфигурационный файл, в каждой укажите свой remote.

Если вам нужно запускать x86-64-программы (юзерспейс), то вы можете установить ARM-версию Windows и запускать их через встроенный транслятор от Microsoft.
Образы ARM-версий доступны на официальном сайте Microsoft, либо же на сторонних сайтах вроде UUP dump.

Любой клиент, поддерживающий маршрутизацию по программам. Например, Windscribe. Не обязательно пользоваться сервисом, в него также можно загрузить свои конфиги.

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

Выходов несколько:
1. Добавлять IP-адреса доменов в момент резолва в лист маршрутизации VPN
Необходимо настроить DNS-сервер так, чтобы в момент запроса поддомена необходимых доменов (например, *.instagram.com) полученные IP-адреса добавлялись в список маршрутизации через VPN.
Это можно сделать, например, с помощью dnsmasq ipset.
Необходимо настроить маршрутизацию по списку ipset, а dnsmasq будет добавлять новые адреса, которые запрашивает пользователь, в этот список.

Недостаток способа заключается в необходимости использовать только DNS на роутере (DNS-over-HTTPS или любой сторонний резолвер не подойдёт — IP-адреса не будут добавляться в ipset и маршрутизации в VPN не будет), а также в том, что любой добавленный IP-адрес будет маршрутизирован в VPN: если два домена используют один и тот же IP-адрес, разделить их маршрутизацию не получится, оба будут маршрутизироваться через VPN.

В OpenWrt настраивается с помощью пакета pbr. Он не поддерживает регулярные выражения, как вы заметили, но они и не нужны: просто напишите любой домен, и словно это зона, все поддомены домена будут маршрутизированы в VPN. По-моему, pbr даже по-другому и не работает (нельзя маршрутизировать конкретный домен без его поддоменов).
Пример с доменами Netflix. Обнаружить все домены Instagram можно с помощью F12 - Network в браузере.

2. Обнаруживать домены в трафике, перемаршрутизировать через список маршрутизации VPN позже
Вариация первого метода с модулями вроде xt_tls, позволяющим обнаружить обращение к определённому домену из TLS-трафика, чтобы также добавить IP-адрес в ipset для маршрутизации в VPN.

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

В OpenWrt модуль отсутствует.

3. Терминировать трафик на «умный» прокси-сервер, который поддерживает маршрутизацию по доменам
Весь TCP/UDP-трафик перенаправляется на локальный прокси-сервер, способный выявлять домены прямо из трафика и маршрутизировать их в зависимости от правил. Примеры подобных прокси: v2fly, xray, sing-box, и др. (все есть в OpenWrt).

Недостаток метода в том, что весь трафик будет обрабатываться userspace-программой: на низкопроизводительных роутерах это может привести к серьезному замедлению, некоторые VoIP-программы не будут звонить (из-за несовпадения UDP-порта, который создала программа, и UDP-порта, который использует прокси), и поддерживаются только UDP и TCP, другие протоколы (ICMP, GRE, IPIP, что угодно) через такой прокси работать не будут.
Преимущество в лёгкой настройке и довольно стабильной работе.

Алгоритм определения доменов, необходимых для маршрутизации, не отличается от описанного в #1.

Вы уверены, что приложение работает именно так?
Обнаружение в приложении может выполняться либо каким-то собственным протоколом по Broadcast/multicast, либо стандартными, вроде mDNS/DNS-SD, через Multicast.
ARP вряд ли получится использовать именно для обнаружения, если это, конечно, не единичное особое устройство, где производитель заранее знает MAC-адрес.

OpenVPN tun тунеллирует только L3-трафик, поэтому не сможет маршрутизировать Ethernet ARP-пакеты (и любой другой Ethernet/L2 и IP broadcast-трафик). Для этого вам нужен туннель с поддержкой L2 — OpenVPN tap, как один из возможных.

Если речь об обычном смарт-ТВ и стандартных протоколах, то, скорее всего, речь всё-таки о multicast. Его поддерживает OpenVPN tun, нужно настраивать маршрутизацию мультикаст-трафика уже средствами самого роутера.
Некоторые программы могут намеренно устанавливать TTL=1 в пакетах, чтобы трафик не маршрутизировался в другие сети — вам необходимо увеличивать TTL у таких пакетов.

Более подробно понять принцип работы программы можно из дампов трафика. Они также помогут диагностировать проблемы с его прохождением через VPN.

Всё зависит от вашего местоположения, от связности вашего провайдера, от ширины его каналов, от стыков, на каких присутствуют интересующие вас провайдеры.

Я обычно делаю так:

• Заходим на https://looking.house/points.php, ищем наиболее географически близкие страны/города
  
• Пингуем тестовые адреса интересующих провайдеров, смотрим трассировку
  
• Смотрим трассировку с серверов на свой IP-адрес
  
• Берём сервер, где ниже пинги и шире каналы