URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 96269
[ Назад ]
Исходное сообщение
"почему не работает маршрутизация"
Отправлено konst2 , 01-Сен-15 20:19 
Почему при назначении маршрута:

route add A gw B
в таблице маршрутизации появляется маршрут, но
traceroute -n A  - не показывает, что маршрут отрабатывает.

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.1     192.168.0.18    255.255.255.255 UGH   0      0        0 eth0
192.168.1.2     192.168.0.18    255.255.255.255 UGH   0      0        0 eth0
...
0.0.0.0         192.168.0.253   0.0.0.0         UG    0      0        0 eth0

traceroute -n 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 60 byte packets
1  192.168.0.253  0.238 ms  0.234 ms  0.196 ms]
2  192.168.0.253  3001.031 ms !H  3001.029 ms !H  3001.024 ms !H

Содержание
Сообщения в этом обсуждении
"почему не работает маршрутизация"
Отправлено Skif , 01-Сен-15 23:18 
А противоположная сторона знает о вашей сети?
"почему не работает маршрутизация"
Отправлено Konst , 02-Сен-15 00:11 
> А противоположная сторона знает о вашей сети?

нет. 192.168.0.18 не знает о 192.168.1.0

"почему не работает маршрутизация"
Отправлено Аноним , 02-Сен-15 00:38 
>> А противоположная сторона знает о вашей сети?
> нет. 192.168.0.18 не знает о 192.168.1.0

Во первых ты ответил на _другой_ вопрос.
Во вторых - а нафига ты тогда пакеты для 1.0 раутишь на 0.18 ?!?!?! Если оно не знает?

"почему не работает маршрутизация"
Отправлено Konst , 02-Сен-15 00:53 
>>> А противоположная сторона знает о вашей сети?
>> нет. 192.168.0.18 не знает о 192.168.1.0
> Во первых ты ответил на _другой_ вопрос.

т.к. в данном случае это актуальнее.
> Во вторых - а нафига ты тогда пакеты для 1.0 раутишь на
> 0.18 ?!?!?! Если оно не знает?

для эксперимента. На самом деле мне надо было связать 2 машины из разных подсетей на удаленном объекте. Мне сообщили ip-шлюза. Роутинг прописал. Связи не появилось. А tracerote показал что и не идет через указанный маршрут.

Вот и сделал в своей локалке эксперимент, указав заведомо нерабочий вариант. Получил ту же картину (почти). На самом деле 1-я попытка traceroute была правильной, а далее как указано выше.
Сейчас почитал еще об роутинге. Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к исполнению.


"почему не работает маршрутизация"
Отправлено Square1 , 02-Сен-15 07:04 
>[оверквотинг удален]
>> 0.18 ?!?!?! Если оно не знает?
> для эксперимента. На самом деле мне надо было связать 2 машины из
> разных подсетей на удаленном объекте. Мне сообщили ip-шлюза. Роутинг прописал. Связи
> не появилось. А tracerote показал что и не идет через указанный
> маршрут.
> Вот и сделал в своей локалке эксперимент, указав заведомо нерабочий вариант. Получил
> ту же картину (почти). На самом деле 1-я попытка traceroute была
> правильной, а далее как указано выше.
> Сейчас почитал еще об роутинге. Развеялось мое заблуждение, что роутинг указанный вручную
> - обязателен к исполнению.

Неверные выводы из ошибочной интерпретации результатов некорректно поставленного эксперимента.


"почему не работает маршрутизация"
Отправлено konst2 , 02-Сен-15 16:42 
>>[оверквотинг удален]
>> Сейчас почитал еще об роутинге. Развеялось мое заблуждение, что роутинг указанный вручную
>> - обязателен к использованию.
> Неверные выводы из ошибочной интерпретации результатов некорректно поставленного эксперимента.

давайте вместе поставим :)

локальная сеть:
имеем 192.168.0.226/24
имеем 192.168.0.18/24 (1 сетевая и 1 ip на нем)
имеем 192.168.0.253/24 на котором есть alias 192.168.1.253/24

Проверяем доступность 192.168.1.253 с 192.168.0.226

На 226-м:
# route -n
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.253   0.0.0.0         UG    0      0        0 eth0

192.168.1.253 - доступен

# route add 192.168.1.253 gw 192.168.0.18
# route -n
192.168.1.253   192.168.0.18    255.255.255.255 UGH   0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.253   0.0.0.0         UG    0      0        0 eth0

#  traceroute -n 192.168.1.253
traceroute to 192.168.1.253 (192.168.1.253), 30 hops max, 60 byte packets
1  192.168.0.18  0.253 ms  0.239 ms  0.233 ms
....

192.168.1.253 - пока недоступен

