- «No route to host» when I do a telnet [closed]
- Telnet no route to host linux
- Check RunBook Match
- Initial Steps Overview
- Detailed Steps
- 1) Gather information
- 1.1) Determine the host
- 1.2) Determine the IP
- 1.3) Determine the port
- 1.4) Determine the frequency of the problem
- 2) Is host up?
- 2.1) Use nmap
- 2.2) Use ping
- 2.3) Use nmap on the IP
- 3) Is the port open?
- 3.1) From client
- 3.2) From remote host
- 3.3) Conclusions
- 4) Check IPTables / NetFilter
- 5) Check routing tables
- 6) Check intervening firewalls
- Check Resolution
- Further Steps
- Further Information
- Почему ping видит хост, а telnet — нет?
«No route to host» when I do a telnet [closed]
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
telnet 10.10.1.9 2181 Trying 10.10.1.9. telnet: connect to address 10.10.1.9: No route to host
#tcpdump -i eth0 port 2181 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 07:55:35.530270 IP 10.10.1.6.55910 > 10.10.1.9.eforward: Flags [S], seq 1018543857, win 14600, options [mss 1418,sackOK,TS val 181360935 ecr 0,nop,wscale 7], length 0
tcpdump -i eth0 port 2181 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 07:55:57.970696 IP 10.10.1.6.55910 > 10.10.1.9.eforward: Flags [S], seq 1018543857, win 14600, options [mss 1460,sackOK,TS val 181360935 ecr 0,nop,wscale 7], length 0
#tcpdump -i eth0 port 2181 or arp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:00:18.356153 IP 10.10.1.6.55944 > 10.10.1.9.eforward: Flags [S], seq 3337054296, win 14600, options [mss 1418,sackOK,TS val 181643770 ecr 0,nop,wscale 7], length 0 08:00:42.294801 ARP, Request who-has 10.10.1.6 tell 10.10.1.9, length 28 08:00:42.295859 ARP, Reply 10.10.1.6 is-at 12:34:56:78:9a:bc (oui Unknown), length 28
tcpdump -i eth0 port 2181 or arp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 08:00:40.805565 IP 10.10.1.6.55944 > 10.10.1.9.eforward: Flags [S], seq 3337054296, win 14600, options [mss 1460,sackOK,TS val 181643770 ecr 0,nop,wscale 7], length 0 08:00:45.805204 ARP, Request who-has 10.10.1.9 tell 10.10.1.6, length 28 08:00:45.805721 ARP, Reply 10.10.1.9 is-at 12:34:56:78:9a:bc (oui Unknown), length 28 08:02:04.752283 ARP, Request who-has 10.10.1.9 tell 10.10.1.6, length 28 08:02:04.753141 ARP, Reply 10.10.1.9 is-at 12:34:56:78:9a:bc (oui Unknown), length 28
Sequence of run : First I ran tcpdumps on both 10.10.1.9 and 10.10.1.10 and then tried doing telnet from 10.10.1.10. arp -a on 10.10.1.9
#arp -a ? (10.10.1.7) at 12:34:56:78:9a:bc [ether] on eth0 ? (10.10.1.4) at 12:34:56:78:9a:bc [ether] on eth0 ? (10.10.1.1) at 12:34:56:78:9a:bc [ether] on eth0 ? (10.10.1.8) at 12:34:56:78:9a:bc [ether] on eth0 ? (10.10.1.10) at on eth0 ? (10.10.1.11) at 12:34:56:78:9a:bc [ether] on eth0 ? (10.10.1.6) at 12:34:56:78:9a:bc [ether] on eth0 ? (10.10.1.5) at 12:34:56:78:9a:bc [ether] on eth0
#arp -a ? (10.10.1.1) at 12:34:56:78:9a:bc [ether] on eth0 ? (10.10.1.10) at on eth0 ? (10.10.1.9) at 12:34:56:78:9a:bc [ether] on eth0
Telnet no route to host linux
This issue happens when a network request is attempted to a remote host, and an error is thrown containing the phrase No route to host , or the error code EHOSTUNREACH .
Check RunBook Match
This runbook is limited to Linux hosts, although some steps may help trigger productive investigations on other OSes.
Initial Steps Overview
Detailed Steps
1) Gather information
1.1) Determine the host
Determine the host (or IP) you are trying to reach.
From here, this host will be referred to as [HOST|IP] .
1.2) Determine the IP
Once you have the hostname, then you can determine the IP address by running:
[HOST] has address 151.101.0.81 [HOST] has address 151.101.128.81 [HOST] has address 151.101.64.81 [HOST] has address 151.101.192.81 [. ]
You can take the first address returned as the IP to use, eg for the above output, 151.101.0.81 would be the IP.
If you can find out the ‘correct’ IP that you are trying to reach by some means independent from your machine, do so. This might involve contacting another user, or figuring out the IP address by introspecting on the host.
1.3) Determine the port
Determine the port you are trying to reach.
If this is a ‘standard’ web request, then the port is either 80 (for http requests) or 443 (for https requests).
If the web request hits a non-standard port, then you will see :[NUMBER] in the URL, eg:
https://example.com:8443/path/to/site
would mean you are trying to contact port 8443 .
This will be referred to subsequently as [PORT] .
1.4) Determine the frequency of the problem
Try and work out if the problem happens every time, or is intermittent.
If it’s intermittent, consider whether there are multiple hosts that could be ultimately reached by the request (eg behind a load balancer), and whether one of these hosts is faulty.
2) Is host up?
Check whether the host you are trying to reach is up.
2.1) Use nmap
If you see output that begins like this:
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-19 10:11 BST
then you have nmap installed. If you don’t then you will need to install it. Wait for the command to return.
If you see a message in output like:
then this is a DNS lookup failure. See the DNS Lookup Failure runbook.
If you see output that mentions Host is up , like this:
Nmap scan report for [HOST] ([IP]) Host is up (0.016s latency). Other addresses for [HOST] (not scanned): [IP2] [IP3] Not shown: 998 filtered ports PORT STATE SERVICE 80/tcp open http 443/tcp open https Nmap done: 1 IP address (1 host up) scanned in 11.20 seconds
then the host you are trying to contact is up.
2.2) Use ping
If you can not install nmap , then you can try to ping the host:
2.3) Use nmap on the IP
If you are certain of the IP you are trying to connect to, you can try using nmap to access that host directly as per step 2.1. If the output differs from that of step 2.1, then you may have an issue with DNS lookup for the host not returning the correct IP address.
If you do, then this is likely due to a DNS server local to your network being misconfigured. Correcting this is outside the scope of this runbook, and will likely require you to contact the person responsible for that DNS server.
3) Is the port open?
There are two ways of determining this — from the client host and from the remote host.
3.1) From client
Run this command, and check the output:
If the command hangs with output like:
then you can only say that the connection is not being explicitly rejected by the remote host. Where the connection is being stopped/dropped is impossible to say. It could be:
- by a local firewall
- by an intervening host/firewall
- by the remote host’s firewall
If the request returns with a message like:
telnet: Unable to connect to remote host: Connection refused
then the request reached a remote host, and was explicitly refused.
If you connect, with a response like this:
Trying 151.101.0.81. Connected to [HOST] Escape character is '^]'.
Then the issue appears to be resolved. If your application is still having the same problem, then check the IP address it is trying to reach matches the IP address above.
3.2) From remote host
There are several ways to determine whether a given port is open on your host.
netstat -ln | grep -w tcp | grep -w [PORT]
If the output looks like this:
tcp 0 0 0.0.0.0:[PORT] 0.0.0.0:* LISTEN
then the port is open on all network interfaces (that’s what 0.0.0.0 means). If you see another set of numbers in place of the 0.0.0.0:[PORT] , then . Similarly, if you see something else in place of the 0.0.0.0:* (the ‘Foreign Address’), then the port may not be accessible only to clients from specific IP addresses. For example, if you see 127.0.0.1:* then it is only accessible from the localhost (using any port).
ss -ln | grep -w tcp | grep -w [PORT]
Which produces similar output:
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
You can try connecting direct to the port using telnet, as per step 3.1. However be aware that this just proves that you can connect from the same host (see notes on interfaces in this section above).
3.3) Conclusions
- the port appears to be open from the point of view of the remote host
- the port appears to be closed from the point of view of the client
this suggests that there is an intervening firewall that is blocking requests from reaching the server.
The firewall may be on the remote host.
4) Check IPTables / NetFilter
First, if you want to (optionally) know whether you are using IPTables or NetFilter, go here.
To determine your IPTables/NetFilter rules and whether they affect your port or host, run as root:
iptables -S | grep -w [PORT] iptables -S | grep -w [IP] iptables -S | grep -w [HOST]
If any lines match, then IPTables may be blocking or redirecting your attempts to connect to the remote server.
Understanding IPTables more deeply to fully debug this is outside the scope of this article. There are many resources on the web that attempt to explain it for various levels of experience.
5) Check routing tables
At this point, you may want to consider whether your routing tables are misconfigured.
This command gives a list of your machine’s routes:
If the ip command is unavailable, try route :
Determining whether the routing tables are correctly configured requires more network knowledge than can be reasonably placed here, and likely some knowledge of the local network topology.
There are many good resources on the internet for this, see Further Information below for links.
6) Check intervening firewalls
At this point you’ve checked connectivity at your client machine and the server. Now it is worth considering whether there is an intervening firewall between client and server blocking the connection.
We have already considered IPTables/NetFilter, but it is possible that there is some other kind of firewall running on your host that is preventing egress.
then consider whether there are network rules set up to prevent egress. On AWS these come in the form of ‘Security Groups’ and ‘Network ACLs’.
Any number of firewalls/hosts may be relaying your request to the destination host. Any of these may be blocking the request from going further.
Using traceroute might be considered at this point to determine which (and how many) hosts are being hit may help you debug further. See here for more background on this tool.
Check Resolution
If the application no longer reports this error, then this issue is resolved.
Further Steps
Further Information
This error originates from the Linux kernel, eg in:
It can be thrown within the kernel for a number of different reasons, which makes interpreting the error tricky.
Почему ping видит хост, а telnet — нет?
Так ты только filter показываешь. Выхлоп iptables-save покажи.
# iptables-save # Generated by iptables-save v1.6.1 on Fri Feb 14 17:04:04 2020 *nat :PREROUTING ACCEPT [165901:15712312] :INPUT ACCEPT [11:924] :OUTPUT ACCEPT [180734:16160062] :POSTROUTING ACCEPT [180734:16160062] COMMIT # Completed on Fri Feb 14 17:04:04 2020 # Generated by iptables-save v1.6.1 on Fri Feb 14 17:04:04 2020 *mangle :PREROUTING ACCEPT [30240295:34648361235] :INPUT ACCEPT [30240294:34648361199] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [29860383:33518819261] :POSTROUTING ACCEPT [29860389:33518819654] COMMIT # Completed on Fri Feb 14 17:04:04 2020 # Generated by iptables-save v1.6.1 on Fri Feb 14 17:04:04 2020 *raw :PREROUTING ACCEPT [30240295:34648361235] :OUTPUT ACCEPT [29860383:33518819261] COMMIT # Completed on Fri Feb 14 17:04:04 2020 # Generated by iptables-save v1.6.1 on Fri Feb 14 17:04:04 2020 *security :INPUT ACCEPT [30073641:34632609054] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [29860383:33518819261] COMMIT # Completed on Fri Feb 14 17:04:04 2020 # Generated by iptables-save v1.6.1 on Fri Feb 14 17:04:04 2020 *filter :INPUT ACCEPT [1209505:1323170257] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [1216328:1289639896] -A INPUT -p tcp -m tcp --dport 8811 -j ACCEPT -A INPUT -d 10.0.0.3/32 -p icmp -m icmp --icmp-type 8 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -s 10.0.0.3/32 -p icmp -m icmp --icmp-type 0 -m state --state RELATED,ESTABLISHED -j ACCEPT COMMIT # Completed on Fri Feb 14 17:04:04 2020
Теперь ты правильно пишешь, а то что порт закрыт — это фиревале проблемы. Если это CentOS, выключи его командами
systemctl stop firewalld systemctl disable firewalld