ky0

Мне лень гуглить ваш хуавей, но если это именно коммутатор - наличие IP-адреса на интерфейсе не даёт вам автоматически возможности что-то маршрутизировать, для этого нужна магия третьего уровня.

Скорее всего, через впн просто данные идут по менее загруженному или оснащённому более производительным железом маршруту. То, что написано по ссылке - больше похоже на маркетинг.

Попробуйте любой другой впн с тем же географическим расположением серверов.

P.S. - как это "потери пакетов есть, но mtr их не показывает"?

Это делается не прокидыванием портов "с адреса VPS", а банальной настройкой VPNа - чтобы оба устройства, между которыми нужна передача данных, оказались в одной сети. Берите любой гайд с Хабра, хоть OpenVPN, хоть Wireguard.

Зачем вам мониторить открытость UDP-порта? Проверяйте работоспособность сервиса, который слушает этот порт - наличие запущенного процесса, корректный ответ на тестовый запрос и т. д.

А проблема-то в чём? По умолчанию OVPN слушает все интерфейсы, если проброс портов настроен нормально, всё будет работать. Если же наоборот хотите, чтобы работало только через один из интерфейсов - не открывайте на втором порт, вот и всё.

Что показывает подключение в verbose-режиме? Часто права на файл/каталог ~/.ssh ставят неверные, поэтому ключ не используется.

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

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

Очень популярный на Тостере вопрос, проистекающий из изначально неверной архитектуры.

Вы говорите "один сервер ведущий, второй - ведомый", но правильно было бы сделать один (ну или несколько - для балансировки) сервер, проксирующий запросы и отвечающий за HTTPS-взаимодействие и выпуск сертификатов, и несколько - для отдельных доменов/сайтов. Такая схема (в особенности - в сочетании с виртуализацией) гранулирует сервисы и делает инфраструктуру более гибкой и проще администрируемой.

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

Думал что разделив все устройства на под сети(отдельные вланы),изолировав их друг от друга,а так же прописав на роутере органичения по интернету я смогу спокойно гонять локальный трафик внутри свитча L2

Разумеется, нет - всё, что уезжает за пределы локальной подсети, отправляется через промежуточный узел, то есть мы попадаем на третий уровень.

Да-да, вы совершенно правы - "пробросьте порт, настройте маршрут".

Специфика Тостера такова, что содержательный ответ обычно получает конкретный вопрос. А у вас не вопрос, а задание, для решения которого потребуется несколько телодвижений. И получается, что либы мы описываем вам всё досконально (без гарантии успеха с первого раза), либо вы приходите переспрашивать, споткнувшись на одной из ступеней. Оно нам надо?

Поэтому да - "пробросьте порт или настройте маршрутизацию". Мануалов по схожим задачам в интернете куча.

Зависит от конкретной реализации. Обычно никто не заморачивается, потому что у UDP-записей относительно небольшой (десятки секунд или минуты) срок жизни. Если за этот период данных нет - прибивается.

Настроить форвард пакетов с маскарадингом между eth0 и wlan0 для нужных адресов и маршрутизацию на роутере.

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

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

Некоторые провайдеры (особенно с ADSL) так настраивают своё оборудование - добавляя на него 1.1.1.1 или какой-нибудь 1.2.3.4. Я бы на вашем месте, если нет доступа к роутеру, обратился в саппорт.

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

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