Can’t test port without telnet? The best port testing method for containerized deployment

Write in front

  • Encountered in production, organize notes
  • How to test remote port without telnet in container
  • If you don’t understand enough, please help me to correct

His life tells us that if you can’t love yourself, you can’t love others. If you hate yourself, you will hate others. In the end, it will be like abhorrent selfishness, which will make people extremely lonely and pessimistic. . — Hermann Hesse “Steppenwolf”

Can’t test port without telnet ? Share with your friends some methods of port testing under the container

Demo port environment preparation, relevant network segment 192.168.26.55 machine, remote machine, listening on port 55555

┌──[[email protected]]-[~]
└─$ coproc python3 -m http.server 55555
[1] 11694

Test environment, same network segment 192.168.26.100 machine

┌──[[email protected]]-[~]
└─$ wget 192.168.26.55:55555 -v
--2023-04-11 16:59:35-- http://192.168.26.55:55555/
Connecting 192.168.26.55:55555... Connected.
HTTP request sent, waiting for response... 200 OK

The timeout $number below is not required and is used to constrain the command timeout

/dev/tcp

Use the /dev/tcp virtual file system to check whether the port is open or closed, and you can test it with the following naming

 </dev/tcp/172.30.127.22/3306

Take a look at a demo, using the /dev/tcp virtual file system in Linux to connect to port 55555 of a remote host. Used to test whether a remote host is listening on or establishing a connection to this port. /dev/proto/host/port/ corresponds to test data /dev/tcp/$host/$port

In order to look good here, we do some simple modification

common situation

┌──[[email protected]]-[~]
└─$(timeout 1 bash -c '</dev/tcp/192.168.26.55/55555' & amp; & amp; echo PORT OPEN || echo PORT CLOSED) 2>/dev/null
PORT OPEN

Unreasonable situation

┌──[[email protected]]-[~]
└─$(timeout 1 bash -c '</dev/tcp/192.168.26.55/443' & amp; & amp; echo PORT OPEN || echo PORT CLOSED) 2>/dev/null
PORT CLOSED

In principle, truth values in Linux are not the same as truth values in programming language code. Confirm whether it is passed according to the return value of the execution

┌──[[email protected]]-[~]
└─$ bash -c '</dev/tcp/192.168.26.55/55555' & amp; & amp; echo $?
0
┌──[[email protected]]-[~]
└─$ bash -c '</dev/tcp/192.168.26.55/443' & amp; & amp; echo $?
bash: connect: connection refused
bash: /dev/tcp/192.168.26.55/443: connection refused
┌──[[email protected]]-[~]
└─$

We can display it normally if we change it to a comma.

┌──[[email protected]]-[~]
└─$ bash -c '</dev/tcp/192.168.26.55/443' ;echo $?
bash: connect: connection refused
bash: /dev/tcp/192.168.26.55/443: connection refused
1

Note that this command may not work on all systems, as it depends on whether the /dev/tcp virtual file system is enabled. Also, this command should only be used for testing or diagnostic purposes and not for any malicious activity.

If the three layers are not connected, it can also be analyzed in detail for different situations

The situation of the port

[root@master ~]# </dev/tcp/172.30.127.22/3306

The case where the IP does not work

[root@master ~]# </dev/tcp/172.30.127.23/3306
bash: connect: No route to host
bash: /dev/tcp/172.30.127.23/3306: No route to host
[root@master ~]# </dev/tcp/192.168.26.55/55555
bash: connect: Network is unreachable
bash: /dev/tcp/192.168.26.55/55555: Network is unreachable
[root@master~]#
  • Network is unreachable : This error occurs when the source device cannot find a route to the destination network. This means that the source device’s routing table does not have an entry for the network that the destination device is on. This could be because the network is down, or there is a misconfiguration in the routing table.
  • No route to host : This error occurs when the source device can find a route to the destination network, but cannot find a route to a specific host on that network. This means that the source device’s routing table has an entry for the network the destination device is on, but not for the specific IP address of the destination device. This could be because the target device is down, or there is a misconfiguration in the routing table.

curl

curl is a tool for transferring data from or to a server. It supports the following protocols: DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS, and WSS. It is powered by libcurl for all transport related functions

common situation

