AlexVWill

Scaleway

Поставить докер вручную через apt

Ядро сервера настроено на IP Forwarding?
cat /etc/sysctl.conf покажи.
Если там нет (или закомменчено) net.ipv4.ip_forward=1
то надо вставить (или раскомментить), и сделать ребут сервера.

адрес vpn-сервера прописывается в самой консол

Так это не работает, поскольку во первых IP адрес не прописывается, а выдаётся DHCP VPN сервера (в данном случае, есть случаи когда он принудительно пишется, но это другое) и маршрут через VPN сервер (IP сервера) идёт через VPN клиента с внутреннем IP, а во вторых IPшник VPN сервер выдает только при авторизации на VPN сервере, т.е. по сути на Xbox нужно ставить клиента VPN, который будет отвечать за авторизацию, маршрутизацию, шифрование и пр. Такого для Xbox я не видел,потому что пользователю на Xbox доступна только песочница для игр и контента, без доступа к системному ядру, а VPN клиен для реализации его задачи должен обладать доступом к системным функциям (например менять default gateway для маршрутизации пакетов).

Теоретически может. А вот делает ли - это можно понять только посмотрев сами настройки, какая маршрутизация, и что именно идёт через сервер работодателя.

А при чем тут VPN. Тебе нужен внешний хостинг, любой хостер, которых миллион. Ищи лучше те, что предлагают VPS, он же виртуальный сервер, с доступом к Linux. Так можно максимально полно и без ограничений со стороны провайдера реализовать то, что надо. Обычно в таком случае закрыт по умолчанию только 25 порт, но еша обычно же по запросу можно открыть.

Ты как раз его используешь законно, это государство незаконно ограничивает доступ к информации.

IP - > Firewall -> NAT пробросить порт 80/443 для подсети 192.168.206.0/24 до 192.168.206.121

/ip firewall nat
add chain=srcnat src-address=192.168.206.0/24 protocol=tcp dst-port=80 action=dst-nat to-address=192.168.206.121 to-ports=80 comment="HTTP Port Forwarding"

Команду по памяти писал, возможно надо поправить, но логика надеюсь ясна. Если конечно подсеть 192.168.206.* внутри VPN как я понял, а не DHCP самого микротика.

Megapolis05, для начала надо понять, где ширина канала падает, до или после сервера...
Поставь на сервер iperf3 и сделай замер от клиента до сервера... Если есть какой то еще сервер, процедуру повтори, до него, но уже через VPN. Так будут объективные данные и понятно станет на каком этапе происходит затык.
Ну и надо смотреть какой алгоритм шифрования стоит, используется ли сжатие пакетов и пр. В WG я не особо, но по аналогии с OpenVPN возможно там эти настройки стоит посмотреть и покрутить. На сервере запустить htop, замерить нагрузку на процессор и очень важно - на память. Поскольку памяти мало, то посмотреть насколько своп расходуется (кстати, какой размер свопа?). В общем универсального метода нет, все сильно зависит от разных факторов.

Рассчитываю на пользователей так 100 актуальных,

скорее всего все упрется в ширину канала, надо настраивать для пользователей ограничения (QoS, traffic control), чтобы особо активные пользователи работали только в рамках своих квот при нагруженном канале и не забивали его так, что остальным не хватает...

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

Никак... Провайдер обеспечивает тебе связь до удаленных хостов с прописанной в тарифном плане шириной канала. Если на всех тестовых хостах обеспечена нужная ширина - провайдеру на то, что какой то хост тормозит будет глубоко наплевать, это дескать "не наша проблема". Тем более если это по вине РКН, если он тормозит пакеты RDP.
Можно конечно остановить RDP, повесить на его порт Iperf3 и замерить ширину канала от твоей машины до хоста, и если она формально ниже тарифа - показать провайдеру, но скорее всего это ничего не даст. Да и там скорее всего просто пинг будет большой, формально работает, а де факто жутко тормозит.

де можно найти VDS для VPN с провайдерским ip?

у провайдеров

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Sstpsvc­\parameters
параметр типа DWORD с именем NoCertRevocationCheck. Присвойте параметру значение 1.

Как бы мог я это сделать?

Никак.

SSTP может помочь тоже, поскольку (если в простых словах) он работает на 443 порту, через TCP и по сути похож очень на обычный https трафик.
Также вполне неплохо справляется AnyConnect c маскировкой, сервер которого OCServ притворяется обычным WEB сервером. Короче, способы есть.
Эти два решения настоящие VPN в отличии от VLESS (который по сути прокся), т.е. позволяют делать всякое, вроде подключения через сертификаты, с проверкой сертификатов пользователя и сервера, разграничения доступов по подсетям, пушинг маршрутов, проксирование (например для выхода в зарубежный VPN через местный VPN с одновременным доступом к ресурсам локальной и удаленной сети) и всякое такое. Если этого всего не надо, то и забей, VLESS вполне подойдет.

Любой Mikrotik это умеет делать из коробки без перепрошивок и всяких танцев с бубном. Бери тот, что в бюджет уложится.

Потому что Google определяет местоположения не только по IP но и по другим параметрам. И если при входе с этого IP он ранее уже определил местоположение как РФ, то в следующий раз он может это учитывать, и ставить местоположение для соединения руководствуясь прежними данными не считаясь с тем, к какой стране относится IP. В Google тоже слышали про VPN и понимают что не всегда по IP можно верно определить фактическое место нахождения пользователя.

Для web сервера на Apache можно сделать авторизацию по паролю...
https://www.digitalocean.com/community/tutorials/h...
Или по сертификату + паролю.
https://stuff-things.net/2015/09/28/configuring-ap...
Доступ по IP не является способом авторизации, а лишь способом ограничения доступа...
Если всеже надо именно ограничение по IP, то это делается указанием нужного IP в конфиге виртуального хостинга. Вот тут https://www.8host.com/blog/sozdanie-intraseti-s-po... примерно похожая задача решается, если я правильно понял задуманное.

Нужен VPN сервер на VPS, расположенном на территории России, для доступа к домашнему роутеру из вне

Для этого не нужен VPS, достаточно получить статический IP и поднять на роутере или домашней машине VPN сервер. Из протоколов, которые не блочатся пока это SSTP и IPSec (второй как то блочили, но, видно у РКН закончилось помутнение рассудка, и теперь он опять работает).
Вообще, при наличии статического IP и VPN не нужен для указанной задачи, просто он повышает сильно безопасность. А при наличии просто белого не статического IP (от РТК к примеру) можно вообще обойтись тем, что есть, подняв на роутере какой то DynamicDNS клиент.

как исправить этот пробел в безопасности

Никак... В озвученной постановке вопроса. Потому как даже промежуточные прокси и VPN не спасут ОРД, потому как всю цепочку при большом желании можно открутить назад.
Вообще, надо понять что в данном случает понимается под "пробел в безопасности". Сетевая безопасность от вторжения извне и взлома системы к этой ситуации не имеет прямого отношения.
Если говорить про безнаказанность в ситуации при совершения какого либо правонарушения (морально-этическую сторону оставляем за скобками), то творить всякое со своей VPS (особенно если она зарегистрирована на реального пользователя) в любом случае крайне не рекомендуется, для этого есть более другие инструменты вроде ТОR или I2P.