# ping -w3 192.168.1.253
# traceroute -n 192.168.1.253
traceroute to 192.168.1.253 (192.168.1.253), 30 hops max, 60 byte packets
1  192.168.1.253  0.232 ms  0.226 ms  0.221 ms

192.168.1.253 - стал доступен (напрямую), хотя команда:

#ip route get 192.168.1.253
выдает:
192.168.1.253 via 192.168.0.18 dev eth0  src 192.168.0.226
    cache  mtu 1500 advmss 1460 hoplimit 64
==========
ну и чем некорректен эксперимент/вывод ?
Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к использованию.


"почему не работает маршрутизация"
Отправлено Square1 , 02-Сен-15 18:47 
>[оверквотинг удален]
> ms
> 192.168.1.253 - стал доступен (напрямую), хотя команда:
> #ip route get 192.168.1.253
> выдает:
> 192.168.1.253 via 192.168.0.18 dev eth0  src 192.168.0.226
>     cache  mtu 1500 advmss 1460 hoplimit 64
> ==========
> ну и чем некорректен эксперимент/вывод ?
> Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к
> использованию.

Тем что вы работаете с алиасом, который стал доступен после арп-запроса


"почему не работает маршрутизация"
Отправлено konst2 , 02-Сен-15 19:18 
>[оверквотинг удален]
>> 192.168.1.253 - стал доступен (напрямую), хотя команда:
>> #ip route get 192.168.1.253
>> выдает:
>> 192.168.1.253 via 192.168.0.18 dev eth0  src 192.168.0.226
>>     cache  mtu 1500 advmss 1460 hoplimit 64
>> ==========
>> ну и чем некорректен эксперимент/вывод ?
>> Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к
>> использованию.
> Тем что вы работаете с алиасом, который стал доступен после арп-запроса

Хорошо. Тогда какое может быть объяснение тому, что при установленном роутинге на хост A через шлюз B (циска) (при ненастроенном шлюзе)
traceroute на host A - не показывает попытку идти через шлюз B
?

"почему не работает маршрутизация"
Отправлено Square1 , 02-Сен-15 19:20 
>[оверквотинг удален]
>>>     cache  mtu 1500 advmss 1460 hoplimit 64
>>> ==========
>>> ну и чем некорректен эксперимент/вывод ?
>>> Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к
>>> использованию.
>> Тем что вы работаете с алиасом, который стал доступен после арп-запроса
> Хорошо. Тогда какое может быть объяснение тому, что при установленном роутинге на
> хост A через шлюз B (циска) (при ненастроенном шлюзе)
> traceroute на host A - не показывает попытку идти через шлюз B
> ?

вы не тем смотрите инструментом.
смотрите tcpdump-ом


"почему не работает маршрутизация"
Отправлено konst2 , 02-Сен-15 19:45 
>[оверквотинг удален]
>>>> ну и чем некорректен эксперимент/вывод ?
>>>> Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к
>>>> использованию.
>>> Тем что вы работаете с алиасом, который стал доступен после арп-запроса
>> Хорошо. Тогда какое может быть объяснение тому, что при установленном роутинге на
>> хост A через шлюз B (циска) (при ненастроенном шлюзе)
>> traceroute на host A - не показывает попытку идти через шлюз B
>> ?
> вы не тем смотрите инструментом.
> смотрите tcpdump-ом

Посмотрел на удаленном объекте.
tcpdump доступен только на исходном хосте (откуда делается traceroute).

Так вот там:
при прописанном роутинге через шлюз "B" (циска)
tcpdump - не показывает участия "B"  при traceroute -n -T <A>

только при traceroute -n -T -g B <A>
есть рез-т:
B > A: ICMP B unreachable - source route failed, length 80
=====
ну в принципе я уже давно понял, что причина того, что я не могу достучаться до "A" в том, что шлюз "B" (циска) недонастроен. (PS. Это чужая железка)

Меня просто смущало, что traceroute не показывает даже ПОПЫТКИ идти через указанный шлюз.

"почему не работает маршрутизация"
Отправлено Square1 , 02-Сен-15 20:16 
>[оверквотинг удален]
> tcpdump - не показывает участия "B"  при traceroute -n -T <A>
> только при traceroute -n -T -g B <A>
> есть рез-т:
> B > A: ICMP B unreachable - source route failed, length 80
> =====
> ну в принципе я уже давно понял, что причина того, что я
> не могу достучаться до "A" в том, что шлюз "B" (циска)
> недонастроен. (PS. Это чужая железка)
> Меня просто смущало, что traceroute не показывает даже ПОПЫТКИ идти через указанный
> шлюз.

О том, что сеть А находится за шлюзом В - должен знать ваш шлюз,  а не ваша хостовая машина.

