res2001

Есть смысл не расширять маску, а наоборот разбить сеть на несколько меньших сетей и настроить между ними маршрутизацию. Сетей может быть несколько, при этом каждую из них не делайте меньше 24. Таким образом останется адресное пространство для расширения в каждой отдельно взятой сети.

TLS Error: TLS key negotiation failed to occur within 60 seconds

Произошел разрыв соединения из-за таймаута ожидания ответа от сервера.
Скорее всего сервер по указанному протоколу/адресу/порту не доступен или трафик блокируется фаерволом.
Если в это же время посмотреть логи сервера, то там, скорее всего не будет никаких признаков входящего клиентского соединения.

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

Судя по всему у вас используется протокол TCP, для проверки доступности сервера можете использовать telnet. Если телнет подключиться - значит сервер доступен по адресу/порту.

1. Маршрутизаторов может быть много. Например, сеть большого предприятия, где используется несколько подсетей + доступ в интернет. На какой именно маршрутизатор должен отправлять пакет хост, предназначенный не для своей сети?
2. Маршрутизаторы добавляются в систему то же через таблицу маршрутизации. Для шлюза по умолчанию в таблице маршрутизации добавляется маршрут для сети 0.0.0.0 (т.е. все адреса).

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

Для работы веба в большинстве случаев достаточно:
1. DNS: UDP, dst=any:53
2. HTTP/HTTPS: TCP, dst=any:443/80

DNS нужен, чтоб преобразовывать имена доменов в IP адреса.

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

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

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

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

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

Вы с другом находитесь в одном городе?
Если да, то, по идее, вы находитесь в одной провайдерской сети. Задержки должны быть минимальными при доступе друг к другу.

Сделайте traceroute (tracert/mtr) с обоих компов друг к другу, сравните вывод, посмотрите через какие адреса проходит трафик в обоих случаях. Где происходят самые большие задержки. В нормальном состоянии трафик должен идти через одни и те же промежуточные хосты и даже может не выходить за пределы провайдерской сети. Если набор промежуточных хостов сильно различается, то возможно провайдер криво маршрутизирует трафик и он в одном из случае идет по какому-то не оптимальному маршруту. Если на одном из узлов с одной стороны задержки приемлемые, а с другой высокие - явно что-то не то с этим узлом.
Можно звонить в поддержку и попытаться объяснить ситуацию, давя на проведенное вами исследование. Как минимум пожаловаться на неадекватные задержки внутри провайдерской сети.

Для большей достоверности traceroute стоит запустить несколько раз, получить несколько показаний тестов и усреднить их.

Надо "разлогиниться" и залогинится пользователем 2.

443 и 80 используются веб серверами (HTTP(S)), и это TCP. Тут UDP не используется.
53 - это DNS запросы, могут быть как UDP (по умолчанию) так и TCP.

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

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

При прямых руках можно и RDP выпустить наружу без дополнительных прослоек в виде ВПН. Но это надо делать на серверной винде с поднятой службой RDS, на десктопе скорее всего полностью обезопасить RDP подключение не выйдет.
Вот тут статья о защите RDP. Она хоть и старая уже, но принципы те же.
Еще несколько полезных статей:
https://winitpro.ru/index.php/2022/02/17/ustanovka...
https://winitpro.ru/index.php/2019/12/17/rdp-tls-s...
https://winitpro.ru/index.php/2022/03/17/nastrojka...

Проблема, видимо, в том, что при подключении ВПН клиента шлюзом по умолчанию становится ВПН-сервер, к которому подключается ВПН клиент. Нужно убрать это поведение (опция push "redirect-gateway def1" в конфиге ВПН сервера 10.36.0.1).
В целом, не вижу проблем, что бы клиент и сервер работали параллельно на одном компе, если они оба не будут трогать настройки шлюза по умолчанию. Скорее всего для правильной маршрутизации трафика придется добавлять статические маршруты или прописывать правила фаервола, перенаправляющие определенный трафик в нужный интерфейс.

Если смотреть только на Ethernet, то он представляет плоскую сеть, где все узлы равноправны и могут обмениваться трафиком друг с другом на прямую без всякой маршрутизации. Ethernet ничего не знает о других сетях. Для него есть только одна сеть.
Поэтому для взаимодействия между разными сетями нужен более высокоуровневый протокол, который позволяет отличить адреса "своей" сети, от "чужих" адресов (обеспечивает маршрутизацию между сетями). Это IP. Датаграммы IP вкладываются в поле данных Ethernet.
Над IP есть TCP и UDP. TCP гарантирует доставку пакетов, UDP - не гарантирует. Общее между ними то, что оба протокола позволяют идентифицировать конечные приложения на хосте получателя и отправителя по номерам портов. Сам по себе IP не позволяет этого делать, для него конечной точкой является хост в сети, средств идентификации приложений внутри хоста в IP нет. TCP и UDP пакеты вкладываются в поле данных IP пакета.
Ну и далее поверх TCP и UDP куча прикладных протоколов, которые решают какие-то специфические задачи. Эти прикладные протоколы точно так же вкладываются в поле данных протоколов TCP или UDP.

И нет никакой конвертации и преобразования, просто пакет вышележащего протокола является данными для пакета нижележащего протокола (инкапсуляция). Про инкапсуляцию смотри аналогию CityCat4 о картошке.

Широковещательные пакеты (а пакет WOL широковещательный) не маршрутизируются между сетями.
Для обхода этого ограничения можно поднять NAT на ВПН интерфейсе ВПН сервера и сделать проброс UDP пакетов на WOL порту на широковещательный адрес подсети.
В программе отправки WOL пакета соответственно надо указывать ВПН адрес ВПН сервера.
По такой схеме работает "WOL over Internet". Именно для такого варианта предназначена опция "Internet" в вашей программе, но она требует поддержки со стороны NATа.

Гораздо проще реализовать какой-то вариант удаленного запуска программы, отправляющей WOL с компа в сети. Для этого надо найти утилиту командной строки, которая умеет в WOL ну и вызвать ее удаленно с соответствующими параметрами.

NAT не обязательно стоит у провайдера, он может быть у тебя дома на роутере и т.п. И оператор динамически вполне может раздавать белые адреса на твой роутер, а роутер уже будет раздавать серые адреса внутрь домашней сети.

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

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

Узнать другие адреса "по умолчанию" сервер не может, т.к. браузер не предоставляет такой возможности. Но с помощью плагинов и т.п., думаю, можно что-то придумать, но тут уже без помощи пользователя не обойтись (ведь плагин надо сначала установить).
Можно узнать, например, версию браузера, какая ОС используется и много чего еще. В интернете полно ресурсов, которые показывают, что получилось достать из вашего браузера.

Кстати, если используется IPv6, то высока вероятность, что прямо на компе используется белый адрес. Тут адресного пространства хватает, чтоб выдать белый адрес каждой блохе. Так что NAT не нужен.

Почему у вас маска в локальной сети 8? Если бы вам это было нужно, вы бы тут такие вопросы не задавали. Сделайте маску локалки адекватной (24 я думаю вам хватит) и все WAN интерфейсы станут действительно WAN, а не частью локальной сети.