A brief comment on Linux Weekly News discussion of the long, slow, transition from net-tools to iproute2 reminded me that many people seem not to realize the man-pages for the iproute2 commands have been there all along. Rather like the git commands they are all prefixed with ip-. They provide much greater depth than the simple man ip:
There’s more work to do, due to the enhanced security features of CentOS. DNS is correct, the webserver is running, but the browsers says the site responds with Connection Refused. Okay, so it’s time to dig in.
First off, is DNS really correct? Does the DNS name resolve to the correct IP address? A quick use of nslookup will verify this, and it does. Okay, next I double-check access the website using the IP, e.g. http://10.11.12.13. This gives the same connection refused error.
Okay, so I know my web browser is getting to the host; if it was a routing issue I wouldn’t get connection refused. So either the server is not listening on port 80 or there’s a firewall blocking it.
Next I get on the host and check to see that httpd is running, using “ps -ef|grep httpd”. It’s there. Okay, is it not running on port 80? Sometimes the apache processes listens on 8080 or something, so I review the /etc/httpd/conf/httpd.conf file and find “Listen 80″ in there. Okay, that’s good.
Next up, netstat. A simple “netstat -na|grep 80″ should tell me if the server is listening on port 80. Except... “command not found”. WTF? I’ve been using netstat in UNIX systems since the eighties. Where did it go? A little quick research and I learn that netstat and related commands were put in a package called “net-tools” and this package was deprecated because some really smart people found a better way for these tools to work, creating the “iproute2″ package. Okay, I’m game to keep up with the times, that’s why everything is using latest versions in this project. So instead of netstat, the new command is “ss -l”. So “ss -l|grep LISTEN” shows something listening on the http port, and to make sure that’s 80, I take a guess that adding an “n” flag will show numbers instead of port names. And “ss -nl|grep LISTEN|grep 80″ shows the host is indeed listening to the port.
But yet, I’m still getting connection refused. There must be a firewall in place somewhere. Now this is a VPS, so a separate firewall service is probably an add-on feature. But to be sure, I log into my ISP account and see if there’s any mention of a firewall there. Nope.
So there must be a firewall process on the host. “ps -ef|grep firewall” reveals a firewalld process. Ah, I guess iptables has moved on and been replaced by something new. Okay. A little more research and I find that the commands “firewall-cmd --zone=public --ad-service=http --permanent” and “firewall-cmd --reload” will allow http traffic to public zone. (I will need to repeat this later for https when I add an SSL certificate.)
And that does the trick. Instead of connection refused, I get the default Apache page.
stackexchange also suggests older tunctl.
baturin points out persistent/transient distinction, tun==IP tap=frames and root versus ordinary user permissions. openvpn with iproute2
