почему tracert не показывает тот же адрес шлюза, что и в ipconfig
Меня смущает следующее:
C:\>ipconfig
....
Connection-specific DNS Suffix . : some address here
IP Address. . . . . . . . . . . . : 10.77.121.54
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.77.121.1
Из вышесказанного, шлюз для моего компьютера - 10.77.121.1. Но когда я использую tracert, первый IP-адрес отличается, как вы можете видеть из следующего. Это 10.77.121.3. Зачем?
C:\tracert 10.75.89.100
Tracing route to 10.75.89.100
over a maximum of 30 hops:
1 29 ms <1 ms <1 ms 10.77.121.3
2 <1 ms <1 ms <1 ms 10.77.0.34
3 1 ms <1 ms <1 ms 10.77.0.45
4 <1 ms <1 ms <1 ms 10.75.89.100
Похоже, используемый шлюз может использовать VRRP или HSRP. 10.77.121.1 - это виртуальный / логический адрес, который вы используете в качестве шлюза, но когда вы отслеживаете маршрут, отвечает один из физических маршрутизаторов. (10.77.121.3)
Ваш шлюз по умолчанию не всегда является следующим переходом. Фактически, это обычно последний маршрутизатор. Ваш компьютер проанализирует таблицу маршрутизации и будет использовать шлюз по умолчанию только в том случае, если не совпадают другие более конкретные маршруты. Так сделай печать маршрута и посмотрите, что вы там найдете.
Из вышесказанного шлюз для моего компьютера - 10.77.121.1. Но когда я использую tracert, первый IP-адрес отличается, как вы можете видеть из следующего. Это 10.77.121.3. Зачем?
Это редко, но, возможно, 10.77.121.1 больше не имеет соединения со следующим переходом, но по-прежнему имеет включенную пересылку. Если это так, с некоторыми операционными системами, когда вы попытаетесь отправить пакет, вы свяжетесь с 10.77.121.1, но 10.77.121.1 вернет Перенаправление ICMP с адресом 10.77.121.3, который ваша система будет использовать в качестве шлюза. Поскольку ваш пакет на самом деле не пересылается 10.77.121.1, он не будет отображаться в маршруте трассировки.
Быстрый захват вашего любимого сниффера на вашем клиенте подтвердит, что это происходит.
Перенаправления ICMP в наши дни в основном не приветствуются по соображениям безопасности, поэтому такая настройка встречается редко.
На моем предприятии все шлюзы избыточны. Со стороны хоста мы установили шлюз на 192.168.0.1, но это IP-адрес с балансировкой нагрузки, управляемый двумя маршрутизаторами, которые на самом деле 192.168.0.2 и 192.168.0.3. При traceroute исходящий пакет отправляется к месту назначения x.x.x.1, но ответный пакет IGMP приходит от x.x.x.2 или x.x.x.3 в зависимости от того, какой маршрутизатор активен. traceroute показывает исходный адрес IGMP.
Это мог быть ответ @MikeR. Также может быть, что ваша машина имеет маршрут к адресу 10.75.89.100, который не проходит через шлюз по умолчанию, а вместо этого проходит через 10.77.121.3. Проверьте таблицу маршрутизации вашего хоста, чтобы узнать, так ли это.
Я тоже столкнулся с той же проблемой. Я использую устройство Sonicwall между ними. Некоторые настройки брандмауэра заблокировали отображение IP в tracert.
Для этого войдите в DELL SONICWALL -> Настройки брандмауэра -> Дополнительно.
там включите проверку на уменьшение TTL IP для перенаправленного трафика в разделе «Предотвращение обнаружения», протестируйте его и дайте мне знать, что это полная помощь.
Я согласен с Райаном и думаю, что ваш компьютер анализирует вашу таблицу маршрутизации, и поэтому он не отправляет вас на шлюз по умолчанию. Вы можете использовать это для очистки таблицы маршрутов:
sudo ip route flush table main
Затем вы можете снова запустить это, чтобы убедиться, что ваша таблица маршрутов пуста:
route -n
Теперь вы можете сбросить настройки Интернета, чтобы таблица маршрутов получала значения по умолчанию, и ваша проблема будет решена.