hint000

очевидно как то надо на роутере в А разрешить трафик из vpn в wan. и чтоб там ещё nat накладывался. и это вот самый непонятный момент

С этим как раз вообще никаких сложностей, тут всё сразу работает (если роутер нормальный, без глупых искусственных ограничений).
Все сложности настройки (их не так уж много) сосредоточены на Б. И они гуглятся по словам "policy routing".

1.

Как я понимаю в первых двух строчках 0.0.0.0 это два шлюза по умолчанию а маска 128 делит всю wan сеть пополам?

Да, почти. Строго говоря, 0.0.0.0/128.0.0.0 не считается "по умолчанию". Только маршрут с маской 0.0.0.0 - настоящий "по умолчанию". Но для простоты можно не придираться и сказать так.

И пакеты летят то на первый интерфейс, то на другой?

Да, в зависимости от адреса назначения. Что в общем случае неправильно (иногда бывает, что именно так задумано, но это не ваш случай). Исправьте на 0.0.0.0.
2.

Есть ли способ быстро переключаться между двумя подключениями на винде?

Да, та самая команда route, через которую (route print) вы показали маршруты.
route /? выводит подсказку, там внизу есть примеры:
route add для добавления маршрута,
route delete для удаления маршрута,
route change для изменения.
Можно не добавляя и не удаляя только менять метрику. Когда есть два (и больше) маршрута с одинаковым адресом назначения и одинаковой маской, то работает маршрут с меньшей метрикой. В вашем примере метрика не срабатывала из-за разной маски. Маршрут с узкой маской имеет приоритет перед маршрутом с широкой маской, независимо от метрики (в вашем случае с маской 128.0.0.0 маршрут был бы приоритетнее, даже имея метрику 26).

Это противоречит базовому принципу маршрутизации - шлюз должен быть в той же сети, либо шлюз должен быть доступен по протоколу точка-точка.
Но если в Proxmox организовать гостевую сеть через NAT, то сам гипервизор будет выступать шлюзом, а до внешнего шлюза трафик пойдёт уже с адресами, транслированными в другую сеть (ту, в которой шлюз).

Я так понимаю это из-за асимметричной маршрутизации на OPENWRT проблема

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

через раз загружает пол страницы и отваливается, хотя пинг стабильный

Главное подозрение на MTU. Читайте по любой ссылке из первого десятка в поиске:
https://www.google.com/search?q=windows+изменить+MTU
В двух словах и "на пальцах": не пролазят только пакеты большого размера; пингуете маленькими пакетами, они пролазят; некоторые пакеты при загрузке страницы тоже маленькие, они пролазят, а на первом же большом пакете затык. Параметр MTU говорит: не посылай пакеты больше указанного размера.

Настройки:
1. На роутере:
...
2. Со стороны клиента:
...
Ощущение, что где-то какую-то деталь забыл...

Есть третий участник процесса.
3. Со стороны сервера:
Шлюзом должен быть прописан 192.168.253.2, чтобы работало без NAT.
Ещё: если сервер виндовый, там по умолчанию штатный брандмауэр не пустит из другого сегмента сети.

Может быть и не связано с проблемой, но всё же процитирую свой ответ 2-летней давности https://qna.habr.com/q/1000141 (периодически напоминаю об этом, но, как обычно, всем пофиг).

Алиасы интерфейсов устарели.
https://www.kernel.org/doc/html/latest/networking/...

IP-aliases are an obsolete way to manage multiple IP-addresses/masks per interface. Newer tools such as iproute2 support multiple address/prefixes per interface, but aliases are still supported for backwards compatibility.

2014 год: Алиасы интерфейсов устарели. https://unix.stackexchange.com/questions/119592/su...

ens160:0 is also obsolete syntax. There is no more aliases usage. IP addresses are applied to the same interface (please see ip a s command output).

2007 год: Алиасы интерфейсов устарели.
https://linux.debian.user.narkive.com/jH7FZrwF/ip-...

The docs I'm reading recommend using "secondary ips" instead of aliases. It
says that IP Aliases are deprecated in favor of "secondary ips"

2007 год! 14 лет 16 лет назад нам говорили прекращать использовать IP-алиасы. 14 лет 16 лет назад, Карл!

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

А так поддерживаю ответ AUser0 как насчёт диагностики tcpdump-ом, так и версию насчёт MAC, который может иметь привязку на оборудовании провайдера (позвонить в техподдержку, спросить о наличии привязки, при её наличии попросить сбросить для x.x.x.211). Факт, что для x.x.x.212 всё работает правильно как бы очень сильно намекает в пользу привязки, которая у провайдера сработала автоматически при первом использовании x.x.x.212.

Кроме того, есть вариант настроить без использования NAT. Например, использовать обычный свитч, в который воткнуты .209 (провод от провайдера), .210, .211 (и .212, .213, .214 при необходимости).
Минус в децентрализации контроля трафика - при необходимости контролировать почту через iptables нужно использовать iptables на самом почтовом сервере. Разумеется, это вопрос администрирования (даже не вкусовщина и не предмет для споров). Что для одного админа здорово, то для другого админа - смерть. Просто технически такой вариант возможен.

