res2001

Добавьте маршруты до адресов discordа через ВПН. А остальное пускайте на шлюз по умолчанию.
При подключении ВПН не должен переписывать шлюз по умолчанию.
Останется только выяснить адреса дискорда. В этом могут помочь сервисы whois.

1. В конфиге OpenVPN ВПН сервера добавить соответствующую опцию push route
2. На всех компах в сети (кроме ВПН сервера), к которым должен быть доступ из ВПН, добавить маршрут до ВПН подсети через ВПН сервер.

Самый надежный вариант - свой собственный ВПН.
Арендуйте VPS в интересующей вас стране, придется найти способ оплачивать услугу, настройте свой собственный ВПН и ходите через него. OpenVPN Или WireGuard настраиваются достаточно просто.

Вы описали сразу 2 проблемы:
1. Десктопная винда (это та что не серверная) она однопользовательская в принципе. Т.е. работа одновременно двух пользователей - это нарушение лицензии. А подключение RDP всегда пытается создать новую пользовательскую сессию для своего подключения. Поэтому винда автоматически выкидывает пользователя, который уже залогинен.
Можно использовать Windows Server там этой проблемы нет. Можно на десктопную винду поставить RDPWrapper, тогда поведение RDP сессии будет аналогично серверной винде, но это нарушение лицензии.
К тому же это не избавит вас от того, что новое RDP соединение будет пытаться создать новую сессию.

2. Есть режим RDP, когда вы подключаетесь к существующей сессии (консольной или RDP). Называется теневое подключение (Remote Desktop Shadowing). Но это требует дополнительной подготовки. Почитать можно, например, тут: https://domoticzfaq.ru/rds-shadow-tenevoye-podklyu...
Если вы используете только теневое подключение, то с RDPWrapper можно не заморачиваться.

Провайдер видит внешний адрес и порт ВПН клиента и внешний адрес и порт ВПН сервера. Эту информацию провайдер видит всегда, иначе пакеты не смогут передаваться по интернету.

На VPS настраиваете ВПН сервер.
ВПН клиенты можно настроить на роутерах на имеющихся или на новых. Можно на компах внутри сетей.
Настраиваете маршрутизацию и фаерволы.
Пользуетесь.

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

Все ВПН клиенты требуют той или иной конфигурации. Т.к. вы работаете с линуксом, то конфигурация находится в файлах. Была бы винда, был бы еще вариант конфигурации в реестре. Но в любом случае конфигурация будет.
Приведенная вами команда генерирует конфиг сама, а то и не один, не проверял. Ссылки на дополнительные скрипты, указанные в вашем скрипте сейчас не доступны. И это не РКН их блочит. Ссылки ведут на github, но github изменил стиль ссылок на raw файлы. В скрипте используются старые ссылки, которые сейчас не работают. Можете поправить ссылки вручную в скрипте при желании.
Этот скрипт мало того, что конфигурирует ВПН, он еще и устанавливает необходимые пакеты. Т.е. нормально так вмешивается в систему.
Родной github репозиторий вашего скрипта тут: https://github.com/hwdsl2/setup-ipsec-vpn
Там же лежат и другие скрипты, которые выкачиваются первым скриптом.

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

Все это актуально, когда вы используете доступ в интернет через ВПН. Но это необязательно так. Чаще всего ВПН настраивают для доступа, например к закрытым ресурсам организации, а весь интернет вы используете как обычно - на прямую без ВПН.

Создавайте туннель на отдельном компе, не на том, на котором крутится софт. И используйте его как шлюз для адресов, на которые ходит этот софт.

Можно ли задать адрес локальной сети в филиале 192.168.1.0?

Тут лучше начать с принципиального решения второй задачи. Ответа на нее я не знаю.
Но если вы хотите объединить сети в одну, то конечно в филиале надо использовать ту же подсеть, что и в головном офисе. Но как по мне - это плохая идея.

Так что лучше сети не объединять (в смысле ответа на второй вопрос) и использовать маршрутизацию вместо бриджа.
А значит, если вы в сети филиала будете использовать ту же подсеть, то получите кучу проблем с маршрутизацией, которые придется как-то решать.
Что бы в принципе избежать проблем - используйте другую подсеть.

чтобы потом можно было подключаться к этому VPN и выходить в интернет под разными IP.

ВПН отвечает за канал связи между ВПН клиентом и ВПН сервером. Куда дальше идет трафик - это уже не его дело. Этим занимается стандартная процедура маршрутизации с помощью настроек таблицы маршрутизации, так же могут вклиниваться в процесс правила фаервола.

Вы можете на ВПН сервере в фаерволе прописать правило для пакетов в интернет, полученных через ВПН, форвардить на определенный интерфейс. Это правило можете менять вручную скриптом или еще по каким-то условиям.
Другой вариант - можно настроить 32 ВПНа (по 1 на каждый внешний адрес), каждый ВПН будет иметь свою подсеть, в фаерволе точно так же прописываются 32 правила для форвардинга пакетов полученных от соответствующего ВПНа на его интерфейс. В этом случае выбор адреса происходит на стороне клиента (подключаетесь к нужному ВПНу).
Вместо 32 ВПНов, можно использовать 32 разных клиента в одном ВПНе с фиксированными адресами. Суть в том, что бы в правиле фаервола вы могли бы их отличать.

Все это теоретические рассуждения. Конкретная реализация будет сильно зависеть от выбранной ОС для ВПН сервера, выбранного типа ВПН, чего-то еще.

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

Реализовать ВПН достаточно просто. Проще всего купить уже готовый, сейчас это не сложно. Надо подобрать оператора ВПН, предоставляющего тип ВПН, который поддерживает ваш роутер.
Но надежней на мой взгляд поднять ВПН самому, это то же не сильно сложно. Для этого вам надо арендовать VPS с Linux, настроить там подходящий ВПН сервер. На роутере настраиваете ВПН клиент. В правилах маршрутизации роутера надо добавить маршрут до адресов брокера через ВПН сервер. Не делайте ВПН маршрутом по умолчанию, т.к. весь трафик пойдет через ВПН. Роутер должен подключать ВПН как по основному так и по резервному каналам.
При этом на компе и в QUIK не надо ничего делать - все будет для них прозрачно.
Выбирайте оператора VPS имеющего сервера в регионе нахождения брокера, так вы сможете несколько уменьшить задержки из-за ВПН. Где находится брокер можно узнать по geoip (он может врать) или спросить у брокера.

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