Как IP-адрес шлюза в статическом маршруте влияет на маршрутизацию


2

Я использовал компьютер с Windows 7 для подключения к компьютеру с Windows 10, который находится в той же физической сети, но в другой подсети. До того, как я добавил статический маршрут в Windows 7, весь трафик направлялся к основному маршрутизатору, а затем обратно в Windows 10. Это вызывало длительную задержку при инициировании RDP-соединения, поэтому я добавил статический маршрут в Windows 7, чтобы избежать использования верхнего маршрутизатора. , Я сделал ошибку, которая в итоге сработала, и я не уверен, почему.

Диаграмма сети

Network diagram

Статические маршруты для Windows 7

1. None
2. route add 10.1.1.0 mask 255.255.255.0 10.1.0.99
3. route add 10.1.1.0 mask 255.255.255.0 10.1.1.3
  • С помощью route 1 tracert шоу 10.1.0.98 -> 10.1.0.1 -> 10.1.0.99 -> 10.1.1.4
  • С помощью route 2 tracert шоу 10.1.0.98 -> 10.1.0.99 -> 10.1.1.4
  • С помощью route 3 tracert шоу 10.1.0.98 -> 10.1.0.99 -> 10.1.1.4

Я понимаю почему route 2 работает, но я не знаю почему route 3 тоже работает.

PS: Если кто-то может предложить более четкое название, пожалуйста, сделайте.


Маршрут 3 не работает. Таким образом, ответ на этот вопрос заключается в том, что ваша таблица маршрутизации была не такой, как вы думали, или ваша информация трассировки неверна. Может быть или один или оба. Traceroute не всегда показывает все прыжки. Был ли адрес вашего шлюза на машине с Win 7 все еще 10.1.0.1?
Appleoddity

@Appleoddity Да, шлюз все еще был 10.1.0.1. 2 и 3 - это команды в наборе. Причина, по которой я верю tracert разница в производительности Установление сеанса RDP происходит мгновенно по маршруту 1 или 2.
chew socks

Ты сделал route print проверить всю таблицу маршрутизации? 3 не сработает. Единственный логичный ответ - вы оставили 2 активных.
Appleoddity

@Appleoddity Я проверил там. Я на самом деле сделал 3 до 2; Я сделал ошибку, а затем был удивлен, что это сработало. Я думаю, что я понял это, хотя. Посмотрите, правильно ли звучит мой ответ ниже.
chew socks

@chewsocks: Можете ли вы также найти конкретные маршруты для хоста, который вы пингуете / отслеживаете? (То есть с сетевой маской 255.255.255.255?) Комментарий harrymc заставляет меня заподозрить перенаправления ICMP, отправленные вашим основным маршрутизатором.
grawity

Ответы:


2

Маршрут 3 работает из-за того, как пакеты ARP обрабатываются компьютером Ubuntu. Запрос ARP для 10.1.1.3 отправляется 10.1.0.0/24 и принимается через интерфейс 10.1.0.99. Так как этот компьютер также владеет 10.1.1.3, он отвечает аппаратным адресом для своего 10.1.0.99. Когда компьютер с Windows 7 позднее пытается установить RDP-соединение с компьютером с Windows 10, он отправляет пакеты, предназначенные для шлюза 10.1.1.3, но с MAC-адресом компьютера в той же подсети, который коммутатор может пересылать напрямую.

Чтобы попытаться проверить это

В Windows 7

.\Arping.exe -i 10.1.0.98 -T 10.1.1.3

На Ubuntu

22:19:51.275116 (Windows 7 MAC) > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.1.1.3 tell 10.1.0.98, length 46

Это логичное объяснение, но все еще в корне ошибочное. Если предположить, что все маски подсети (это все 255.255.255.0, верно?) Равны / 24, то компьютеры на 10.1.0.x / 24 не будут отправлять «запрос ARP для 10.1.1.3», потому что они не находятся в той же подсети. Компьютер знает это, и поэтому знает, что должен отправить пакет на шлюз по умолчанию или другой маршрут, который у него есть. Поэтому он создает запрос ARP для шлюза IP 10.1.0.1 и отправляет пакет этому маршрутизатору для пересылки. Он никогда не будет искать в своей локальной сети 10.1.1.x.
Appleoddity

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

@Appleoddity Я разместил редактирование, где я сделал дамп tcp.
chew socks

Хорошо. Я вижу tcpdump, но вы генерируете ARP, «форсируя» его с помощью arpping. Нам нужно увидеть фактический запрос / ответ arp в сети при пинге или трассировке 10.1.1.4. Он будет отображаться в трассировке tcpdump или wireshark в сети 10.1.0.0. Я полагаю, что Arpping всегда будет отправлять запрос, на который вы его указали.
Appleoddity

