Destination host unreachable linux как исправить

I have two ubuntu computers on a local network and neither one of them can ping each other. Every time I try I get the «destination host unreachable» error message. Both computers are able to access the internet with any problems.

I have a ActionTech v1000h router from Telus. I’ve been in touch with one of their customer representatives and they said that there should’t be any reason why two devices cannot ping each other on the network.

I’m totally at a loss, do any of you guys have any ideas?

Computer 1:

ifconfig -a

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:10084 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10084 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:797420 (797.4 KB)  TX bytes:797420 (797.4 KB)

wlan0     Link encap:Ethernet  HWaddr c4:85:08:77:d3:f5  
          inet addr:192.168.1.77  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::c685:8ff:fe77:d3f5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:373068 errors:0 dropped:0 overruns:0 frame:0
          TX packets:380158 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:103445020 (103.4 MB)  TX bytes:112630337 (112.6 MB)

route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG    0      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     9      0        0 wlan0

sudo iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  

Computer 2:

ifconfig -a

etho0     Link encap:Ethernet HWaddr 00:24:8c:ae:f6:91
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:2
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:110 errors:0 dropped:0 overruns:0 frame:0
          TX packets:110 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:8414 (8.4 KB)  TX bytes:8414 (8.4 KB)

wlan0     Link encap:Ethernet  HWaddr 00:22:43:9b:7b:64  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::222:43ff:fe9b:7b64/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:252 errors:0 dropped:0 overruns:0 frame:0
          TX packets:435 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:123143 (123.1 KB)  TX bytes:65828 (65.8 KB)

route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG    0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     9      0        0 wlan0

sudo iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  

Edit: Example of the error when computer 1 tries to ping computer 2:

ping 192.168.1.2

PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
From 192.168.1.77 icmp_seq=1 Destination Host Unreachable
From 192.168.1.77 icmp_seq=2 Destination Host Unreachable
From 192.168.1.77 icmp_seq=3 Destination Host Unreachable
From 192.168.1.77 icmp_seq=4 Destination Host Unreachable
From 192.168.1.77 icmp_seq=5 Destination Host Unreachable
From 192.168.1.77 icmp_seq=6 Destination Host Unreachable
^C
--- 192.168.1.2 ping statistics ---
7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 6031ms
pipe 3

Edit 2: arp -a of both computers

Computer 1:

? (192.168.1.254) at 20:76:00:f5:3b:70 [ether] on wlan0

Computer 2:

? (192.168.1.254) at 20:76:00:f5:3b:70 [ether] on wlan0
? (192.168.1.77) at <incomplete> on wlan0

Edit 3: nmap -sn 192.168.1.0/24 on computer 2

