Today, my colleague said that a new cloud server is installed, and it is normal to log in Using ssh, but the above service port of Dayun database cannot be accessed.

Using netstat ANP to view the port is normal to listen, and the listening address is also allowed to be accessed by any ip

And the firewall and iptables are both closed

I was also surprised, so I logged in to the server remotely. Check the port of Dayun. It looks normal.

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

tcp6 0 0 :::5236 ::😗 LISTEN 3810/dmserver

Ssh-v-p 5236 root @ server public network ip try to access the database and find the connection failed

So it was changed to

ssh -v -p 5236 root@127.0.0.1 Discovery can connect successfully

All firewalls are closed. It should not be a firewall problem. I tried to use traceroute server public network ip to see if there is a problem with network routing.

As a result, the output from traceroute shows that the ip connection to the local machine has to go through several machines, which is a bit abnormal.

traceroute to ##desensitization##, 30 hops max, 60 byte packets
1 100.108.0.1 (100.108.0.1) 7.172 ms 7.271 ms 7.255 ms
2 11.245.20.8 (11.245.20.8) 5.880 ms 6.032 ms 11.245.20.2 (11.245.20.2) 5.943 ms
3 11.245.96.3 (11.245.96.3) 5.058 ms 4.933 ms 11.245.96.9 (11.245.96.9) 5.103 ms

Use route-n to check the route. It is found that there is no route of local public ip, so the default route should be used

Why is there no local routing? Is ip not configured well. But why can ssh connect if it is not configured properly? I try to use ifconfig-a to check and find a problem: the ip of this public network is not configured at all!

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.137 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::8d9f:e6ba:acea:d7bd prefixlen 64 scopeid 0x20
ether fa:16:3e:35:e6:b7 txqueuelen 1000 (Ethernet)
RX packets 84212 bytes 49923509 (47.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 48468 bytes 14177057 (13.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 58427 bytes 56052388 (53.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 58427 bytes 56052388 (53.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255
ether 52:54:00:e8:4d:1c txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

virbr0-nic: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether 52:54:00:e8:4d:1c txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Later, I consulted my peers and learned that ECs is like this. nat mapping is done through their routing, and there is no need to configure public ip on the local machine.

If you want to know the IP address of the local public network, you can use curl ip.cip.cc obtain.

So I execute this command to configure another virtual ip (public network) for this machine

ifconfig eth0:1 $(curl ip.cip.cc) netmask 255.255.255.0 up

Execute ssh-v-p 5236 root @ server public ip again, and it is found that it can be accessed successfully.

This means that the routing of the cloud server should block the 5236 port connection, not the local problem.

The next thing is simple. While looking for Huawei cloud interface person, see if you can open more ports. Before Huawei cloud replies, we use ssh to forward and * * map remote ports to local access through ssh. In this way, we can bypass the firewall problem of Huawei cloud.