Почему эта настройка маршрутизации не работает

У меня есть два интерфейса на серверной машине. Результат IP-маршрут находится рядом:

по умолчанию через 192.168.100.1 dev enp1s0 proto static metric 100
10.8.0.0/24 dev tap0 proto kernel scope link src 10.8.0.1
192.168.100.0/24 dev enp1s0 proto kernel scope link src 192.168.100.201 метрика 100

и айпи адрес следующий (MAC скрыты):

...
1: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel состояние UP группа по умолчанию qlen 1000
    ссылка/эфир **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.201/24 brd 192.168.100.255 глобальная область действия noprefixroute enp1s0
       valid_lft навсегда
    inet6 fe80::1409:66c6:eb0d:22a1/64 ссылка на область видимости noprefixroute
       valid_lft навсегда
2: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel состояние НЕИЗВЕСТНО группа по умолчанию qlen 100
    ссылка/эфир **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 10.8.0.1/24 brd 10.8.0.255 глобальная область действия tap0
       valid_lft навсегда
    ссылка на область inet6 fe80::85:5fff:fe98:6cb7/64
       valid_lft навсегда

/proc/sys/net/ipv4/ip_forward значение равно 1; брандмауэр отключен.

Я хочу получить доступ 192.168.100.1 от 10.8.0.100. Доступ к веб-серверу (который прослушивает все порты на этой машине) через curl --интерфейс 10.8.0.100 http://10.8.0.1 работает отлично. Но curl --интерфейс 10.8.0.100 http://192.168.100.201 выход Сеть недоступна.

Curl инициирует рукопожатие tcp и отправляет пакет на 10.8.0.100 интерфейс. Затем пакет достигает серверной машины на 10.8.0.1. Сервер смотрит в адрес назначения пакета и видит, что он 192.168.100.201. Затем он смотрит в таблицу маршрутизации и видит, что 192.168.100.201 является местным. Теперь ответ возвращается. Отправитель был 10.8.0.100. Глядя на таблицу маршрутизации, мы можем обнаружить, что она доступна через кран0, который является локальным. Итак, теперь он толкает в кран0 и достигает 10.8.0.100.

Но на самом деле - это не. Это потому, что ход моих мыслей неверен? Я подумал, что информации, представленной в описанной таблице, достаточно, чтобы определить, как пересылать пакеты. Это на самом деле неполное?

Прежде всего, укажите IP-адрес и интерфейс с параметром -I для пинг не являются синонимами. Сначала сообщает, какой исходный IP-адрес подобрать. Он направит его в соответствии с сетевым потоком, включая локальные адреса и таблицы маршрутизации. Второй говорит напрямую выбрать интерфейс для отправки пакета (и он выберет первый назначенный IP-адрес в качестве источника).

Далее то, что вы делаете, не имеет ничего общего с пересылкой пакетов. Переадресация означает, что пакет действительно должен прийти «извне». Поскольку вы генерируете пакет с этого хоста, пересылка не требуется. Это локально сгенерированный пакет. Поскольку ваш IP-адрес назначения является одним из локально назначенных адресов, когда вы не заставляете ping отправлять пакет на определенный интерфейс «внешний» (с -Я интерфейс option) ядро ​​будет обрабатывать этот поток пакетов внутри себя. Он просто не будет пытаться вывести его на реальный интерфейс, поскольку его пункт назначения «уже здесь». Так вот что происходит и почему это работает в одном случае, а не в другом.

PS: Также проверьте -р вариант пинг инструмент на случай, если вы знаете, что делаете, и оба интерфейса подключены к одному и тому же широковещательному домену (я сомневаюсь в этом с интерфейсом TAP).