Suse/OpenSuSE - [решено] Маршрутизация в подсеть через отдельный гейт

jscar · Отправлено: **18:38, 27-05-2015** | #11

Цитата jscar:

eth1 Link encap:Ethernet HWaddr *
inet addr:192.168.30.1 Bcast:192.168.30.255 Mask:255.255.255.0 »

Цитата jscar:

появилась новая vpn-железка, 192.168.30.250, за ней подсеть 10.10.19.0/24 »

в локальной сети

ruslandh · Конфигурация компьютера

Ну и направьте :
route add -net 10.10.19.0/24 dev eth1

jscar · Отправлено: **19:17, 27-05-2015** | #13

и что это даст?

Код:

traceroute 10.10.19.69 -n
traceroute to 10.10.19.69 (10.10.19.69), 30 hops max, 40 byte packets using UDP
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  192.168.30.1 (192.168.30.1)(H!)  2883.986 ms (H!)  2875.995 ms (H!)  2867.999 ms

Код:

tcpdump -i eth1 -n | grep 10.10.19
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
19:11:51.298993 arp who-has 10.10.19.69 tell 192.168.30.1
19:11:52.298991 arp who-has 10.10.19.69 tell 192.168.30.1
19:11:54.302992 arp who-has 10.10.19.69 tell 192.168.30.1

El Scorpio · Отправлено: **05:40, 28-05-2015** | #14

Цитата jscar:

но, очевидно, всей сети его вручную прописывать не будешь. надо научить гейт туда ходить »

А почему бы и не да?
DHCP прекрасно раздаёт клиентам статичные маршруты в отдельные подсети

Цитата jscar:

route add -net 10.10.19.0/24 gw 192.168.30.250
SIOCADDRT: Нет такого процесса »

Такая ошибка выводится, когда route пытается удалить отсутствующий маршрут
Такое впечатление, будто route пытается сначала удалить что-то "ненужное".

Попробуйте написать команду как
route add -net 10.10.19.0 netmask 24 gw 192.168.30.250

Цитата ruslandh:

Не понял, если у интерфейса 192.168.30.250, то и сеть за ней должна быть 192.168.30.0/24
А если сеть за ней 10.10.19.0/24, то и ip у железки должно быть из этой сети. »

А вот тут-то вы неправы.
Не забывайте, что у любого маршрутизатора всегда как минимум два адреса
Как я понимаю, 192.168.30.250 - это адрес с со стороны сети 192.168.30.0
А в сети 10.10.19.0 она имеет другой адрес

jscar · Отправлено: **08:11, 28-05-2015** | #15

Цитата El Scorpio:

почему бы и не да?
DHCP прекрасно раздаёт клиентам статичные маршруты в отдельные подсети »

существует еще софтовый впн, через который клиенты и подсети подключаются в сеть 192.168.30.0/24 и должны иметь доступ в 10.10.19.0/24. мне кажется, некорректно раздвать такие маршруты на всех удаленных подсетях через dhcp, да и маршруты там не пропишешь из-за гейта в иной подсети

Цитата El Scorpio:

Попробуйте написать команду как
route add -net 10.10.19.0 netmask 24 gw 192.168.30.250 »

если вы имели в виду "-net 10.10.19.0/24", то никакой разницы нет. та же ошибка. с вашим же вариантом -
route: bogus netmask 24

jscar · Отправлено: **16:21, 28-05-2015** | #16

в общем, если кому-то интересно, проблему решил какой-то особой магией.

Код:

route add 192.168.30.250 dev eth1

после чего

Код:

route add -net 10.10.19.0/24 gw 192.168.30.250

прекрасно отработал, как должен был

причины сего мне не ясны, если есть гуру, способные это объяснить - с интересом выслушаю

El Scorpio · Отправлено: **03:52, 30-05-2015** | #17

Цитата jscar:

причины сего мне не ясны, если есть гуру, способные это объяснить - с интересом выслушаю »

Попробую объяснить
причина в том, что компьютер не мог найти маршрут до 192.168.30.250

Ошибка находится здесь

Цитата jscar:

192.168.30.0 192.168.30.1 255.255.255.0 UG 0 0 0 eth1 »

Сравните хотя бы с этим

Код:

192.168.0.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0

