tutorial - Usar netcat para enviar un paquete UDP sin enlace

usar comando nc

Question

Estoy tratando de usar netcat para simular un protocolo NAT transversal.

Tengo una instancia que está escuchando paquetes UDP en el puerto 6666, así:

nc -ul 6666

En otra ventana de terminal, estoy tratando de enviar periódicamente un paquete UDP desde el puerto 6666 (para abrir la ruta de retorno en mi enrutador, esto sería en un script que se repite cada 20 segundos para volver a abrir el puerto)

nc -u -p6666 mypinghost.com 4444

El problema es que netcat falla en esta llamada ping con el mensaje:

nc: enlace fallido: dirección ya en uso

Lo que implica que el oyente que se ha vinculado al puerto 6666 está bloqueando el envío de otro proceso desde ese puerto, o posiblemente que netcat esté intentando vincularse al 6666 para escuchar.

¿Es así como se escribe netcat, o puedo hacerle cosquillas de alguna manera para que me permita enviar un paquete sin vincularlo al puerto para escuchar?

Answer 1

No creo que puedas usar netcat de esa manera. Yo recomendaría escribir un script simple de Python que haga las tareas de envío y recepción en un proceso. De esta forma, puede mantener ese puerto de forma exclusiva y aun así realizar ambas tareas.

Answer 2

nc -ul 6666

Escuche en el puerto UDP 6666.

nc -u -p6666 mypinghost.com 4444

Usando el puerto UDP 6666 como puerto de origen, envíe a mypinghost: 4444.

nc: enlace fallido: dirección ya en uso

Eso sería en la segunda invocación de netcat , donde 6666 ya está siendo utilizado por el primero.

Lo que implica que el oyente que se ha vinculado al puerto 6666 está bloqueando el envío de otro proceso desde ese puerto

Correcto.

o posiblemente que netcat esté tratando de vincularse al 6666 para escuchar.

Y definitivamente eso. Usted le dijo que hiciera eso, así que lo hizo.

Lo que intenta hacer es imposible entre dos procesos en el mismo host. Solo un proceso puede usar un puerto UDP local específico a la vez, a menos que use SO_REUSEADDRESS , que netcat no parece implementar.

Como ha sugerido el otro afiche, la solución está en usar un solo proceso.