ValdikSS

Речь про VPN, перенаправляющий трафик (устанаилвающий маршрут по умолчанию)?
Настройте соединения так, чтобы они не перезаписывали, а добавляли маршруты, с метрикой маршрута выше основного соединения — так у вас не будет маршрутизироваться трафик через VPN по умолчанию.
Каждую отдельную программу настройте на использование (bind) конкретного интерфейса VPN — таким образом вы сможете маршрутизировать трафик через необходимый интерфейс.

Установите пакет xtables-addons-common (или аналогичный в вашем дистрибутиве) и настройте модуль ipp2p на блокировку Bittorrent-трафика:
iptables -A FORWARD -m ipp2p --bit -j DROP

Он несколько старенький, но умеет блокировать и классический Bittorrent, и DHT, но насчёт µTP не уверен. Он точно не блокирует обфусцированный TCP Bittorrent.

Для StrongSwan (IPsec-сервер и клиент) есть, например, https://github.com/m-barthelemy/vpn-webauth
Сторонние методы аутентификации можно приделать почти к любому протоколу и серверу, а уже в них реализовывать проверку доп. факторов.

Если оба сервера (VPN и веб-сервер) ваши, то задачу можно решить IPsec IKEv2 в режиме без выдачи IP-адресов. На VPN-сервере добавятся специальные правила маршрутизации, которые маршрутизируют IP-адрес и порт клиента без подмены адреса.

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

Подключение перестаёт устанавливаться, потому что возникает асимметричная маршрутизация: ответный трафик с сервера до IP-адреса вашего компьютера начинает маршрутизироваться через VPN, с IP-адреса сервера VPN, а не адреса вашего сервера.
Пакет даже может дойти до вас (зависит от настроек VPN-сервера), но ваш компьютер не может связать запрос и ответ из-за несовпадения IP-адресов.

Необходимо настроить либо policy routing для каждого интерфейса (в особенности, для физического интерфейса сервера), либо настроить RDP-сервер на bind к физическому интерфейсу (и убедиться, что у вас сохраняется маршрут по умолчанию через не-VPN-интерфейс, но при этом имеет метрику выше).

• OpenVPN Access Server
  
• Pritunl
  

Все известные мне базы данных geoip ведутся коммерческими компаниями и основываются на разных данных. Обязанность провайдера — вписать правильную географическую информацию во whois-базы, но geoip-базы ведутся не только по whois-информации.

Соответственно факт, что страна сменилась, может означать, что сайт, на котором вы проверяете страну, использовал устаревшую базу одного из поставщиков geoip, и наконец обновил её, либо же сама база обновилась.
Проверить информацию во многих популярных базах можно, например, через https://www.iplocation.net/.

Интернет на устройствах перестаёт работать, потому что возникает асимметричная маршрутизация: ответный трафик с сервера до IP-адреса клиентов Wireguard начинает маршрутизироваться через NordVPN, с IP-адреса сервера NordVPN, а не адреса вашего сервера.

Необходимо настроить NAT в интерфейс NordVPN, если пакеты идут из интерфейса Wireguard, а также либо policy routing для каждого интерфейса (в особенности, для физического интерфейса сервера, на котором слушает Wireguard), либо настроить Wireguard на bind к физическому интерфейсу.

Вряд ли.

SSTP был разработан до внедрения WebSocket в HTTP, из-за чего использует странные подходы, которые не совместимы с HTTP-прокси/балансировщиками/терминаторами. SSTP сначала создаёт обычную HTTP-сессию, настраивает соединение, а затем это же соединение начинает использовать как сокет, с двусторонним обменом, что противоречит стандартам HTTP.
Чтобы, по-видимому, как предполагали авторы, указать веб-серверу, что соединение будет очень долгим, используется HTTP-заголовок Content-Length: 18446744073709551615 (2^64 - 1), что также создаёт проблемы, как минимум, с Apache и nginx.

Обычно, в случае IPv6, в другую сеть маршрутизируют целую подсеть. Для этого необходимо получить отдельную сеть от хостера, либо же разделить бо́льшую сеть (например, /56) на несколько меньших (например, /64), но эта сеть обязательно должна быть «заведена» на сервер в помощью маршрутизации, а не её назначением на интерфейс.

В вашем случае, полагаю, у вас всего одна /64-подсеть, из которой один из адресов уже назначен серверу. Это означает, что сеть назначена на интерфейс, а не настроена маршрутом на него. В этом случае оборудование хостера ожидает NDP-анонсы от каждого адреса (клиента). Необходимо настроить NDP proxy, либо тот, что встроен в Linux, либо отдельный демон на выбор: ndppd, ndp-proxy, ndproxy, autoneighxy.

Больше по теме:
https://www.geeklab.info/2013/05/ipv6-neighbour-proxy/
https://quantum5.ca/2019/03/08/ndp-proxy-route-ipv...
https://mkaczanowski.com/ndppd-ipv6-ndp-proxy/

А прямой ответ на вопрос «Как правильно выдать ipv6?» — запросить у хостера дополнительную подсеть/подсети нужного размера, смаршрутизированные на сервер, и смаршрутизировать их дальше в VPN штатными средствами, без NDP Proxy.

P.S. в OpenWRT встроен собственный отличный NDP Proxy, работающий из коробки и не требующий дополнительных настроек.

Самый надёжный вариант — установить на компьютере в виртуальной машине ОС-роутер (например, OpenWRT), подключив её в локальную сеть в режиме моста и настроив на ней маршрутизацию и VPN, а в игровой консоли указать адрес этой виртуальной машины в качестве IP-адрес шлюза.

Такой способ позволяет максимально гибко и совместимо настроить раздачу VPN на устройства, его не поддерживающие, без дополнительного оборудования.

Вам подойдёт буквально любой VPN.

Можно ли сделать так чтобы подключался впн (разницы нет какой), но TCP пакеты передавались через эти сервисы хранения?

Технически это возможно, конечно, но скорость, даже со всеми оптимизациями, будет сильно низкой. Подойдёт для получения новостей, но однозначно не для интерактивных сайтов.
VPN через почту будет еще медленней.