asmelnik

Что происходит с тегированным кадром если он приходит на неуправляемый свич?

В 99.9% случаев такой кадр будет скоммутирован как обычный.
Исключения:
у вас древняя Cisco, которая отправляет кадры в своем собственном формате.
Или довольно редкий и древний неуправляемый зверь с коммутацией store-and-forward и максимальным размером фрейма менее 1522 байт.
или управляемый в конфигурации по умолчанию, но вы о нем не знаете, что он управляемый.
Есть еще более редкие вариации.

И можно ли построить VLAN если промежуточные свичи неуправляемые?

В большинстве случаев можно, но не нужно.
Т.к. ЛЮБОЙ подключенный к неуправляемому коммутатору имеет возможность "влезть" в ваш VLAN, а вы и знать ничего не будете...

1. Убрать маркировку,
2. Убрать NAT по маркировке, и сделать NAT по src 10.100.0.0.24

Это пропробуйте убрать.

/ip firewall mangle
add action=mark-routing chain=prerouting comment=\
    "Rule to forward all SSTP traffic to OpenVPN server" new-routing-mark=\
    OpenVPN passthrough=yes src-address=10.100.0.0/24

А вот это

/ip firewall nat
add action=masquerade chain=srcnat comment=\
    "SSTP forwarding to OpenVPN masquerade rule" out-interface=VPS4OpenVPN \
    routing-mark=OpenVPN src-address=10.100.0.0/24

поменять на

/ip firewall nat
add action=masquerade chain=srcnat  out-interface=VPS4OpenVPN src-address=10.100.0.0/24

Хотя есть одно но, пока устройство не в домашней сети, то все работает, но как только заходим в сеть через WiFi, то девайс получает IP по DHCP из внутреннего пула, и правило не работает.

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

Вот, собственно.
https://mum.mikrotik.com/presentations/RU17M/prese...
Что у вас скорее всего было сделано (насколько я понимаю)
т.е. у вас был создан в микротике "виртуальный мини микротик" у которого 2 интерфейса - VPN к буржуям, и VPN для подключения.

Если ИП статикой -- то весь инет для этого ИП скорее всего или пойдет через ВПН, или в ВПН вообще не попадет.
Могу и ошибаться, конечно.

Например я вел, но не по системному, а сетевому
В чистом виде был Cisco ICND1/2
Тут многое зависит например от сроков и целей курсов,
Общее представление за 2-3 занятия это одно.
3-4 месяца по 3-4 раза в неделю это другое.
И уклон в какую сторону?

Итог:
Судя по количеству подписавшихся на вопрос -- вопрос явно вызвал интерес, судя по полному отсутствию ответов и комментариев -- подобную статистику не ведут.
Этот же вопрос задан на https://forum.nginx.org
Но там ответов тоже пока нет.

Кому интересно подробнее -- можете почитать ветку
https://forum.nginx.org/read.php?21,298858,298858#...
Спасибо за внимание.

На 192.168.1.1 надо прописать маршрут к сети 192.168.20.0/24 через 192.168.1.11
И у всех в сети 192.168.20.0/24 шлюзом должен быть 192.168.20.1
И у Вашего L3 коммутатора, который 192.168.1.11, шлюзом должен быть 192.168.1.1

И да, могут быть на 192.168.1.1 приколы, связанные с icmp redirect...
Т.к. у вас пакет из 192.168.1.0/24 для 192.168.20.0/24 шлюз 192.168.1.1 должен отправить в тот же интерфейс, с которого принял. А в IPv4 на этот счет есть отдельные заморочки.

Такая проблема "рулится" легко.
Итерация 1-- путь запросов в инет:
1) есть ли шлюз у хоста? Доступен ли он?
2) на шлюзе хоста >=2 интерфейса? шлюз "смотрит" в какой интерфейс? Доступен ли щлюз?
3) повторяем 2) для следующего шлюза пока до выхода в инет не дойдем.

Итерация 2 -- путь ответов из инета:
1) знает ли инетовский шлюз, что сеть "хоста" (в вашем случае VLAN20) где-то есть?если нет -- прописываем маршрут, если да -- доступен ли шлюз для этой сети и идем на него.
2) Знает ли следующий шлюз о сети "хоста" (в вашем случае VLAN20)? если нет -- прописываем маршрут, если да -- доступен ли шлюз для этой сети и идем на него. ... повторяем 2), пока не дойдем до самого "хоста"

IP -- он не симметричен, каждый маршрутизатор принимает самостоятельное решение куда отправить пакет исключительно опираясь на адрес назначения (по классике, иное настраивается отдельно для особых случаев).
Есть отдельный путь "туда", и совершенно независимый "обратно", автоматического "туда-обратно" в IP НЕ ПРЕДУСМОТРЕНО от слова "совсем".

Практически любой современный физический интерфейс на компьютере --ПОСЛЕДОВАТЕЛЬНЫЙ: USB, Ethernet (100/1000/2500/5000/10000 Мбит), PON, SATA... (параллельные LPT и IDE(PATA) давно сошли со сцены)
Т.е. сколько физически (Но не логически) интерфейсов вы задействуете, столько и получите одновременных потоков.
При этом если USB -- то это шина, т.е.в каждый момент времени только одно устройство передает данные. И сколько бы вы устройств на одну шину не повесили -- физически это один поток данных.
Если что-то хотите передавать в сеть в реальные 16 или 32 потока -- вам надо соответствующее количество физических интерфейсов.
Но возникает вопрос "зачем"??
Не просто так от параллельных интерфейсов перешли на последовательные :)