@Appleoddity Я предполагал, что он не будет отправлять запросы ARP, как только узнает ответ, но на самом деле это так. Я записывал одни и те же запросы, даже когда не делал арпинга
chew socks

1

Магия маршрута 3 работает отчасти благодаря протоколу разрешения адресов и частично из-за таблицы пересылки и частично из-за алгоритмы маршрутизации.

Википедия говорит :

Протокол разрешения адресов (ARP) - это протокол связи, используемый для обнаружения адреса канального уровня, такого как MAC-адрес, связанный с данным адресом интернет-уровня (обычно адресом IPv4).

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

Ubuntu при запуске объявила о своем присутствии и интерфейсах в обеих подсетях, к которым он подключен, то есть ко всей вашей сети. Любое подобное объявление сделано Windows 10 была только внутри своей подсети, поэтому никогда не доходила до Windows 7. Даже если такое объявление не было получено, Windows 7 будет, чтобы найти соответствие, отправьте широковещательный пакет в сеть, используя Протокол ARP, чтобы спросить "у кого есть 10.1.1.4".

Большой намек на то, что tracert команда не перечислила маршрутизатор среди хмеля. Запрос на 10.1.1.4 пошел прямо к компьютеру Ubuntu хотя Windows 7 не знает о 10.1.1.4,

То, что мы видим в действии, это Windows Таблица IP-маршрутизации: процесс определения маршрута :

  • Для каждой записи в таблице маршрутизации выполните побитовое логическое И между IP-адресом назначения и маской сети. Сравните   результат с идентификатором сети записи для совпадения.

  • Список подходящих маршрутов составляется. Маршрут с самым длинным совпадением (маршрут, который соответствует наибольшему количеству битов с   IP-адрес получателя). Самый длинный соответствующий маршрут   наиболее конкретный маршрут к IP-адресу назначения. Если несколько записей   с наибольшим совпадением (несколько маршрутов в одну сеть   ID, например), маршрутизатор использует самый низкий показатель, чтобы выбрать лучший   маршрут. Если существует несколько записей, которые являются самыми длинными совпадают и   самый низкий показатель, маршрутизатор может свободно выбирать, какую запись таблицы маршрутизации   использовать.

Маршрутизация Windows 7 нашла общий префикс между 10.1.1.4 а также 10.1.1.3 который был 10.1.1, Другими возможностями были маршрутизатор или Ubuntu на 10.1.0.99, но чей общий префикс был только 10.1поэтому они не были выбраны.

Мы видим здесь в действии таблицу пересылки, которая построена сверху таблицы маршрутизации. В то время как таблица маршрутизации компилирует маршруты на основе IP-адресов, таблица пересылки содержит соответствующие MAC-адреса. Таким образом, таблица пересылки содержала запись: «Для 10.1.1.X, переслать пакет на MAC-адрес компьютера Ubuntu ". Как только пакет прибыл на компьютер Ubuntu, он знал очень хорошо как переслать 10.1.1.4,

Так вот как пакеты из Windows 7 в конечном итоге на Windows 10, и наоборот.


Бесплатная ARP не генерирует записи таблицы маршрутизации ни в одной операционной системе, которую я видел. Вы могли бы догадаться, если бы речь шла о пакетах ICMP Redirect, поступающих от маршрутизатора Mikrotik, которые генерируют запись маршрута хоста.
grawity

@ Grawity: я забыл необоснованный ARP, который я добавил. ARP, конечно, является неотъемлемой частью таблицы маршрутизации, и в нескольких операционных системах эти два списка отображаются отдельно для удобства чтения. Смотрите, например, раздел 3.2 rfc1433 Направленный ARP ,
harrymc

Это было бы верно для Directed ARP, за исключением того, что ни Windows, ни Linux не используют этот протокол. Он был опубликован как «экспериментальный» RFC, но так и не получил широкого распространения на практике. Я только что проверил реализацию Linux IPv4 FIB, и она полностью отделена от кэша ARP / соседей. Google говорит, что на microsoft.com также нет упоминаний о «ARP helper».
grawity

@ grawity: Вы серьезно не предполагаете, что ОС не будет использовать ARP для разрешения IP-адресов и поиска подходящих MAC-адресов? Я не вижу других механизмов, кроме ARP + таблица маршрутизации + таблица пересылки, но я слушаю.
harrymc

Нет. Я полагаю, что эти слои действуют совершенно независимо друг от друга. Таблица маршрутизации в большинстве указывает исходящий интерфейс, но не адрес L2 назначения.
grawity
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.