Вопросы Теги

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

У меня есть два интерфейса на сервере. Вывод ip route следующий: 

default via 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 metric 100

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

...
1: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.201/24 brd 192.168.100.255 scope global noprefixroute enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::1409:66c6:eb0d:22a1/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::85:5fff:fe98:6cb7/64 scope link
       valid_lft forever preferred_lft forever

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

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

Curl инициирует квитирование TCP и отправляет пакет на интерфейс 10.8.0.100 . Затем пакет достигает серверного компьютера на 10.8.0.1 . Сервер просматривает пакет dest и видит, что это 192.168.100.201 . Затем он просматривает таблицу маршрутизации и видит, что 192.168.100.201 является локальным. Теперь ответ возвращается. Отправитель: 10.8.0.100 . Посмотрев на таблицу маршрутизации, мы можем обнаружить, что она доступна через tap0 , который является локальным. Итак, теперь он помещается в tap0 и достигает 10.8.0.100.

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

0
задан 4 August 2021 в 20:15
1 ответ

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

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

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

1
ответ дан 4 August 2021 в 20:40

Теги

Похожие вопросы