┌──[[email protected]]-[~]
└─$timeout 3 curl -vvv telnet://192.168.26.55:55555
* About to connect() to 192.168.26.55 port 55555 (#0)
*Trying 192.168.26.55...
* Connected to 192.168.26.55 (192.168.26.55) port 55555 (#0)

Unreasonable situation

┌──[[email protected]]-[~]
└─$timeout 3 curl -vvv telnet://192.168.26.55:443
* About to connect() to 192.168.26.55 port 443 (#0)
*Trying 192.168.26.55...
* connection refused
* Failed connect to 192.168.26.55:443; Connection refused
* Closing connection 0
curl: (7) Failed connect to 192.168.26.55:443; Connection refused
┌──[[email protected]]-[~]
└─$

nc OR nact

The nc or ncat commands can also be used to test whether a remote host is listening on or establishing a connection to a specified port.

┌──[[email protected]]-[~]
└─$ which nc
/usr/bin/nc

For example, to test whether port 55555 on a remote host is open, you can use the following command:

common situation

┌──[[email protected]]-[~]
└─$nc -vz 192.168.26.55 55555
Ncat: Version 7.50 (https://nmap.org/ncat)
Ncat: Connected to 192.168.26.55:55555.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.
┌──[[email protected]]-[~]
└─$

Unreasonable situation

┌──[[email protected]]-[~]
└─$nc -vz 192.168.26.55 443
Ncat: Version 7.50 (https://nmap.org/ncat)
Ncat: Connection refused.

Or you can use ncat, which is a more modern tool that is part of the nmap suite of networking tools. It is designed as a richer replacement for nc. It supports SSL/TLS encryption, IPv6, SOCKS proxies, and more.

┌──[[email protected]]-[~]
└─$ncat -zv 192.168.26.55 55555
Ncat: Version 7.50 (https://nmap.org/ncat)
Ncat: Connected to 192.168.26.55:55555.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.
┌──[[email protected]]-[~]
└─$ncat -zv 192.168.26.55 443
Ncat: Version 7.50 (https://nmap.org/ncat)
Ncat: Connection refused.
┌──[[email protected]]-[~]
└─$

nmap

Port scanning tool, will scan all ports, generally not recommended

┌──[[email protected]]-[~]
└─$ rpm -ql nmap || yum -y install nmap
┌──[[email protected]]-[~]
└─$nmap -sT 192.168.26.55 443

Starting Nmap 6.40 (http://nmap.org) at 2023-04-11 16:44 CST
Nmap scan report for 192.168.26.55 (192.168.26.55)
Host is up (0.0025s latency).
Not shown: 994 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
222/tcp open rsh-spx
8080/tcp open http-proxy
50000/tcp open ibm-db2
55555/tcp open unknown
MAC Address: 00:0C:29:9F:48:81 (VMware)

Nmap done: 2 IP addresses (1 host up) scanned in 1.74 seconds
</code><img class="look-more-preCode contentImg-no-view" src="//i2.wp.com/csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreBlack. png" alt="" title="">

python

The Linux environment generally has a python environment. To use Python to check whether the remote port is open, you can use the socket module

Portal Demo

┌──[[email protected]]-[~]
└─$python2
Python 2.7.5 (default, Aug 4 2017, 00:39:18)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> sock.connect(('192.168.26.55', 55555))
>>>

Demo with unreachable ports

┌──[[email protected]]-[~]
└─$python2
Python 2.7.5 (default, Aug 4 2017, 00:39:18)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> sock.connect(('192.168.26.55', 443))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
socket.error: [Errno 111] Connection refused
>>>
┌──[[email protected]]-[~]
└─$
</code><img class="look-more-preCode contentImg-no-view" src="//i2.wp.com/csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreBlack. png" alt="" title="">

Regarding the port test under the container, you can share it here with your friends. I feel that there is no difference. The demo is not done in the container.

Partial content reference of blog post

? The copyright of the content of the reference links in this article belongs to the original author. Please inform us if there is any infringement.

https://medium.com/geekculture/linux-useful-tricks-telnet-alternatives-ed9f342149a1

? 2018-2023 [email protected], All rights reserved. Attribution-Non-Commercial-Share Alike (CC BY-NC-SA 4.0)