Почему сеть ведёт себя очень странно?

Question

[LAG_LAGbI4]

Есть локальная сеть. Доступ в интернет через kerio. Внешний ip адрес 77.111.222.5. Шлюз провайдера 77.111.222.1.
Но при выполнении команды трасерт

Трассировка маршрута к ya.ru [93.158.134.3]
с максимальным числом прыжков 30:

1 2 ms 11 ms 2 ms control [192.168.1.252]
2 13 ms 5 ms 8 ms 10.22.2.1
3 7 ms 9 ms 7 ms 10.244.11.6
4 4 ms 3 ms 7 ms 188.123.255.34
5 10 ms 4 ms 4 ms 188.123.255.33
6 8 ms 6 ms 6 ms 213.79.104.161
7 6 ms 10 ms 5 ms 213.79.127.21
8 10 ms 16 ms 11 ms std-p1-eth-trunk17.yndx.net [87.250.239.96]
9 5 ms 4 ms 7 ms ugr-b-c1-ae1.yndx.net [87.250.239.47]
10 6 ms 5 ms 7 ms ya.ru [93.158.134.3]

Первый хоп понятно - это kerio. Но почему ответ второго хопа из 10 сети. У меня нет интерфейса, который бы смотрел в 10ую сеть. Как так может происходить?

Answer 1

[Ярослав]

Это стык внутри провайдерской сети - между маршрутизаторами самого провайдера.

Примерно так:

Comments

[LAG_LAGbI4]

я не понимать. почему тогда маршрутизатор провайдера 1 не отвечает?

[Ярослав]

Он и отвечает.

Но не с того интерфейса, на который получил traceroute-запрос, а с того, которым смотрит внутрь провайдерской сети.
Поведение это, с непривычки, неочевидное, и объясняется архитектурой маршрутизатора провайдера.

Да, .1, .2 и .5 на схеме - это последние октеты ip-адреса.

Получется, ASBR провайдера смотрит в вашу сторону адресом 77.111.222.1/29, а внутрь провайдерской сети - адресом 10.22.2.1/30

[LAG_LAGbI4]

Ярослав: но как маршрутизатор может отвечать интерфейсом, который не смотрит в мою сторону? ведь пакет в таком случае не дойдёт до меня, а уйдёт в сеть провайдера.

[OsyaBender]

LAG_LAGbI4: На роутере может быть такая опция "Не отвечать на пинг-запросы"

[LAG_LAGbI4]

OsyaBender: а какое это имеет отношение к данной ситуации?
вот тут 9 хоп не хочет отвечать на пинги. его право, это нормально.

Трассировка маршрута к iana.org [192.0.43.8]
с максимальным числом прыжков 30:
1 9 ms 2 ms 1 ms control [192.168.1.252]
2 4 ms 6 ms 4 ms 10.22.2.1
3 7 ms 8 ms 5 ms 10.244.11.62
4 5 ms 4 ms 7 ms 188.123.255.34
5 18 ms 8 ms 11 ms 188.123.255.33
6 7 ms 90 ms 30 ms 213.79.104.161
7 63 ms 40 ms 40 ms fkt-m9-eg1.comcor.ru [62.117.100.83]
8 * 3697 ms 1694 ms lag-108.ear2.Frankfurt1.Level3.net [212.162.4.129]
9 * * * Превышен интервал ожидания для запроса.
10 137 ms 150 ms 147 ms INTERNET-CO.ear2.Washington1.Level3.net [4.31.163.46]
11 132 ms 135 ms 144 ms iana.org [192.0.43.8]
Трассировка завершена.

[Ярослав]

LAG_LAGbI4: но как маршрутизатор может отвечать интерфейсом, который не смотрит в мою сторону? ведь пакет в таком случае не дойдёт до меня, а уйдёт в сеть провайдера.

Здесь чуть хитрее ;)
Итак:

1. Маршрутизатор R1 в интерфейсе eth0 получает запрос с вашей стороны:
src ip: 77.111.222.5
dst ip: 93.158.134.3
TTL: 1

2. R1 заглядывает в таблицу маршрутизации: что с ним делать? Видит запись: положить в интерфейс eth1 и отправить на маршрутизатор R2.

3. R1 кладёт запрос в очередь отправки интерфейса eth1.

4. Интерфейс eth1 маршрутизатора R1 достаёт запрос из очереди отправки, уменьшает TTL...
Ой! TTL == 0! Надо сообщить отправителю: запрос протух!

