чтобы маршрут писался не на конкретный ip адрес шлюза, а на интерфейс?
Рассказываю прям на пальцах...
Но перед этим немного теории и терминологии, чтобы в последующем было понятно, что именно подразумевается, да и вопросы будут более более конкретизированы.
Первое: у любого хоста, будь то комп, роутер, сетевой принтер, WI-FI точка доступа - шлюз по умолчанию
всегда один Это постулат, аксиома - называйте как нравится. Почему один и почему по умолчанию? Начнём с последнего - по умолчанию - это то, что мы ни описать, ни охарактеризовать, ни как-то конкретизировать не можем, но с ним всё-равно надо что-то сделать.
То есть, если мы не знаем что это такое - то к нему принимается действие "по умолчанию". Ещё не догадался, почему один шлюз? Правильно - если мы не знаем куда отправить пакет - он идёт по умолчанию. Не в два, не в три места, а в одно, пусть даже это чёрная дыра. Во всех остальных случаях конечные узлы (или множество узлов) мы можем описАть, следовательно это уже конкретизировано и правило "по умолчанию" не применимо. Стало быть мы знаем что, куда и через кого должно пойти - и это уже маршрут. Маршрутов у хоста может быть дофига. К примеру на магистральных маршрутизаторах их таблица исчисляется сотнями тысяч строк, это абсолютно нормально.
Второе: практика.
Имеем начальную таблицу
# route -nDestination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 enp2s0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp2s0
193.242.135.192 0.0.0.0 255.255.255.192 U 100 0 0 enp2s0
И, к примеру, есть сеть 192.168.
3.0/24 о которой мы пока не знаем, но на которую в моём дефолтном шлюзе прописан маршрут. То есть я не заморачиваюсь, как пойдут пакеты, я не понимаю и не конкретизирую эту сущность, мне в этот момент пофик, значит применться правило по умолчанию и это задача для моего 192.168.1.1 - дефолтного шлюза.
Проверяем: пингуем от балды...
# ping 192.168.3.1PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=63 time=1.63 ms
From 192.168.1.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.1.3)
64 bytes from 192.168.3.1: icmp_seq=2 ttl=63 time=1.60 ms
64 bytes from 192.168.3.1: icmp_seq=3 ttl=63 time=1.38 ms
64 bytes from 192.168.3.1: icmp_seq=4 ttl=63 time=1.47 ms
64 bytes from 192.168.3.1: icmp_seq=5 ttl=63 time=1.45 ms
^C
--- 192.168.3.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 1.388/1.511/1.639/0.097 ms
Заметил строчку
From 192.168.1.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.1.3) ?
Ок, делаем вывод, что на сеть 192.168.3.0/24 так или иначе идёт через 192.168.1.3, который, о чудо, в моей же сети.
Прописываем свой маршрут, в обход нашего дефолтного шлюза (то есть мы уже понимаем, что хотим).
(два подряд амперсанда "&&" помогают прям одной строчкой выполнить две последовательные команды: создать маршрут и потом посмотреть что наваяли)
# route add -net 192.168.3.0 netmask 255.255.255.0 gw 192.168.1.3 && route -n (эквивалент: ip route add 192.168.3.0/24 via 192.168.1.3)
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 enp2s0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp2s0
192.168.3.0 192.168.1.3 255.255.255.0 UG 0 0 0 enp2s0
193.242.135.192 0.0.0.0 255.255.255.192 U 100 0 0 enp2s0
Проверяем пингом и видим, что вон той сиреневой строчки уже нет и всё отлично пингуется
# ping 192.168.3.1enp2s0
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=63 time=1.49 ms
64 bytes from 192.168.3.1: icmp_seq=2 ttl=63 time=1.42 ms
64 bytes from 192.168.3.1: icmp_seq=3 ttl=63 time=1.74 ms
^C
--- 192.168.3.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.426/1.555/1.749/0.146 ms
Заметь, что до этого мы нигде не указывали, через какое устройство работать, в нашем случае это
enp2s0Пробуем прописать маршрут, указывая лишь устройство.
#route add -net 192.168.3.0 netmask 255.255.255.0 dev enp2s0 && route -nDestination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 enp2s0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp2s0
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 enp2s0
193.242.135.192 0.0.0.0 255.255.255.192 U 100 0 0 enp2s0
Как видим маршрут создался. А пингуется ли?
# ping 192.168.3.1PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
From 192.168.1.150 icmp_seq=1 Destination Host Unreachable
From 192.168.1.150 icmp_seq=2 Destination Host Unreachable
From 192.168.1.150 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.3.1 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4074ms
Фигу! А почему? А потому, что возникла коллизия - пакет с интерфейса спрыгнул, но даже до первого узла не дошёл, о чём покажут команды traceroute или tracepath. Тут надо понимать ещё и то, что если пакет ушёл через определённый шлюз, то и ответ вернуться должен через него же. По крайней мере в наших консерваториях именно так.
Ну т.е. интерфейс по DHCP получает какой-то шлюз и чтоб он автоматически прописывался.
Если хост шлюз получает по DHCP, то это и есть автоматически. DHCP может отдавать дополнительные маршруты, но это настраивается именно в нем. Если у провайдера такой цели не стоит, то все дополнительные хотелки надо добавлять самостоятельно в дополнительных настройках интерфейса (если такой функционал есть) или стартовыми скриптами.
Надеюсь понятно.
