Destination host unreachable что значит
- Destination host unreachable — адрес назначения недоступен
- Bad IP — неисправный IP-адрес
После установки и настройки UserGate Server, необходимо проверить доступ в сеть Интернет.
Наберите в командной строке ping www.UserGate.ru .
Любой компьютер в сети, кроме UserGate сервера, должен дать ответ
Pinging www.usergate.ru [198.63.210.238] with 32 bytes of data
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Если Вы задали неправильный шлюз, то должны поучить следующий ответ (шлюзом задан 192.168.0.51)
Pinging www.usergate.ru [198.63.210.238] with 32 bytes of data
Reply from 192.168.0.51: Destination host unreachable.
Reply from 192.168.0.51: Destination host unreachable.
Reply from 192.168.0.51: Destination host unreachable.
Reply from 192.168.0.51: Destination host unreachable.
Такой ответ означает, что DNS работает правильно. То есть DNS преобразовал URL в IP.
Если у Вас ответ:
Pinging www.usergate.ru [198.63.210.238] with 32 bytes of data
Reply from 198.63.210.238: bytes=32 time =10ms TTL=32
Reply from 198.63.210.238: bytes=32 time =10ms TTL=32
Reply from 198.63.210.238: bytes=32 time =10ms TTL=32
Reply from 198.63.210.238: bytes=32 time =10ms TTL=32
Значит, пользователь имеет свободный доступ в Интернет, например включен «Общий доступ в Интернет»
Маленькие секреты сетевых утилит. Интерпретируем вывод ping, traceroute и whois для отладки
Команды ping, traceroute и whois — в числе первых вещей, о которых узнают начинающие админы. Многие, кто не специализируется на сетях, ими и ограничиваются, и совершенно зря. С помощью стандартных инструментов можно извлечь гораздо больше информации о проблеме, чем может показаться.
ping
Команда ping example.com известна каждому, даже далекому от сетей человеку. Она отправляет удаленному хосту пакеты ICMP echo, на которые, по идее, он должен ответить таким же пакетом.
Однако этот протокол не просто так называется Internet Message Control Protocol. Его функции далеко не только диагностические, а диагностические функции куда шире, чем «ответил — не ответил».
Что может сказать ping?
Зачастую, если хост назначения недостижим, от ping действительно можно получить только request timeout и ничего больше. Если успешный ответ всегда исходит от самого хоста назначения, то сообщения об ошибках доставки — от промежуточных маршрутизаторов. По стандарту промежуточные маршрутизаторы могут, но не обязаны уведомлять отправителя. Часто и не уведомляют — по соображениям производительности, и обвинить их не в чем.
Но уж если тебе пришел ответ от промежуточного маршрутизатора, он обычно информативен. К примеру, ответ destination host unreachable должен отправляться только тогда, когда хост находится в одной локальной сети с маршрутизатором и не отвечает. Самый простой способ увидеть эту ошибку — пингануть заведомо несуществующий адрес в своей же сети: к примеру, если твоя сеть 192.168.0.0/24 и хоста 192.168.0.200 в ней нет, выполнить ping 192.168.0.200 .
Такой ответ может прийти только от последнего маршрутизатора на пути к хосту.
А вот network unreachable говорит об отсутствии маршрута к указанной сети у одного из хостов на пути. Эта ошибка может возникнуть в любом месте пути, поэтому нужно обратить внимание на отправителя.
Чаще всего эта проблема у тебя самого: слетели настройки маршрутов или хост не получил маршрут от сервера DHCP. Но такой ответ может прийти и от промежуточного маршрутизатора:
From 192.0.2.100 icmp_seq=1 Destination Net Unreachable Если ты видишь такую картину, что-то серьезно пошло не так. Если хост достижим из других сетей, вполне возможно, что у провайдера проблема с настройками BGP. Я как минимум один раз сталкивался с тем, что крупный провайдер ошибочно фильтровал маршруты из сети, которую он считал зарезервированной для использования в будущем, хотя на тот момент IANA уже полгода как передала ее RIPE NCC и многие люди получили адреса из нее.
WWW
Если не хочешь быть как тот провайдер, можно воспользоваться автоматически обновляемыми списками несуществующих адресов вроде Cymru Bogon Reference
Ошибки семейства destination host/net prohibited означают, что пакет был отброшен правилом межсетевого экрана. Впрочем, никто не обязывает отвечать отправителю именно так или вообще отвечать. К примеру, в Linux правила вида iptables -j REJECT по умолчанию выдают destination port unreachable , если явно не указать —reject-with , причем указать можно любой тип, даже icmp-net-unreachable .
Но это все о простом ping без опций. Некоторые проблемы лучше всего выявляются дополнительными опциями.
Присоединяйся к сообществу «Xakep.ru»!
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Destination Host Unreachable
Имеется одноплатный ПК с внешней USB сетевой картой на котором стоит Linux, монитора и клавиатуры у него нет. Он напрямую соединен с рабочим ПК. После включения одноплатного ПК со вставленным сетевым проводом, либо вставленным после включения, все работает как положено. Пинги до рабочего ПК идут. Стоит выдернуть кабель, вернуть на место и получаю ошибку «Destination Host Unreachable».
PING 192.168.137.1 (192.168.137.1) 56(84) bytes of data. 64 bytes from 192.168.137.1: icmp_seq=1 ttl=128 time=1.12 ms 64 bytes from 192.168.137.1: icmp_seq=2 ttl=128 time=0.517 ms 64 bytes from 192.168.137.1: icmp_seq=3 ttl=128 time=0.568 ms ping: sendmsg: Network is unreachable … ping: sendmsg: Network is unreachable From 192.168.137.120 icmp_seq=14 Destination Host Unreachable From 192.168.137.120 icmp_seq=15 Destination Host Unreachable При этом на рабочем ПК в Wireshark я вижу ARP запросы, вижу что он отвечает, но получается что до одноплатного ПК ответы не доходят или игнорируются?!
Настройки одноплатного ПК:
#/etc/network/interfaces allow-hotplug eth0 auto eth0 iface eth0 inet manual #/etc/dhcpcd.conf interface eth0 static ip_address=192.168.137.120/24 static routers=192.168.137.1 $ ifconfig eth0 eth0: flags=4163 mtu 1500 inet 192.168.137.120 netmask 255.255.255.0 broadcast 192.168.137.255 inet6 fe80::d145:a15c:798a:6f0a prefixlen 64 scopeid 0x20 ether aa:29:6a:8a:30:a0 txqueuelen 1000 (Ethernet) RX packets 75 bytes 5940 (5.8 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 446 bytes 22854 (22.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 В чем может быть проблема?
BerZerKku
07.02.20 07:28:39 MSK
у меня тоже не отрабатывает на одном серваке auto eth0 при падении линка, помогает лишь перезапуск, думаю какой-то баг. За 7 лет так и не разобрался почему.
anonymous
( 07.02.20 07:53:23 MSK )
Запусти tcpdump на одноплатнике, проверь, доходят ли до него арп ответы. Посмотри арп таблицу на одноплатнике.
iliyap ★★★★★
( 07.02.20 08:16:11 MSK )
А разве оно вот так должно работать?
Я то думал что либо allow-hotplug либо auto
#/etc/network/interfaces allow-hotplug eth0 auto eth0 iface eth0 inet manual i3wm
( 07.02.20 11:38:48 MSK )
Interfaces marked "allow-hotplug" are brought up when udev detects them. This can either be during boot if the interface is already present, or at a later time, for example when plugging in a USB network card. Please note that this does not have anything to do with detecting a network cable being plugged in. i3wm
( 07.02.20 11:44:08 MSK )
Ответ на: комментарий от iliyap 07.02.20 08:16:11 MSK
Вот результаты команд arp и tcpdump. Логи tcpdump сняты при запущенном на рабочем ПК ping 192.168.137.120 (IP одноплатника).
// После манипуляции с кабелем. $ arp -a ? (192.168.137.1) at on eth0 $ sudo tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 03:55:48.161007 IP 192.168.137.1 > 192.168.137.120: ICMP echo request, id 1, seq 3917, length 64 03:55:48.161097 IP 192.168.137.120 > 192.168.137.1: ICMP echo reply, id 1, seq 3917, length 64 03:55:48.163251 IP 192.168.137.120.36886 > dns.google.domain: 9529+ PTR? 1.137.168.192.in-addr.arpa. (44) 03:55:48.206884 IP dns.google.domain > 192.168.137.120.36886: 9529 NXDomain 0/0/0 (44) 03:55:48.207284 IP 192.168.137.120.36898 > dns.google.domain: 22125+ PTR? 120.137.168.192.in-addr.arpa. (46) 03:55:48.251210 IP dns.google.domain > 192.168.137.120.36898: 22125 NXDomain 0/0/0 (46) 03:55:48.251662 IP 192.168.137.120.45454 > dns.google.domain: 45970+ PTR? 8.8.8.8.in-addr.arpa. (38) 03:55:48.296910 IP dns.google.domain > 192.168.137.120.45454: 45970 1/0/0 PTR dns.google. (62) 03:55:49.162859 IP 192.168.137.1 > 192.168.137.120: ICMP echo request, id 1, seq 3918, length 64 03:55:49.163010 IP 192.168.137.120 > 192.168.137.1: ICMP echo reply, id 1, seq 3918, length 64 03:55:50.168649 IP 192.168.137.1 > 192.168.137.120: ICMP echo request, id 1, seq 3919, length 64 03:55:50.168746 IP 192.168.137.120 > 192.168.137.1: ICMP echo reply, id 1, seq 3919, length 64 // Видимо тут был выдернут и вставлен обратно кабель 03:55:54.363115 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 03:55:54.367534 ARP, Request who-has 192.168.137.120 tell 0.0.0.0, length 28 03:55:54.655089 IP6 :: > ff02::1:ff43:bf6e: ICMP6, neighbor solicitation, who has fe80::b9e1:410b:9643:bf6e, length 32 03:55:54.799041 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 03:55:55.719424 IP6 fe80::b9e1:410b:9643:bf6e > ip6-allrouters: ICMP6, router solicitation, length 16 03:55:55.719757 IP6 fe80::b9e1:410b:9643:bf6e > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 03:55:55.802877 ARP, Request who-has 192.168.137.120 tell 0.0.0.0, length 28 03:55:55.999085 IP6 fe80::b9e1:410b:9643:bf6e > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 03:55:56.504948 IP6 fe80::b9e1:410b:9643:bf6e.mdns > ff02::fb.mdns: 0*- [0q] 2/0/0 (Cache flush) PTR raspberrypi.local., (Cache flush) AAAA fe80::b9e1:410b:9643:bf6e (143) 03:55:57.120442 ARP, Request who-has 192.168.137.120 tell 0.0.0.0, length 28 03:55:58.701753 IP6 fe80::b9e1:410b:9643:bf6e.mdns > ff02::fb.mdns: 0*- [0q] 2/0/0 (Cache flush) PTR raspberrypi.local., (Cache flush) AAAA fe80::b9e1:410b:9643:bf6e (143) 03:55:59.125783 ARP, Request who-has 192.168.137.120 tell 192.168.137.120, length 28 03:55:59.127125 IP 192.168.137.120 > 224.0.0.22: igmp v3 report, 1 group record(s) 03:55:59.128771 ARP, Request who-has 192.168.137.1 tell 192.168.137.120, length 28 27 packets captured 49 packets received by filter 16 packets dropped by kernel BerZerKku
( 10.02.20 07:06:03 MSK ) автор топика
Ответ на: комментарий от i3wm 07.02.20 11:38:48 MSK
Пробовал разные комбинации данных команд, разницы в работе не заметил.
BerZerKku
( 10.02.20 07:06:50 MSK ) автор топика
Ответ на: комментарий от BerZerKku 10.02.20 07:06:50 MSK
В мане по ссылке сказано, что allow-hotplug реагирует на подключение USB-сетевой, однако, это никак не связано с подключением кабеля в существ. интерфейс.
Please note that this does not have anything to do with detecting a network cable being plugged in.
Так, что по факту нужно придумать или найти какой-то ifplugd
https://linux.die.net/man/8/ifplugd
i3wm
( 10.02.20 16:46:12 MSK )
Ответ на: комментарий от BerZerKku 10.02.20 07:06:03 MSK
ARP ответов не видно. Ни от одноплатника, ни от ПК. А вот этот запрос:
03:55:59.125783 ARP, Request who-has 192.168.137.120 tell 192.168.137.120, length 28 вообще внушает. Спрашивает у сети свой собственный мак адрес. Что-то не так с настройками сети у этого одноплатника… Покажи
ip -0 addr ls ip -4 addr ls ip -4 nei ls nud all ip -4 ro ls ip -4 ru ls до отключения кабеля, после отключения кабеля, после подключения кабеля.
ARP лучше слушать вот так, чтоб не ловить весь мусор:
tcpdump -npe -i eth0 arp iliyap ★★★★★
( 10.02.20 19:22:07 MSK )
Ответ на: комментарий от iliyap 10.02.20 19:22:07 MSK
Этим сообщение одноплатный ПК оповещает всех что занял данный IP.
Ситуация такая, что если запустить пинг на одноплатном ПК, то на рабочий они доходят и он отвечает. Получается что одноплатный ПК после переключения кабеля либо вообще ничего не принимает с линии, либо игнорирует все сообщения. Логи tcpdump выше взяты с одноплатного ПК.
Кабель подключен (нормальная работа).
$ ip -0 addr ls 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: net2: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:80:0f:78:01:00 brd ff:ff:ff:ff:ff:ff $ ip -4 addr ls 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: net2: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 192.168.137.120/24 brd 192.168.137.255 scope global noprefixroute net2 valid_lft forever preferred_lft forever $ ip -4 nei ls nud all 224.0.0.251 dev net2 lladdr 01:00:5e:00:00:fb NOARP 224.0.0.22 dev net2 lladdr 01:00:5e:00:00:16 NOARP 192.168.137.1 dev net2 lladdr 28:3b:82:c7:f0:55 REACHABLE $ ip -4 ro ls default via 192.168.137.1 dev net2 src 192.168.137.120 metric 202 192.168.137.0/24 dev net2 proto dhcp scope link src 192.168.137.120 metric 202 $ ip -4 ru ls 0: from all lookup local 32766: from all lookup main 32767: from all lookup default $ ip -0 addr ls 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: net2: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 00:80:0f:78:01:00 brd ff:ff:ff:ff:ff:ff $ ip -4 addr ls 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever $ ip -4 nei ls nud all 224.0.0.22 dev net2 lladdr 01:00:5e:00:00:16 NOARP $ ip -4 ro ls $ ip -4 ru ls 0: from all lookup local 32766: from all lookup main 32767: from all lookup default Кабель снова подключен (связь не работает).
$ ip -0 addr ls 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: net2: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:80:0f:78:01:00 brd ff:ff:ff:ff:ff:ff $ ip -4 addr ls 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: net2: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 192.168.137.120/24 brd 192.168.137.255 scope global noprefixroute net2 valid_lft forever preferred_lft forever $ ip -4 nei ls nud all 224.0.0.251 dev net2 lladdr 01:00:5e:00:00:fb NOARP 0.0.0.0 dev lo lladdr 00:00:00:00:00:00 NOARP 224.0.0.22 dev net2 lladdr 01:00:5e:00:00:16 NOARP 192.168.137.1 dev net2 INCOMPLETE $ ip -4 ro ls default via 192.168.137.1 dev net2 src 192.168.137.120 metric 202 192.168.137.0/24 dev net2 proto dhcp scope link src 192.168.137.120 metric 202 $ ip -4 ru ls 0: from all lookup local 32766: from all lookup main 32767: from all lookup default ping response «Request timed out.» vs «Destination Host unreachable»
When I ping an IP address, what is the difference between Request timed out and Destination host unreachable returned from the command?
28.7k 16 16 gold badges 75 75 silver badges 90 90 bronze badges
asked Mar 1, 2014 at 5:36
Suresh Kumar Veluswamy Suresh Kumar Veluswamy
4,193 2 2 gold badges 20 20 silver badges 35 35 bronze badges
5 Answers 5
Destination Host Unreachable
This message indicates one of two problems: either the local system has no route to the desired destination, or a remote router reports that it has no route to the destination.
If the message is simply «Destination Host Unreachable,» then there is no route from the local system, and the packets to be sent were never put on the wire.
If the message is «Reply From < IP address >: Destination Host Unreachable,» then the routing problem occurred at a remote router, whose address is indicated by the «< IP address >» field.
Request Timed Out
This message indicates that no Echo Reply messages were received within the default time of 1 second. This can be due to many different causes; the most common include network congestion, failure of the ARP request, packet filtering, routing error, or a silent discard.