Ваша хостовая машина- ничего кроме дефолтного роутинга на ваш шлюз знать не должна.
Ваш шлюз должен знать, за каким шлюзом находиться хост в сети А.
Шлюз В должен знать что за ним находиться хост А.

Ну и в обратную сторону соответственно....шлюз В должен знать что ваш хост находится за вашим шлюзом...

"почему не работает маршрутизация"
Отправлено Square1 , 02-Сен-15 21:28 
>[оверквотинг удален]
>> Меня просто смущало, что traceroute не показывает даже ПОПЫТКИ идти через указанный
>> шлюз.
> О том, что сеть А находится за шлюзом В - должен знать
> ваш шлюз,  а не ваша хостовая машина.
> Ваша хостовая машина- ничего кроме дефолтного роутинга на ваш шлюз знать не
> должна.
> Ваш шлюз должен знать, за каким шлюзом находиться хост в сети А.
> Шлюз В должен знать что за ним находиться хост А.
> Ну и в обратную сторону соответственно....шлюз В должен знать что ваш хост
> находится за вашим шлюзом...

И вот тут мы подходим к вопросу :) который я вообще говоря хотел задать в самом начале...
А сети которые вы связываете, часом не серые?
Потому что если вам надо связать между собой две серые сети через интернет- то вы мягко говоря подошли к решению задачи вообще не с того конца... :)

"почему не работает маршрутизация"
Отправлено Konst , 03-Сен-15 00:38 
>[оверквотинг удален]
>> Ваш шлюз должен знать, за каким шлюзом находиться хост в сети А.
>> Шлюз В должен знать что за ним находиться хост А.
>> Ну и в обратную сторону соответственно....шлюз В должен знать что ваш хост
>> находится за вашим шлюзом...
> И вот тут мы подходим к вопросу :) который я вообще говоря
> хотел задать в самом начале...
> А сети которые вы связываете, часом не серые?
> Потому что если вам надо связать между собой две серые сети через
> интернет- то вы мягко говоря подошли к решению задачи вообще не
> с того конца... :)

да нет. Все тривиальнее. Наш сервер находится в некоем учреждение в местной localnet-1, там же есть отдельная localnet-2. Задача была связать наш сервер (из localnet-1) с машиной из localnet-2. Задействовали циску, котрая смотрит "1-м концом" с localnet-1, а "2-м концом" в localnet-2. Мне надо было только прописать роутинг на своем сервере.
В рез-те - связи не появилось. Вопрос - почему?
traceroute -n на хост из localnet-2 не показал, что он пытается использовать указанный шлюз (циску). Вот это и вызывает недоумение.
PS. К циске и localnet-2 я не имею никакого отношения. Все сети имеют серые addr.


"почему не работает маршрутизация"
Отправлено Etch , 02-Сен-15 19:28 
> Тем что вы работаете с алиасом, который стал доступен после арп-запроса

Не совсем так. Если я что-то понимаю в сетях, то запрос уходит на шлюз (192.168.0.18), как и говорит 'ip route get 192.168.1.253'.

А ответ приходит сразу от конечного IP лишь потому, что узел шлюза содержит этот адрес среди прочих (не важно на каком интерфейсе). Т.е. шлюз не знает, что в данном случае он шлюз - он просто получает пакет, видит что его не надо маршрутизировать дальше, и поэтому просто присылает ответ от нужного IP.

И команда 'arp -an |grep 192.168.1.253' покажет отсутствие соответствия MAC адреса для данного IP.

"почему не работает маршрутизация"
Отправлено Square1 , 02-Сен-15 19:32 
>> Тем что вы работаете с алиасом, который стал доступен после арп-запроса
> Не совсем так. Если я что-то понимаю в сетях, то запрос уходит
> на шлюз (192.168.0.18), как и говорит 'ip route get 192.168.1.253'.
> А ответ приходит сразу от конечного IP лишь потому, что узел шлюза
> содержит этот адрес среди прочих (не важно на каком интерфейсе). Т.е.
> шлюз не знает, что в данном случае он шлюз - он
> просто получает пакет, видит что его не надо маршрутизировать дальше, и
> поэтому просто присылает ответ от нужного IP.
> И команда 'arp -an |grep 192.168.1.253' покажет отсутствие соответствия MAC адреса
> для данного IP.

192.168.0.18 не содержит 192.168.1.253 ни на каком интерфейсе.... если я правильно понял схему