Дык а вы проверяли, что они сейчас не видят друг друга?
По-моему, у Mikrotik'а хватает ума в таких простых случаях автоматически создавать маршруты, не требуя ручной настройки.

И если таки не видят, то смотрите, является ли Mikrotik шлюзом для тех хостов, на которых проверяете.

Цепочка INPUT определяет судьбу пакетов, которые предназначены самому хосту (серверу в вашем случае).
А движение пакетов, которые идут клиентам или от клиентов, регулируется цепочкой FORWARD.

Существуют ли способы узнать какие порты и протоколы пытается использовать какая-либо сущность в ос?

Есть старая команда netstat (кучу ключей, определяющих, что именно она показывает, смотрите в man netstat или в гугле). Есть более новая команда ss.

Понимаю, что зело костыльно, подписался, чтобы увидеть более изящное решение.

Не туда добавляете. Вроде русским языком написано: Перенаправление портов. Но вы зачем-то вместо этого пытаетесь прописать статическое резервирование адресов в DHCP. Хотя конечно, Tenda тот ещё хлам, и даже интерфейс они не смогли по-человечески сделать (совершенно разные функции лепят вплотную на одной странице).

пытаюсь добавить внешний ip, кидает ошибку

Внешний адрес прописывать тут вообще не нужно.

Посоветуйте пожалуйста куда копать

Копайте в сторону конфликта IP-адресов (выдаваемых по DHCP).
Например, когда 192.168.1.100 перестанет пинговать шлюз, то попробуйте со шлюза пинговать 192.168.1.100.
И с разных других компьютеров пинговать 192.168.1.100.
И если такой пинг пройдёт, то отключите (физически) 192.168.1.100 от сети и снова проверьте пинги до него с разных компов.
Вдруг обнаружите, что кто-то по этому адресу отвечает, даже когда комп отключен от сети.

Серьёзно? Wi-Fi роутер корпоративного уровня за 200 баксов рядом с антикварным dir-100. :)

потому что dir-100 часто зависает в таком режиме работы(помогает только питание вкл-откл)

Зависает dir-100 не из-за корявой схемы, а потому что ему давно место на свалке. (Почему не в музее? Как музейный экспонат он так себе, всё-таки на свалку.) Нет, я понимаю, после ядерной войны любой хлам будет представлять ценность, но мы пока до этого не дожили.

Про то, почему в локальной сети оказались белые адреса из США (штат Аризона) можно и не спрашивать. Ведь веризон рифмуется с Аризоной - вот поэтому.

Как эту схему упростить

Купите что-нибудь типа такого: https://market.yandex.ru/product--wi-fi-router-tp-...
и будет у вас одно устройство вместо цепочки из трёх.

Большинство инструкций описывают как настроить NAT, причем как правило с 2 сетевыми картами (что логично)

Не знаю, насколько это логично; стараюсь писать правила более универсально, не привязывая к интерфейсам без необходимости. Для вашего случая:

-A POSTROUTING -s 192.168.1.0/25 ! -d 192.168.1.0/25 -j MASQUERADE

Вешаем на один адаптер сервера 2 интерфейса - eth0, eth0:0. Первый интерфейс делаем 192.168.2.1/25. Добавляем второй интерфейс серверу eth0:0 и назначаем ему IP 192.168.1.128/25.

Алиасы интерфейсов устарели.
https://www.kernel.org/doc/html/latest/networking/...

IP-aliases are an obsolete way to manage multiple IP-addresses/masks per interface. Newer tools such as iproute2 support multiple address/prefixes per interface, but aliases are still supported for backwards compatibility.

2014 год: Алиасы интерфейсов устарели. https://unix.stackexchange.com/questions/119592/su...

ens160:0 is also obsolete syntax. There is no more aliases usage. IP addresses are applied to the same interface (please see ip a s command output).

2007 год: Алиасы интерфейсов устарели.
https://linux.debian.user.narkive.com/jH7FZrwF/ip-...

The docs I'm reading recommend using "secondary ips" instead of aliases. It
says that IP Aliases are deprecated in favor of "secondary ips"

2007 год! 14 лет назад нам говорили прекращать использовать IP-алиасы. 14 лет назад, Карл!

Схема подключения называется https://www.google.com/search?q=router-on-a-stick
Из недорогих управляемых коммутаторов можно взять такой 5-портовый https://mikrotik.com/product/RB260GS
или такой 8-портовый https://www.tp-link.com/ru/business-networking/eas... (с урезанными функциями, но VLAN есть). Никаких WAN у коммутатора нет, вам придётся самостоятельно заморочиться настройкой VLAN. Несколько проще будет настройка, если роутер воткнуть в коммутатор двумя сетевыми интерфейсами (5-портовый вариант отпадает), тогда сам роутер настраивается стандартно, только VLAN на коммутаторе.

Nginx обратный прокси.

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