5. Интерфейс eth1 маршрутизатора R1 создаёт сообщение ICMP TTL Exceeded.
Ладно, с destination ip всё понятно: 77.111.222.5
А какой адрес мне указать в качестве адреса отправителя? А возьму-ка я свой - 10.22.2.1!

6. Интерфейс eth1 маршрутизатора R1 выпихивает ответ обратно в системную шину R1.

7. R1 смотрит: ой, пакет для ip-адреса 77.111.222.5! Смотрит в таблицу маршрутизации: куда его девать? Ага! Положить в интерфейс eth0!

8. Маршрутизатор LAG_LAGbI4 получает ответ:
TTL Exceeded
dst ip: 77.111.222.5
src ip: 10.22.2.1

9. LAG_LAGbI4 удивляется ;)

[LAG_LAGbI4]

Ярослав: это специфика оборудования что ли? я с таким никогда не сталкивался. я проверил на 5 доступных провайдерах, везде подругому работает.

[Ярослав]

LAG_LAGbI4: да, такое поведение зависит от:
- производителя
- модели
- конкретной конфигурации маршрутизатора

Проверить прямо сейчас не могу, но могу предположить, что этот фокус должен проявляться в случае, если интерфейсы маршрутизатора R1 (в примере eth0 и eth1) располагаются на _разных_ PFE - грубо говоря, сетевых платах.

В общем, если кратко:
заморачиваться не надо, так бывает.

[Александр Карабанов]

В IPv6 сетях в таких ситуациях вообще link-local адреса фигурируют и это нормально.

Answer 2

[Андрей]

Попробуйте тогда еще
ping -r 9 188.123.255.34

Comments

[LAG_LAGbI4]

C:\Users\x>ping -r 9 188.123.255.34

Обмен пакетами с 188.123.255.34 по с 32 байтами данных:
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.

Статистика Ping для 188.123.255.34:
Пакетов: отправлено = 4, получено = 0, потеряно = 4
(100% потерь)

я не очень понял, что делает ключ -r

[Андрей]

Ну попробуйте какой-нибудь другой IP из Вашего списка traceroute-а, только не дальше чем в 4 прыжках от Вас.

Ключ -r записывает все IP адреса чем которые проходил ping и ответ на него, но не больше чем 9 штук. ping -r информативнее traceroute-а поскольку он записывает IP-адреса обеих сторон каналов.

[LAG_LAGbI4]

Андрей:
Трассировка маршрута к google-public-dns-a.google.com [8.8.8.8]
с максимальным числом прыжков 30:
1 1 ms 4 ms 7 ms control [192.168.1.252]
2 7 ms 2 ms 4 ms 10.22.2.1
3 8 ms 7 ms 6 ms 10.244.11.62
4 3 ms 5 ms 3 ms 188.123.255.34
5 15 ms 13 ms 18 ms 188.123.255.33
6 7 ms 8 ms 14 ms 213.79.104.161
7 31 ms 13 ms 23 ms 72.14.213.188
8 3 ms 4 ms 4 ms 72.14.252.10
9 3 ms 2 ms 2 ms google-public-dns-a.google.com [8.8.8.8]
Трассировка завершена.

C:\Users\x>ping -r 9 10.22.2.1

Обмен пакетами с 10.22.2.1 по с 32 байтами данных:
Ответ от 10.22.2.1: число байт=32 время=12мс TTL=126
Маршрут: 85.21.244.34 ->
192.168.1.252
Ответ от 10.22.2.1: число байт=32 время=3мс TTL=126
Маршрут: 85.21.244.34 ->
192.168.1.252
Ответ от 10.22.2.1: число байт=32 время=23мс TTL=126
Маршрут: 85.21.244.34 ->
192.168.1.252
Ответ от 10.22.2.1: число байт=32 время=2мс TTL=126
Маршрут: 85.21.244.34 ->
192.168.1.252

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

[Андрей]

Что Вы понимаете под технологией прямого общения ? Это совершенно нормально на сетях /30 и /31 ставить серые адреса, они никому не мешают, только лишь создают странные записи при трассировке.

Answer 3

[SergeyNN]

NAT провайдера?..

Comments

[LAG_LAGbI4]

а зачем нужен нат, если ip адрес внешний статический?

[SergeyNN]

У нас в Нижегородской области Ростелеком, например, так экономит адреса. Абонентов много, белых адресов на всех не хватает. При подключении к сети (pppoe) иногда дают белый, а иногда серый адрес за натом Ростелекома. Как повезет.