
Me gustaría generar un detector de netcat en un puerto determinado dentro de un contenedor acoplable para depurar manualmente las solicitudes entrantes, pero el comportamiento de netcat dentro de la ventana acoplable parece diferente de lo que solía observar en una configuración no acoplada. Tomando Vanilla Ubuntu 18.04 como ejemplo:
sudo docker run -it -p 6010:6010 ubuntu:18.04
# inside container
apt-get update && apt-get install -y netcat net-tools
nc -lk 0.0.0.0 6010 &
# then to verify what I am listening on
netstat -an|grep LISTEN
# example output:
# tcp 0 0 0.0.0.0:39331 0.0.0.0:* LISTEN
Ningún error de ningún tipo, sólo una asignación silenciosa de un punto diferente. Por la experiencia de generar oyentes no dockerizados, solía pensar que obtendría un error (como puerto tomado) o que el puerto solicitado se asignaría correctamente. ¿Qué está pasando aquí y cómo forzar la escucha en el puerto deseado?
Sólo para anticipar posibles sugerencias, como dice el hombre de netcat en -p [port]
:
Es un error utilizar esta opción junto con la opción -l.
Respuesta1
Como se sugiere en los comentarios, la versión netcat de BusyBox requiere -p
especificar el puerto de escucha, por lo que la página del manual que usted cita no se aplica en este caso. Esta es la línea de comando correcta para BusyBox netcat:
nc -l -p 6010 # IP can be left out if it is 0.0.0.0 (all IPs)
Aquí está la página de ayuda para nc en mi versión de Alpine:
/ # nc -v
BusyBox v1.32.1 () multi-call binary.
Usage: nc [OPTIONS] HOST PORT - connect
nc [OPTIONS] -l -p PORT [HOST] [PORT] - listen
-e PROG Run PROG after connect (must be last)
-l Listen mode, for inbound connects
-lk With -e, provides persistent server
-p PORT Local port
-s ADDR Local address
-w SEC Timeout for connects and final net reads
-i SEC Delay interval for lines sent
-n Don't do DNS resolution
-u UDP mode
-v Verbose
-o FILE Hex dump traffic
-z Zero-I/O mode (scanning)```