"почему не работает маршрутизация"
Отправлено Konst , 03-Сен-15 01:04 
>[оверквотинг удален]
>> на шлюз (192.168.0.18), как и говорит 'ip route get 192.168.1.253'.
>> А ответ приходит сразу от конечного IP лишь потому, что узел шлюза
>> содержит этот адрес среди прочих (не важно на каком интерфейсе). Т.е.
>> шлюз не знает, что в данном случае он шлюз - он
>> просто получает пакет, видит что его не надо маршрутизировать дальше, и
>> поэтому просто присылает ответ от нужного IP.
>> И команда 'arp -an |grep 192.168.1.253' покажет отсутствие соответствия MAC адреса
>> для данного IP.
> 192.168.0.18 не содержит 192.168.1.253 ни на каком интерфейсе.... если я правильно понял
> схему

у 192.168.0.18-го дефолтный gw = 0.253. Его запросили о 192.168.1.253, о котором он ничего не знает, и передел запрос на 0.253, который знает... Как-то так, наверное.

"почему не работает маршрутизация"
Отправлено Etch , 03-Сен-15 07:37 
> 192.168.0.18 не содержит 192.168.1.253 ни на каком интерфейсе.... если я правильно понял схему

а, да - невнимательно посмотрел. Тогда на 192.168.0.18 должен быть маршрут до 192.168.1.253, и он по ICMP Redirect выслал исходной машине новый маршрут.

"почему не работает маршрутизация"
Отправлено Konst , 03-Сен-15 00:57 
>> Тем что вы работаете с алиасом, который стал доступен после арп-запроса
> Не совсем так. Если я что-то понимаю в сетях, то запрос уходит
> на шлюз (192.168.0.18), как и говорит 'ip route get 192.168.1.253'.
> А ответ приходит сразу от конечного IP лишь потому, что узел шлюза
> содержит этот адрес среди прочих (не важно на каком интерфейсе). Т.е.
> шлюз не знает, что в данном случае он шлюз - он
> просто получает пакет, видит что его не надо маршрутизировать дальше, и
> поэтому просто присылает ответ от нужного IP.
> И команда 'arp -an |grep 192.168.1.253' покажет отсутствие соответствия MAC адреса
> для данного IP.

Тоже так подумал. Только с последнем скорее не согласен. В arp будут mac и для 192.168.1.253 и для 192.168.0.253, причем в данном случае одинаковые.

Последний мой эксперимент действительно в этом случае - некорректен.
---
А в целом по теме: почему при прописанном роутинге traceroute не показывает попытку дойти до шлюза - ответ видимо в разных типах/настройках роутеров. В моем случае недонастроенная циска просто сразу топырит запрос (refuse route), и tracerote ничего и не выдает. Другие роутеры в подобной ситуации (не настроен шлюз) не топырят, и только по timeout отваливаются. И в этом случае tracerote покажет, что дошел до шлюза.


"почему не работает маршрутизация"
Отправлено Square1 , 02-Сен-15 19:19 
>[оверквотинг удален]
> ms
> 192.168.1.253 - стал доступен (напрямую), хотя команда:
> #ip route get 192.168.1.253
> выдает:
> 192.168.1.253 via 192.168.0.18 dev eth0  src 192.168.0.226
>     cache  mtu 1500 advmss 1460 hoplimit 64
> ==========
> ну и чем некорректен эксперимент/вывод ?
> Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к
> использованию.

Чтобы рассуждать о маршрутизации, вам надо собрать вот такую примерно схему

_________192.168.0.226/24
________________/\
192.168.0.253/24  192.168.0.18/24
_____________(1)\/(2)
___________192.168.1.253/24

И никаких "необязательных в ручную роутингов" :)

"почему не работает маршрутизация"
Отправлено fantom , 10-Сен-15 15:57 
>[оверквотинг удален]
>> 0.18 ?!?!?! Если оно не знает?
> для эксперимента. На самом деле мне надо было связать 2 машины из
> разных подсетей на удаленном объекте. Мне сообщили ip-шлюза. Роутинг прописал. Связи
> не появилось. А tracerote показал что и не идет через указанный
> маршрут.
> Вот и сделал в своей локалке эксперимент, указав заведомо нерабочий вариант. Получил
> ту же картину (почти). На самом деле 1-я попытка traceroute была
> правильной, а далее как указано выше.
> Сейчас почитал еще об роутинге. Развеялось мое заблуждение, что роутинг указанный вручную
> - обязателен к исполнению.

Дык все правильно... УЧИТЕ МАТЧАСТЬ! А конкретнее - что такое ICMP Redirect....

"почему не работает маршрутизация"
Отправлено Etch , 02-Сен-15 05:05 
1 - вы не показали маршрут до 192.168.0.18
2 - полагаю, нужно сбросить кэш маршрутизации:  ip route flush cache
3 - покажите вывод команды:  ip route get 192.168.1.1