Starting Nmap 6.40 ( http://nmap.org ) at 2014-05-07 21:14 PDT
Nmap scan report for 192.168.1.2
Host is up (0.00024s latency).
Nmap done: 256 IP addresses (1 host up) scanned in 3.30 seconds

Edit 4: The tcpdump logs of both computers while the first ping 192.168.1.254 and then each other:

Computer 1:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:45:01.661300 ARP, Request who-has 192.168.1.2 tell 192.168.1.77, length 28
22:45:02.659393 ARP, Request who-has 192.168.1.2 tell 192.168.1.77, length 28
22:45:03.659394 ARP, Request who-has 192.168.1.2 tell 192.168.1.77, length 28
22:45:04.676872 ARP, Request who-has 192.168.1.2 tell 192.168.1.77, length 28
22:45:05.675391 ARP, Request who-has 192.168.1.2 tell 192.168.1.77, length 28
22:45:06.675396 ARP, Request who-has 192.168.1.2 tell 192.168.1.77, length 28
22:45:07.692825 ARP, Request who-has 192.168.1.2 tell 192.168.1.77, length 28
22:45:48.379058 ARP, Request who-has 192.168.1.77 tell 192.168.1.254, length 28
22:45:48.379108 ARP, Reply 192.168.1.77 is-at c4:85:08:77:d3:f5, length 28
22:45:54.419388 ARP, Request who-has 192.168.1.254 tell 192.168.1.77, length 28
22:45:54.420875 ARP, Reply 192.168.1.254 is-at 20:76:00:f5:3b:70, length 28

Computer 2:

reading from file pc2.pcap, link-type EN10MB (Ethernet)
22:44:43.538367 ARP, Request who-has 192.168.1.254 tell 192.168.1.2, length 28
22:44:43.676705 ARP, Reply 192.168.1.254 is-at 20:76:00:f5:3b:70 (oui Unknown), length 28
22:45:02.107935 ARP, Request who-has 192.168.1.254 tell 192.168.1.2, length 28
22:45:02.107951 ARP, Reply 192.168.1.254 is-at 20:76:00:f5:3b:70 (oui Unknown), length 28
22:45:06.780619 ARP, Request who-has 192.168.1.77 tell 192.168.1.2, length 28
22:45:07.778419 ARP, Request who-has 192.168.1.77 tell 192.168.1.2, length 28
22:45:08.778419 ARP, Request who-has 192.168.1.77 tell 192.168.1.2, length 28
22:45:09.796214 ARP, Request who-has 192.168.1.77 tell 192.168.1.2, length 28

Edit 5: Setup static ips for both computers etho0 and connected them with an internet cable. Both computers can definitely ping each other through the ethernet cable! ifconfig -a eth0 results:

Computer 1:

eth0      Link encap:Ethernet  HWaddr 68:68:68:00:62:a4  
          inet addr:192.168.1.10  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::6a68:68ff:fe00:62a4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4060 (4.0 KB)  TX bytes:7629 (7.6 KB)

Computer 2:

eth0      Link encap:Ethernet  HWaddr 00:24:8c:ae:f6:91  
          inet addr:192.168.1.20  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::224:8cff:feae:f691/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:250 errors:0 dropped:0 overruns:0 frame:0
          TX packets:130 errors:0 dropped:0 overruns:0 carrier:3
          collisions:0 txqueuelen:1000 
          RX bytes:26501 (26.5 KB)  TX bytes:20897 (20.8 KB)

Страницы: [1] 2  Все   Вниз

0 Пользователей и 2 Гостей просматривают эту тему.

Страницы: [1] 2  Все   Вверх

Do you know the most difficult part of the job of a network engineer? You are responsible for every issue related to networking in your company. Even though everything works fine, someone will come up with a complaint, and it is on our head to fix it.

While I was working as a network engineer trainee, I received a call from the development section. The manager on Duty in the development section was angry and said that the network was not working.

When I asked him about the issue, he said the Internet is just fine, but one of his teammates received an error while pinging to a device in his subnet.

His teammate received the Destination Host Unreachable reply while he tried to ping to another computer in his section.

The manager on Duty demanded an explanation for the Destination Host Unreachable. I explained to him the reasons to receive Destination Host Unreachable error messages with examples. If you have not seen this error message before, have a look at the screenshot attached below.

What Is The Reason to Receive Destination Host Unreachable Error Message?

If you want a one-sentence answer, look at the statement in the table.

Let me explain with the example I showed above. When I sent Ping packets to the IP address 192.168.225.45 from my computer, it looked at the ARP table stored in my PC to fetch the MAC address associated with the destination IP Address.

You know the basic rule of network communication. You cannot send packets to an IP Address before finding the MAC address (Physical Address) of the destination device.

ARP table shows the MAC address of the devices assigned with the specific IP Address.

If you do not know this concept, there are tons of tutorials available about Address Resolution Protocol (ARP) on the Internet.

My computer could not find the ARP Address mapped to the IP Address 192.168.225.45 in the ARP table.

C:systosys>ping 192.168.225.45

Pinging 192.168.225.45 with 32 bytes of data:
Reply from 192.168.225.47: Destination host unreachable.
Reply from 192.168.225.47: Destination host unreachable.
Reply from 192.168.225.47: Destination host unreachable.
Reply from 192.168.225.47: Destination host unreachable.

Ping statistics for 192.168.225.45:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:systosys>Destination Host Unreachable

So it displayed Reply from 192.168.225.47: Destination host unreachable as the response.

How to Fix Destination Host Unreachable?

If you do not know how to fix the reply from the x.x.x.x destination host unreachable message, follow the instructions provided below.

1. Flush the ARP Cache

   The first step to troubleshoot the Reply from 192.168.225.47: Destination host unreachable error is by deleting all entries in the ARP table on your computer.

   • Open the Command Prompt as Administrator
     1. Type cmd on the Windows Search
     2. Right Click on the Command Prompt from the Search Window
     3. Click on the Run as Administrator option

   • Type the following command and press enter

     netsh interface ip delete arpcache

   • Try ping the same IP address again and check for the issue.
2. Run a Traceroute

   If the problem persists, you should run a traceroute to pinpoint the problem location.

   1. Open Command Prompt
   2. Type the following command and press the enter key.

      tracert 192.168.225.45

   3. Check the result to understand the reason for the Destination Host Unreachable message.

      

   Why do I receive the ping reply Destination Host Unreachable? The traceroute result shows there is no such destination device.

3. Disable the Firewall on your PC

   In my experience, some users said faulty Firewall settings caused the Destination Host Unreachable error. So, I suggest you turn off the firewall on your laptop and check for the issue.

4. Check the Status of the Destination Device and Test the Connection

   If the destination device is in your reach, make sure the device is on. Make sure the network connection is fine.

   You may unplug and replug the network cable to verify the connection status.

How to Check if Destination a Host Unreachable Error is Resolved?

It is very simple. You need to ping the same IP Address.

If the error is at the side of the IP Address, you should try to ping a different IP Address or domain name.

For example, check the command below to test whether the Destination a Host Unreachable Error fixed or not.

ping www.systosys.com

During my network engineer career, one of the common errors I received while troubleshooting connectivity issues is Destination Host Unreachable.

This error was the cause of my Internet connectivity problems most times.

The same can be true for you too. When you troubleshoot your connectivity problems, the chances of getting this ping reply are very high.

If you learn how to resolve this error by yourself, you can fix most of your Internet connectivity problems yourself. In this tutorial, I will explain everything about this error.

By the first part, you will learn the meaning of this ping reply.

The second part of this article explains the reasons to get the ping reply Destination Host Unreachable.

You will learn how to fix the Destination Host Unreachable ping error in the last part.

What does Destination Host Unreachable Ping Reply Mean?

Before proceeding to the core of this tutorial, let me explain the meaning of this ping reply.

The Destination Host Unreachable error tells that the ping packets from your computer cannot find a route to the destination IP address(destination host).

Now you understand the meaning of this ping reply. However, to learn more about this error, you should ask yourself two questions.

1. Who replied to your device this Destination Host Unreachable message?
2. Why the ping packets from your computer failed to reach the destination address?

Let me answer the questions one by one. But before I explain the first question, you must learn how the ping operation works.

When you ping an address, this is how it works.

• I am pinging to my blog by typing ping www.corenetworkz.com on command prompt.
• Ping packets reach the default gateway
• Checking the ARP table and Routing table
• Finding a route to the Remote Gateway of the destination IP address
• Remote Gateway forwards the ping packets to the destination host
• Remote host reply with an acknowledgment

Can you tell me the potential sources for a Destination Host Unreachable reply from this ping workflow algorithm?

You can get this reply from two possible sources.

1. Your Default Gateway
2. Destination Gateway

How do you know whether the reply comes from your default gateway or remote gateway?

Well, it is simple. All you have to do is to analyze the ping reply carefully. Check the format of the message. Two types of error messages are common on Windows devices.

1. Reply from x.x.x.x Destination Host Unreachable

   If you see the following format, check the IP address. Most of the time, X.X.X.X must be a remote gateway address. Which shows the error message you received is from the remote gateway.

2. Destination Host Unreachable

   If you don’t see an IP address in the error reply, your default gateway sends it.

Both error formats have different reasons. I will explain the reasons to get either format in the next part.

Reasons to Get the ICMP Error Destination Host Unreachable

Any one of the reasons listed below can get you to the ICMP Echo message Destination Host Unreachable.

1. Your Default Gateway doesn’t know the route to the destination IP address
2. Packet Routing issue on Remote gateway
3. The destination host might be down
4. Loose Connection
5. Wrong Firewall Settings

One of the frequent questions I received from our readers is whether this error is related to the Operating System like Windows error and Linux error?

The answer is no.

Analyzing the ICMP Echo Destination Host Unreachable

Let me explain why I received this ICMP Echo by analyzing a live example.

Here I send ping packets to the global DNS address 4.2.2.2 to troubleshoot the connectivity problem. The screenshot below shows the reply I received.

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:corenetworkz;ping 4.2.2.2

Pinging 4.2.2.2 with 32 bytes of data:

Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

Ping statistics for 4.2.2.2:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:corenetworkz>

Which format is this? It is the second format of the Destination Host Unreachable error. Let me explain how to resolve this error.

How to Fix Ping Error Destination Host Unreachable?

If you do not want to go into the complexity of this ICMP Echo, you can follow the instructions below to resolve the Destination Host Unreachable Ping error message.

1. Disable the firewall

   Aggressive firewall settings can cause the destination host unreachable error.

   To check whether the firewall is the reason for this issue, disable it on your computer.

   Try to access the Internet after disabling the firewall.

2. Perform a Power Cycle in your Network
   • Switch off the devices on your network
   • Disconnect power cables from Modem and Router
   • Disconnect the Ethernet cables from Modem, Computer, and Router
   • Reconnect the power and ethernet cables
   • Power on the Modem and Router after one minute
3. Disable IPv6 and Test the Connectivity

   Sometimes devices fell into the IP version conflicts. Different operating systems have different IP version priorities.

   Windows 10 prefer IPv6 to IPv4. The same is true for the major Linux variants like Ubuntu, Fedora, Debian, etc.

   However, sometimes devices fail to work properly with IPv6.

   Rarely it results in ICMP error messages. We can check it by disabling the IPv6 on your device.

   Let us check how to disable the IP Version 6 on a Windows 10 computer and test the issue.

   • Right-click on the Network Adapter at the system tray
   • Click on Open Network & Internet settings

   • Click on Change Adapter options

   • Right Click on the current connection and click properties
   • Uncheck the Internet Protocol Version 6 (TCP/IPv6)

   • Click OK
   • Reboot your Computer

   Once you reboot your computer, check for the connection.

«Destination Host Unreachable» and ssh » No route to host»

При попытке пинга с Убунты локальной машины центос пишет

При попытке подключиться по ssh

На центосе стоит 2 сетевые карты с этими айпи. И нету подключения к интернету.

При попытке пинга с Убунты локальной машины центос пишет

Чего? Ты с локальной машины с убунтой пингуешь сам себя и тебе отвечает центос?

Я с Убунты(192.168.8.101) пытаюсь пинговать центос(192.168.100.166 и 192.168.8.1) На центосе установлены 2 сетевые карты с такими айпи. К 166 подключен кабель от глобальной сетки, а со второй карты идет кабель в роутер и от роутера второй кабель идет в убунту.

Не судите, но тут думаю есть проблема.

Ну так у Вас просто сеть не работает.

Начинать надо сначала — приведите список и параметры сетевых интерфейсов на локальной машине (команда ifconfig), а также таблицу маршрутизации (команда ip route).

Ну и проверьте, есть ли сеть физически (в логах dmesg должны быть строчки, что сетевые интерфейсы подняты).

Это с какой машины таблица маршрутизации?

фаерволы на обеих машинах выключил?

С обеих машин
ip a
ip r
ip ru
ip r g адрес_другого_компуктера
iptables-save

Во-первых, где шлюз по умолчанию?

Во-вторых, я правильно понимаю, что enp2s5 имеет адрес 192.168.100.166, а enp2s2 — 192.168.8.1?

Если это так, то что Вы хотите сказать вот этой строкой:

Вот это тоже лишнее:

Вместо них добавьте шлюз по умолчанию

(ip route add default gw $IP)

где $IP — IP-адрес шлюза.

Впрочем, связь между Ubuntu и CentOS должна и без шлюза по умолчанию заработать.

Да выходит что s5=100.166, s1=8.1 Я убрал эти значения что вы указали как лишние. Какой тогда использовать шлюз?

Другая информация была выше.

Выходит что мне должен раздавать интернет 166 айпи, к которому и подключен сам по себе сетевой кабель. А 8.1 быть как проводником к роутеру и от роутера до машины убунты с айпи 8.101 Как я понимаю эту схему.

Приведите новую таблицу маршрутизации с CentOS.

Связь между Ubuntu и CentOS должна и без шлюза появиться — они у Вас в одной сети (192.168.8.0/24) находятся.

А по поводу шлюза — Вам виднее, как сеть организована. Через какую машину в в интернет выходите?

Я к роутеру подкидываю сетевой кабель, от которого ща и получаю интернет. А когда тестирую связь машин, то откидаю кабель.

Выходит что мне должен раздавать интернет 166 айпи, к которому и подключен сам по себе сетевой кабель.

В этом случае в сети 192.168.100.0/24 должен быть шлюз, через который идет интернет. Вот его и объявляйте шлюзом по умолчанию.

А 8.1 быть как проводником к роутеру и от роутера до машины убунты с айпи 8.101

А вот тут поподробнее, пожалуйста. Как физически организована сеть между CentOS и Ubuntu? Из Ваших конфигов следует, что эти машины находятся в одной локальной сети.

Если это так, то о каком роутере между ними идет речь? Если нет, то конфиги надо менять, но чтобы понять, как именно, надо знать физическую конфигурацию сети.

А когда тестирую связь машин, то откидаю кабель.

Я правильно понимаю, что машины CentOS и Ubuntu напрямую соединены сетевым кабелем? Без роутеров и свичей между ними?

Источник

Маленькие секреты сетевых утилит. Интерпретируем вывод ping, traceroute и whois для отладки

Содержание статьи

Команда 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. Но такой ответ может прийти и от промежуточного маршрутизатора:

Если ты видишь такую картину, что-то серьезно пошло не так. Если хост достижим из других сетей, вполне возможно, что у провайдера проблема с настройками BGP. Я как минимум один раз сталкивался с тем, что крупный провайдер ошибочно фильтровал маршруты из сети, которую он считал зарезервированной для использования в будущем, хотя на тот момент IANA уже полгода как передала ее RIPE NCC и многие люди получили адреса из нее.

Если не хочешь быть как тот провайдер, можно воспользоваться автоматически обновляемыми списками несуществующих адресов вроде Cymru Bogon Reference

Ошибки семейства destination host/net prohibited означают, что пакет был отброшен правилом межсетевого экрана. Впрочем, никто не обязывает отвечать отправителю именно так или вообще отвечать. К примеру, в Linux правила вида iptables -j REJECT по умолчанию выдают destination port unreachable , если явно не указать —reject-with , причем указать можно любой тип, даже icmp-net-unreachable .

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

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Источник

How to Solve Destination Net Unreachable — Ping Error Message

Destination Net Unreachable is one of the common ICMP error messages you see when you ping a remote IP address as part of a ping test in network troubleshooting.

This tutorial explains the meaning of the ICMP error message Destination Net Unreachable and teaches how to fix it.

The first part of this tutorial explains why do you receive Destination Net Unreachable error while you ping a web address. The second part of the tutorial explains how to solve this error.

Let us check what does the error message means?

What is The Meaning of the Ping reply Destination Net Unreachable?
This error message tells the ping request from your computer failed to find a route to the destination network.

Reasons for the ICMP echo Destination net unreachable
The ping packet couldn’t find the destination network due to any one of the following reasons.

Packet Routing issue

The destination network path might be down

Technical Explanation of Destination Net Unreachable Ping Reply
When you ping an IP address from your computer, the ping packet goes to the default gateway. The default gateway will send the ping packet to the destination address.

However, if the default gateway does not know the path to the desired network, your computer will get a Destination Net Unreachable message.

Have a look at the screenshot I uploaded below. I send ping packets to the global DNS address 4.2.2.2 from your computer.

However, the process went wrong and received the ping error Destination net unreachable on the command prompt.

Let me explain why I have received the reply from the IP address 192.168.42.129 when I send ping packets to 4.2.2.2.

Here I pinged the IP address 4.2.2.2 from my computer. The ping request went to the default gateway.

The default gateway in my network is a modem. The IP address of the modem is 192.168.42.129.

The modem failed to find a route to the destination network and replied to my computer with the Destination net unreachable message.

How to Fix the Ping Error Destination Net Unreachable?

I explained the reasons for the ping error Destination Net Unreachable in the first part of this tutorial. Now, let us check how to fix this problem.

I have created a troubleshooting guide for this purpose. I recommend you to follow the steps in the order provided below.

Power Cycle the Network:
A proper power cycle will refresh the routing table entry and fix loose connection problems. Follow the instructions provided below carefully.

• Switch off the devices on your network
• Disconnect power cables from Modem and Router
• Disconnect the Ethernet cables from Modem, Computer, and Router
• Reconnect the power and ethernet cables
• Power on the Modem and Router after one minute
• Check for the issue. If you still receive the same ICMP error, follow the net solution.

Delete the Local Hosts Entries
Third-party applications and malicious programs like viruses can rewrite the local host file on your Windows computer. A faulty entry on the local host file can prevent your Windows PC from accessing the Internet and results in Ping errors.

Let us check how to fix the Destination Net Unreachable error on Windows 10 computer by clearing the local host file.

• Go to the location C:WindowsSystem32driversetc
• Right-click on the hosts and open in a Notepad
• Delete the entries and save the file
• Now ping a remote IP address and check for the issue

Disable the Firewall
Security Applications installed on your device can cause ping error Destination Net Unreachable especially when you access the Internet over a VPN or Proxy.

To check whether the Firewall on your device causes ping errors, you need to disable it. To disable the inbuilt Firewall on Windows 10 and Windows 8, follow the instructions.

• Click on the Windows Start button
• Click Control Panel
• Click Windows Firewall
• Click the Turn Windows Firewall on or off option
• Click the Turn off Windows Firewall radio buttons both under the Private network settings and Public network settings under the Customize Settings
• Click the OK button to save the settings

I hope this tutorial has helped you to resolve the Destination net unreachable ICMP Error on your computer.

CoreNetworkZ has many tutorials covering similar ICMP error messages. Some of them are below.

Источник

«Destination Host Unreachable» and ssh » No route to host»

При попытке пинга с Убунты локальной машины центос пишет

При попытке подключиться по ssh

На центосе стоит 2 сетевые карты с этими айпи. И нету подключения к интернету.

Нужно прописать маршруты до сети 192.168.100.0 из сети 192.168.8.0 и маршрут до 192.168.8.0 из 192.168.100.0.

Для узлов в сети 192.168.100.0 прописывайте маршрут на их шлюзе, а для 192.168.8.101 прописывайте маршрут на нём.

На убунте использую

Обе сети должны знать как с друг другом связаться.

Т.е. на хостах 192.168.100.0 должен быть маршрут до 192.168.8.0 и на 192.168.8.0 должен быть маршрут до 192.168.100.0, если на всех хостах сети 192.168.100.0 шлюзом указан 192.168.100.254, то пропиши на нём маршрут до сети 192.168.8.0 через 192.168.100.166, а на 192.168.8.101 пропиши либо маршрут до сети 192.168.100.0 через 192.168.8.1, либо пропиши его шлюзом.

Ну и правила iptables тоже.

Затем разрешение продвижения пакетов нужно настроить через sysctl.

все работает на центосе и убунта пингует центос.

Отлично, рад за Вас.

Но вот на убунте нету интернета, а на центосе все есть.

Все верно, так и должно быть. Чтобы появился интернет, нужно NAT настроить. И лучше это делать не на CentOS, а на шлюзе во внешнюю сеть (возможно, в Вашем случае это машина 192.168.100.254). Потому что, если Вы настроите на CentOS, интернет на Ubuntu, конечно, появится, но технически пакеты будут подвергаться двойному NAT — один раз на CentOS и второй — на шлюзе (т. к. CentOS не имеет публичного IP). Так что если есть доступ к шлюзу, настраивайте NAT на нем. И не забудьте прописать маршруты в сеть 192.168.8.0/24.

Я не имею доступу к машине с айпи 254. Есть только 2 полигонные машины центос и убунту. Вот как советует Константин попрописую шлюзы и как я понимаю уж препятствий для получения интернета на убунте не должно быть. Сейчас построю цепочку связи сети и буду прописывать.

forward на центосе прописан 1 в самих конфигах.

В общем я использовал это

Я не имею доступу к машине с айпи 254.

iptables -A FORWARD -s 192.168.8.0/24 -d 192.168.100.0/24 -j ACCEPT
iptables -A FORWARD -s 192.168.100.0/24 -d 192.168.8.0/24 -j ACCEPT

Этого мало. Надо на машине с CentOS разрешить forward всего трафика из сети 192.168.8.0/24 в обоих направлениях.

И вот это лишнее:

iptables -t nat -A POSTROUTING -o enp1s1 -j MASQUERADE

Вам надо маскарадить трафик, который идет на Ваш шлюз (192.168.100.254). Чтобы он воспринимал трафик из сети 192.168.8.0.24 (про которую он ничего не знает) как исходящий с машины с CentOS. Поэтому оставляете это правило только на интерфейсе с IP-адресом 192.168.100.166.

После этого, по идее, на машине с Ubuntu должен появиться интернет.

Это все лучше сделать через создание таблицы и что бы оно работало после ребута системы

Этого мало. Надо на машине с CentOS разрешить forward всего трафика из сети 192.168.8.0/24 в обоих направлениях.

Этим вы говорите о какой именно команде?

Глупо конечно, но может быть тут мешается центосовский firewalld?

Чем он может мешать? Я думаю просто не все правила внес, потому и нету самого доступа к интернету.

Так как писал ранее пингуются машины между собой и 254 айпи так же с 8.8.8.8, а вот если пропинговать google.com или ya.ru и так же попытаться подключится на убунте к интернету, то глухо.

Подожди, у тебя пингуется с убунты 8.8.8.8?

а в /etc/resolv.conf что нибудь есть?

Я потому и не могу понять, если пингуется 8.8.8.8 то по сути должен же быть доступ к интернету, так как это гугловский айпи. Но вот прописав google.com или ya.ru, к примеру, я не получаю пинга и браузер молчит.

В таком случае, что выдает ping google.com?

Да и куда прописать

это IP ya.ru. если пинг есть, то у тебя проблема не в машрутах и форвардинге, а в настройках DNS

А чем сеть на центосе поднимается? NetworkManager?

Пинг по айпи идет на всех машинах, тогда где все таки это днс?

А чем сеть на центосе поднимается? NetworkManager?

Да, на NetworkManager

Дописал в конфиге на центосе днс и теперь пингуется гугл и я.ру. Но с убунты нету пинга. Хотя даже вбивал при подключении днс который добавлен на центосе.

Да и куда прописать. . Что бы после перезагрузки сохранялись настройки.

Я не знаю, как именно в Ubuntu это делается, но обычно существует файл /etc/rc.local или /etc/init.d/rc.local (зависит от настроек системы инициализации Вашего дистрибутива), который является исполняемым sh-скриптом, и куда можно добавлять свои команды.

В ubuntu у Вас в качестве DNS-сервера указана машина CentOS. Там действительно DNS-сервер запущен?

Хотя даже вбивал при подключении днс который добавлен на центосе.

Если на машине с Ubuntu в файл /etc/resolv.conf добавить строку (предварительно убрав/закомментировав все остальные):

доменные имена начинают разрешаться?

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

Нет, доменные имена не разрешаются. Все так же. Возможно нужно вбить дополнительную команду?

Погодите, Вы утверждаете, что машина 8.8.8.8 пингуется с Ubuntu? И при этом использовать ее в качестве DNS-сервера не получается?

Я правильно Вас понял? Тогда надо разбираться, что происходит с пакетами, отсылаемыми на 53 порт. Возможно, у Вас на шлюзе заблокированы DNS-запросы к внешним DNS-серверам.

Как проверить — запустить сниффер (например, tcpdump) и посмотреть, какие пакеты и куда идут при DNS-запросах. DNS-запросы можно генерировать командами host, nslookup или dig (см. соответствующие man’ы с описанием синтаксиса и ключей команд). Если запросы уходят, а ответов нет, Ваш шлюз блокирует DNS-запросы. В этом случае должен существовать собственный DNS-сервер в Вашей сети, стоит узнать его адрес у администратора и прописать в /etc/resolv.conf.

Да пинг идет. Вот что мы имеем.

И вот что мы имеем с Centos

И вот такая картина c Ubuntu

Очевидно, кто-то рубит пакеты, идущие на 53 порт с машины с Ubuntu. И скорее всего, это происходит на машине с CentOS. Если на ней tcpdump запустить в момент DNS-запросов с Ubuntu, что будет? Последовательно на двух интерфейсах — сначала на том, который в одной сети с Ubuntu, потом на внешнем.

Ну и еще раз призываю разрешить форвардинг всех пакетов на CentOS (сделать политику по умолчанию в цепи FORWARD ACCEPT).

Centos ip — 100.166

На 8.1 просто летят логи, а на 100.166 только это.

Вот что получилось.

Я так и не понял из треда, тебе нужны фаерволы на обоих ПК? Если нет, то отключи их.

Мне нужно настроить сеть в которой моя машина на убунте будет получать интернет от центоса на которой 2 сетевухи и в дальнейшем при запросе 192.168.100.166:10022 выполнялся запрос как 192.168.8.101:22 (ssh)

Не, это неинформативно. В первом случае все забито пакетами ssh — я так понимаю, что Вы не за консолью сидите на CentOS, а по ssh туда заходите. Ограничьте tcpdump по протоколу (udp) и порту (53) — нас сейчас именно dns-пакеты интересуют. Нужен трафик, снятый в момент dns-запросов с Ubuntu. С обоих интерфейсов CentOS.

Вот когда я пытаюсь пингонуть google.com

В общем, все подтверждается — машина с centOS блокирует DNS-запросы.

Смотрите настройки файрвола на CentOS.

Еще был вариант что сторонние программы мешали. Но я стопнул и перепроверил. Не дало результата. На счет настройки файрвола, что именно может блокировать?

На счет настройки файрвола, что именно может блокировать?

Я Вам несколько раз уже про это писал — проверьте параметры цепочки forward. Для начала установите политику по умолчанию для этой цепи на пропуск всех пакетов (iptables -P FORWARD ACCEPT). Если поможет, значит, Вы нашли виновника, надо детально разбираться в настройках iptables на машине с CentOS.

Да я прописывал и данную команду, но видимо что то могу упускать. Пересмотрел доки и все команды которые могли бы помочь были использованы и опробованы. Я вижу что вы пишите и ценю ваши порывы помочь мне. Просто я хочу до конца разобраться в этом и доделать. Просто из-за моего «опыта», которого нет в этом направлении, мне сложнее быстрее адаптироваться и направиться в нужном направлении.

Пробовал так прописывать.

Рад за Вас. Правда, не понял, зачем Вы сервисы поостанавливали.

По поводу настроек iptables. Все Ваши записи с модификациями цепочки FORWARD (iptables -A FORWARD. ) в данном контексте бессмысленны, т. к. политика по умолчанию задана на пропуск пакетов.

Тут есть два варианта. Если Вы полностью доверяете машинам в сети 192.168.8.0, то можете так и оставить настройки. При этом все правила модификации цепи FORWARD можно убрать, оставить только задание политики (iptables -P FORWARD ACCEPT).

Ну и второй вариант — разрешить форвардинг только тех портов и протоколов, которые необходимы. Например, полезно закрыть соединения на 25 порт tcp-протокола, исходящие с машин сети 192.168.8.0/24 — этим Вы нейтрализуете активность спамовых бот-сетей, которые могут завестись на машинах сети 192.168.8.0/24.

Если Вы пойдете по этому варианту, то нужно будет вернуть политику по умолчанию для цепи FORWARD в состояние DROP и тщательно настроить саму цепь с помощью iptables.

Источник