Ты в качестве шлюза (удалённой системы, на MAC-адрес которой мы должны слать пакетики, адресованные локально не известным IP) указал собственный интерфейс 10.2.0.1

@o01eg Я не знаю, что «должно быть». Я знаю, что все такие модельные ситуации решаются пошаговым разбором и пониманием, а не переключением кнопочек и перебором циферок в случайном порядке.

Сбрось всю тряхомудию, оставь самый простой вариант, когда никаких правил не задаётся и никаких шлюзов не назначается. У тебя будут:
— Интерфейс 192.168.1.5, которому передаются все пакеты, совпадающие с его адресом с учётом маски /24, и который пытается найти MAC-адрес назначения, чтобы передать туда данные через сетевую карту (реальную).
— Интерфейс 10.2.0.1, которому передаются все пакеты, совпадающие с его адресом с учётом маски /24, и который пытается найти MAC-адрес назначения, чтобы передать туда данные через сетевую карту (виртуальную).
Только после этого начинается собственно «роутинг», то есть отправка пакетов с адресами не из локальных подсетей на специально заданные MAC-адреса, получаемые из IP-адресов, заданных как «шлюз» для каких-то (или всех) диапазонов. Например, 192.168.1.1.

Пакеты на 10.2.0.3 не будут идти ни на какой шлюз, для них будет делаться ARP-запрос, после чего 10.2.0.3 получит пакет со своим MAC и своим IP, как находящийся в локалочке (реальной или виртуальной). Никаких записей в таблице (кроме автоматически упоминаемых здесь как «on-link») для них не требуется, если всё работает, как должно быть. То есть, первая строчка (которой ты хотел выразить «дефолтный шлюз через 10.2.0.1», что не имеет смысла — пакеты надо отправлять «куда-то», «откуда» у нас уже есть) не нужна, вторая — твой реальный сетевой шлюз, третья не нужна, потому что пакеты в подсети передаются не через шлюз, а напрямую.

@ceyt Всё должно работать с одним маршрутом на 192.168.1.1 и стандартными записями для каждого интерфейса (маршрут на подсеть, на собственный адрес, на бродкаст в подсети, на общий бродкаст, на мультикаст — смотри на локалхост).

@bazar Тотальное и самозабвенное ламерство.

@bazar И что такое «канал» не объяснил, и что такое «идёт через» не объяснил, и что такое «не работает» не объяснил.

@bazar Действительно, надо выкинуть кампутир с виндой и поставить «продвинутый роутер». Монитор с клавиатурой и мышкой можно даже не подключать.

@o01eg «Не работало» или же «ходило через другой интерфейс»? Как именно «ходило», или ты просто в Wireshark обёрнутые пакеты заметил? Что такое «канал»? Выделенная линия, которую трактор переехал, или point-to-point туннель поверх имеющейся сети, или что-то другое? Что мы пытаемся починить, изнасиловав таблицу маршрутов?

@o01eg Как именно? Там проанонсировался MAC-адрес 10.2.0.3? То есть, это физически одна сеть, в которую смотрят несколько интерфейсов?

@o01eg То есть, ты изобретаешь отказоустойчивое/многопутное соединение двух систем?

@o01eg Если у тебя тот хост доступен через оба интерфейса, и он на линуксе, то ему надо включить arp_filter, чтобы и анонсы MAC-адресов, и трафик шли строго через каждый:
https://access.redhat.com/solutions/30564
https://robertlathanh.com/2009/08/two-subnetworks-on-one-lan-and-linux-arp_filter/
Поскольку у тебя подсети на интерфейсах не совпадают, отдельные таблицы маршрутизации для них можно не делать.

@o01eg И как тогда что-то там «идёт»?

@o01eg Так что сейчас «идёт»??? Какие пакеты, с какими адресами? Что происходит вообще? Я клещами вытянуть из тебя это пытаюсь.

@o01eg Насколько я понимаю, tracert не использует IcmpSendEcho2Ex (можешь проверить таблицу импорта в своей версии) и, следовательно, не может указать интерфейс для отправки пингов. Завидная совместимость с юниксовой утилитой, по умолчанию выбирающей первый попавшийся интерфейс. Попробуй на всякий случай TCP/UDP-ping или traceroute.