Это странно, по идее это разные подсети и они в любом случае уходят на уровень софтового роутера, а не разрешаются на l2 уровне бриджа. Уверены, что нет никаких других правил по которым мог бы пройти данный трафик?
Сами VLAN порты у вас в бридж включены? Скиньте настройки vlan, хотя бы скринами.
Это достаточно сложно и требует хорошего понимания маршрутизации и работы ipsec.
Рекомендую вам упростить схему и добавить к ipsec туннельный протокол реализующий интерфейс, например ipip или gre.
Тогда ipsec у вас будет защищать именно не защищенный туннельный трафик, а все вокруг вы реализуете уже стандартными методами.
0UTS1D3R, в том смысле, что подобные компании продают вашу экспертизу, у вас её нет. Значит они или приставляют к вам ментора, который за вас отвечает, но где они его на 3 дня в неделю возьмут и кого они оставшиеся четыре будут продавать, или продают того чего нет рассчитывая, что прокатит. Второй вариант говорит о том, что компания обманывает своих клиентов. И так не бывает, что компания клиентов старается обмануть, а с сотрудниками честна и прозрачна, это стиль мышления руководства и он проявляется в компании во всех аспектах.
ИМХО в ИТ войти без вложений в себя достаточно сложно, я бы вам рекомендовал попробовать обучение/стажировка в epam, прочитать пару книг, подтянуть python и английский до a2, и постараться попасть к ним на курс devops. Но надо понимать это примерно полгода-год без денег.
Резол по lan ip идет вне зависимости от метрик интерфейсов. Просто в DNS у вас прописан lan ip для целевого узла.
Когда вы lan отключаете, у вас dns становится недоступен и узел пытается резолвить имя через netbios, что у него судя по все успешно получается и трафик идет уже в прямой интерфейс.
Задержкой добавляемой цепочкой коммутаторов в большинстве сетей, в том числе корпоративных можно пренебречь. Для того чтобы получить дополнительную миллисекунду задержки вам потребуется от 20 до 200 устройств в цепочке.
Приведенные вами "правила" не существуют и я бы сказал являются вредными советами.
Кол-во портов коммутаторов и их кол-во в первую очередь определяются их размещением. Предельные же скорость достигаются подбором оборудования и схемой коммутации.
xr0m46, подключаемся к mikrotik, смотрим нагрузку на внешнем интерфейсе. После чего к нем по проводу подключаем ПК и запускаем любой speedtest или 4k youtube, если нагрузка на интерфейсе поднимается до заявленной провайдером( близкой ), значит бутылочное горлышко ниже.
Параллельно мониторим загрузку процессора на mikrotik, гипотетически может быть перегружен он.
На головном mirotik с белым адресом:
bridge - ip:192.168.11.1/24
шаблон ipsec policy между 192.168.11.1 и 192.168.11.0/24 в туннельном режиме.
На "клиентском mikrotik"
bridge -ip:192.168.11.2 network 192.168.11.1
ipsec policy между 192.168.11.1 и 192.168.11.2
там же прописываем при с публичным ip головного mikrotik.
Клиентский mikrotik подключает к головному, устанавливает соединении.
На головном автоматически генерируется политика ipsec policy между 192.168.11.1 и 192.168.11.2 из шаблона.
Согласно политике весь трафик на 192.168.11.1 будет заворачиваться в ipsec туннель и пойдет на головной микротик, где будет развернут и передан на 192.168.11.1.
Удобство данной схемы, независимость от маршрутизации, публичных ip адресов клиентских mikrotik( они могу быть и серыми ) и вся настройка кроме одно пункта peer на клиентских устройствах не зависит больше ни от каких ip адресов и интерфейсов.
Пока с клиентского устройства есть маршрут до головного с публичным ip туннель поднимется( ну если конечно между ними не будет дропаться трафик )
Поскольку в ipsec нет интерфейсов, а это часто бывает не очень удобно, хотя по большому счету можно и без них, на чистой маршрутизации, на 192.168.11.1 - 192.168.11.2 вешает ipip туннель.
Но qos как хочется у меня пока так и не получился. Единственный вариант который вроде может получится это через dscp метки, они вроде как сохраняются при "переходе" из обычного трафика в ipsec и обратно.
Скорее всего все же верну обратно два туннеля и будут метить трафик через ipip интерфейсы.
Да. По вашему замечанию peers это точки куда подключатся, а не точки между которыми шифруется трафик. Шифрование определяется политикой, а политика используется при подключении к определенному peer.
Схему прохождения пакетов я знаю и как qos настраивается тоже.
Какие именно два набора понадобятся, можете привести пример?
Для конкретики
wan1 - 192.168.8.2
wan2 - 192.168.9.2
ipsec bridge - 192.168.11.5 на одном конце и 192.168.11.1 на другом( в качестве peer публичный адрес второго маршрутизатора ).
ipip туннель с 192.168.11.5 на 192.168.11.1, адреса 192.168.15.5 на одном конце и 192.168.15.1 на другом.
Нужно по разному разметить ipip трафик в случае когда ipsec пошел через разные wan интерфейсы.