Jeff Widman asked:
I manage a KVM VPS at 22.214.171.124 that for some reason cannot reach http://pecl.php.net.
ping the IP address of the PECL server (126.96.36.199), to make sure that it isn’t a DNS problem, and each time I get
Destination Host Unreachable.
How can I debug whether the root cause is a misconfiguration of my server, or the ping being rejected by the destination server?
I have no issues
pinging PECL from various other servers that I manage, so I know PECL isn’t blocking all pings.
I also have no issues
pinging any other sites I try from my VPS, the problem is solely with the PECL server.
I used the looking glass of my VPS host (http://lg.las1.ultravps.net/), and it has no issues pinging PECL. I also filed a support ticket with the host, and they logged into the hypervisor for this node and said they could successfully ping PECL.
I ran a
traceroute to the PECL server from another server to find the IP address of a next-to-last hop. I can successfully ping that IP (188.8.131.52) from my VPS.
When I run
traceroute from the VPS, I get:
[jeffwidman@ultravps ~]$ traceroute pecl.php.net traceroute to pecl.php.net (184.108.40.206), 30 hops max, 60 byte packets 1 ultravps.jeffwidman.com (220.127.116.11) 3005.478 ms !H 3005.400 ms !H 3005.270 ms !H [jeffwidman@ultravps ~]$ traceroute 18.104.22.168 traceroute to 22.214.171.124 (126.96.36.199), 30 hops max, 60 byte packets 1 ultravps.jeffwidman.com (188.8.131.52) 3005.916 ms !H 3005.877 ms !H 3005.867 ms !H [jeffwidman@ultravps ~]$
I checked multiple blacklist sites, just to make sure I hadn’t inherited a bad IP address… none of them listed my IP. I also don’t regularly hit PECL, and this issue has occurred for several days, so I’d be very surprised if I was hitting rate-limiting.
What else can I do to debug whether PECL is blocking my IP address or if I have something misconfigured on my VPS?
[jeffwidman@ultravps ~]$ ip route default via 184.108.40.206 dev eth0 proto static metric 100 220.127.116.11/8 dev eth0 proto kernel scope link src 18.104.22.168 metric 100
[jeffwidman@ultravps ~]$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:16:3c:d1:49:f6 brd ff:ff:ff:ff:ff:ff inet 22.214.171.124/8 brd 126.96.36.199 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::216:3cff:fed1:49f6/64 scope link valid_lft forever preferred_lft forever [jeffwidman@ultravps ~]$
Now the problem is apparent.
Your network interface has the wrong prefix set.
It is set to /8 (or in the old netmask notation, 255.0.0.0), which tells your operating system that every address in the 188.8.131.52 through 184.108.40.206 inclusive is on the same LAN as your VPS.
This obviously is not the case. Most of this range is subdivided into very small networks scattered all over the Americas.
Because of this, your computer does not know it is meant to route the packets, and tries to contact any address beginning with 104. on the same LAN, where it cannot be found.
To fix the problem, you need to reconfigure your network for the correct netmask or CIDR range. You can obtain this information from your VPS provider.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.