LINUX.ORG.RU
ФорумAdmin

Шлюз по умолчанию в другой подсети.


0

1

Здравствуйте. Ситуация следующая. ОС Gentoo, ядро 3.7.10 Имеется сеть(эмуляция в gns3): Схема
gentoo-машины импортированы из virtualbox, к первой(gentoo_001) через nat подведен интернет к интерфейсу enp0s3.

gentoo_001 вывод ip route list:

default via 10.0.2.2 dev enp0s3  metric 2 
10.0.2.0/24 dev enp0s3  proto kernel  scope link  src 10.0.2.15  metric 2 
127.0.0.0/8 via 127.0.0.1 dev lo 
172.16.55.0/29 dev enp0s8  proto kernel  scope link  src 172.16.55.1 
172.16.55.8/29 via 172.16.55.2 dev enp0s8  metric 3 
172.16.55.16/29 via 172.16.55.2 dev enp0s8  metric 3 


gentoo_002 вывод ip route list:
default via 172.16.55.1 dev enp0s3  metric 2 
127.0.0.0/8 via 127.0.0.1 dev lo 
172.16.55.0/29 dev enp0s3  proto kernel  scope link  src 172.16.55.2 
172.16.55.8/29 dev enp0s8  proto kernel  scope link  src 172.16.55.9 
172.16.55.16/29 dev enp0s9  proto kernel  scope link  src 172.16.55.17  


gentoo_003 вывод ip route list:
127.0.0.0/8 via 127.0.0.1 dev lo 
172.16.55.0/29 via 172.16.55.17 dev enp0s3  metric 2    ---(эту строку добавил я через /etc/conf.d/net)
172.16.55.16/29 dev enp0s3  proto kernel  scope link  src 172.16.55.19  


ping с компьютера gentoo_003 на gentoo_001(172.16.55.1) проходит, наоборот тоже.

Я знаю, что в этой схеме для машины gentoo_003 должен быть добавлен такой маршрут(вместо 172.16.55.0/29 via 172.16.55.17 dev enp0s3 metric 2):

default via 172.16.55.17 --- (шлюз по умолчанию)

и я знаю как это сделать.
Вопрос в другом.
Теоретически, раз маршрут до 172.16.55.1(gentoo_001) есть(на машине gentoo_003) и работает, то(опять-таки теоретически) можно теперь прописать его(172.16.55.1) маршрутом по умолчанию для 172.16.55.19(gentoo_003), т.е. так:
ip route add default via 172.16.55.1
На к сожалению при вводе получаю ошибку:
RTNETLINK answers: Nerwork is unreachable
Объясните пожалуйста, почему так происходит.

★★★★★

Последнее исправление: rumgot (всего исправлений: 2)

Много букв не читал, смысл шлюза в том, что он находится в видимой сети и выпускает в другие.

sin_a ★★★★★
()
Ответ на: комментарий от sin_a

Это да. Но ведь логично, что раз маршрут к хосту (который находится в другой сети) есть, то этот хост может служить шлюзом. Или нет? Или указанная выше ошибка специальное ограничение, чтобы ошибки не допускали?

rumgot ★★★★★
() автор топика
Ответ на: комментарий от rumgot

В шлюз по умолчанию отправляются пакеты, для которых не нашлось более узкого, конкретного маршрута. А по твоему предложению, чтобы отправить пакет в шлюз по умолчанию, ещё надо найти, через какой другой его отправлять.

Elyas ★★★★★
()
Ответ на: комментарий от Elyas

Согласен, это не логично. Но ведь технически реализовать такую схему можно. так вот я и думаю:можно ли такое поведение утилиты ip перенастроить, чтобы это ограничение снять.

rumgot ★★★★★
() автор топика

Потому что пакет имеет только отправителя и получателя. Шлюз, получив пакет не себе, отправляет его дальше согласно своим маршрутам. Внимание, вопрос - а как он способен получить пакет, предназначенный не ему? Ведь адрес шлюза в пакете не указывается? А получается это так - отправитель на транспортном уровне задаёт адрес получателя - IP получателя, а на канальном уровне - MAC-адрес шлюза. Таким образом, канальный уровень, ничего не зная про всякие TCP/IP спокойно доставляет пакет шлюзу, который подменяет канальный адрес пакета на следующую точку маршрута и отсылает дальше. Но для всего этого отправитель должен знать MAC-адрес шлюза. Узнаёт он его через ARP-запрос, который по своей природе широковещательный, поэтому на всех узлах обрывается во избежание флуда.

redgremlin ★★★★★
()
Ответ на: комментарий от redgremlin

Если промежуточный «шлюз» доступен для настройки, то можно разрешить на нём proxy arp, тогда он при получении arp-запроса не к себе вместо обрыва протранслирует его дальше. Вот только я не знаю, утилита ip делает тестовый arp-запрос или руководствуется только конфигурацией.

redgremlin ★★★★★
()
Ответ на: комментарий от rumgot

раз маршрут к хосту (который находится в другой сети) есть, то этот хост может служить шлюзом.

Твоим шлюзом является тот, через который твои пакеты попадают к желаемому. Что бы они пошли дальше, это головная боль уже того шлюза и на нём и надо указывать следующий шлюз. У тебя простейшая задача по маршрутизации.

На, изучай: http://www.warriorsofthe.net/movie.html

sin_a ★★★★★
()
Ответ на: комментарий от redgremlin

Не оспариваю написанное вами. Но. Вот рассуждаю, а вы напишите, в чем моя ошибка.
redgremlin, proxy-arp нужен, если я хочу запросить по arp протоколу mac адрес хоста, находящегося в другой сети. А в данном случае мне не нужен этот mac адрес. У меня (на компьютере gentoo_003) есть маршрут к сети(172.16.55.0/29) где находится gentoo_001 (который я хочу использовать как шлюз по умолчанию), т.е. я отправляю пакет на компьютер gentoo_002 (который указан как маршрут к сети 172.16.55.0/29 т.е. к хосту 172.16.55.1 (gentoo_001)). Где я не прав?

rumgot ★★★★★
() автор топика
Ответ на: комментарий от rumgot

Пакет всё равно по канальному уровню идёт по маку. Пакет доходит до gentoo_002 с канальным маком gentoo_002 (или не доходит вообще) и транспортным адресом «целевой IP». У gentoo_002 просто нет другой информации из пакета, про gentoo_001 извне никакой информации он получить не может.

redgremlin ★★★★★
()
Ответ на: комментарий от redgremlin

Всем спасибо за ответы.

rumgot ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.