Не может сетевая карта быть "шлюзом" для локальной сети.
Хотя бы потому что адрес 192.168.30.1 сам является частью диапазона 192.168.30.0/24, а значит любая попытка разбора такой "маршрутизации" приводит к зацикливанию алгоритма.
Скорее всего в сетевой подсистеме linux для таких ляпов предусмотрены проверки, просто они в разных ситуациях срабатывают по разному: при отправке пакетов отправляют их напрямую, а при модификации таблицы маршрутизации прекращают поиск. Вот потому пинги на устройство 192.168.30.250 (и прочие) проходят, а проложить маршрут в другую сеть через него уже не получается

ruslandh · Конфигурация компьютера

Цитата El Scorpio:

Не может сетевая карта быть "шлюзом" для локальной сети. »

Да ну, сколько угодно.

Другой вопрос, что
route add -net 10.10.19.0/24 dev eth1 - просто перекидывала запрос на eth1, без указания какому компу посылать (широковещательный запрос), а шлюз не сообщал, что это его запросы.
А route add -net 10.10.19.0/24 gw 192.168.30.250 указало конкретный адрес шлюза.

El Scorpio · Отправлено: **07:41, 31-05-2015** | #19

Цитата ruslandh:

Цитата El Scorpio:
Не может сетевая карта быть "шлюзом" для локальной сети. »

Да ну, сколько угодно. »

Повторяю: не может быть интерфейс локальной сети быть сам себе "шлюзом" для этой же сети

Цитата ruslandh:

route add -net 10.10.19.0/24 dev eth1 - просто перекидывала запрос на eth1, без указания какому компу посылать (широковещательный запрос), а шлюз не сообщал, что это его запросы.
А route add -net 10.10.19.0/24 gw 192.168.30.250 указало конкретный адрес шлюза. »

Вынужден констатировать, что вы имеете крайне смутное представление о работе таблицы маршрутизации

Рассмотрим самую простую таблицу

Код:

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

Каждый пакет протоколов TCP, UDP, ICPM и ряда других содержит значение IP-адреса и MAC-адреса получателя.
Если для IP-адреса получателя в таблице маршрутизации есть диапазон без шлюза (адрес 0.0.0.0), тогда отправитель делает прямую передачу информации следующим образом:
1. Отправляет служебный запрос ARP "Кто здесь 192.168.0.10?".
Только этот запрос является широковещательным, потому что у него MAC получателя равен FFFFFFFFFFFF, и такой пакет принимают все устройства данной локальной сети. Все прочие пакеты содержат MAC-адреса конкретных устройств, и принимаются только этими устройствами.
2. Устройство с этим IP-адресом присылает ответ "Ну я здесь 192.168.0.10"
3. Отправитель берёт из ответа MAC-адрес устройства, и записывает его в таблицу ARP, где тот хранится некоторое время
4. Затем отправитель начинает отправлять пакеты с данными, в которых указывается IP и MAC конечного получателя.

Если для IP-адреса получателя в таблице маршрутизации есть диапазон с указанным шлюзом, тогда отправитель делает запрос ARP по адресу шлюза, а затем начинает отправлять пакеты с данными, в которых указывается IP конечного получателя и MAC шлюза. Далее подразумевается что указанный шлюз получит этот пакет и отправит далее в нужную сеть по своей таблице маршрутизации.

А теперь вопрос: если сетевая карта является шлюзом для своей локальной сети, и IP-адрес шлюза совпадает с IP-адресом самой сетевой карты, то какие значения адресов будут в отправляемом пакете?
Правильно: отправляемый пакет будет иметь IP конечного получателя и MAC самого отправителя. Как следствие, этот пакет сможет принять только сам отправитель. Затем он будет пересылать пакет снова и снова, пока в пакете не обнулится значение TTL (время жизни)
Однако сейчас такие "маршруты" работают корректно, потому что в современных реализациях стека протоколов TCP/IP предусмотрели защиту от такой глупости.
-------------------------------------------------------

Теперь вернёмся к проблеме jscar, совершившего именно такую глупость.
Команда route add -net 10.10.19.0/24 gw 192.168.30.250 завершается ошибкой, потому что route просматривает таблицу маршрутизации на предмет прямых маршрутов до 192.168.30.250. То есть он ищет нужное значение только среди среди строк, у которых адрес шлюза равен 0.0.0.0
А среди таких срок нужного диапазона нет

Посему нужно заменить неправильный маршрут

Код:

192.168.30.0 192.168.30.1 255.255.255.0 UG 0 0 0 eth1

на правильную запись

Код:

192.168.30.0 0.0.0.0 255.255.255.0 UG 0 0 0 eth1