GNU/Linux >> Tutoriels Linux >  >> Linux

Netcat arrête d'écouter le trafic UDP

Il y a donc plusieurs choses appelées netcat ; ubuntu a même /etc/alternatives symbolique-link-hackery pour cela.

Je pense qu'une partie de votre problème est que UDP ne fait pas de sessions ; J'ai copié une partie du fichier /usr/share/doc/netcat-traditional/README.gz ci-dessous qui explique assez bien.

Les connexions UDP sont ouvertes à la place de TCP lorsque -u est spécifié. Ce ne sont pas vraiment des "connexions" en soi puisque UDP est un protocole sans connexion, bien que netcat utilise en interne le mécanisme "connected UDPsocket" que la plupart des noyaux supportent. Bien que netcat prétende qu'une connexion UDP sortante est "ouverte" immédiatement, aucune donnée n'est envoyée jusqu'à ce que quelque chose soit lu à partir de l'entrée standard. Ce n'est qu'ensuite qu'il est possible de déterminer s'il existe réellement un serveur UDP à l'autre bout, et souvent vous ne pouvez tout simplement pas le dire. La plupart des protocoles UDP utilisent des délais d'attente et des tentatives pour faire leur travail et dans de nombreux cas, ils ne prennent pas la peine de répondre du tout, vous devez donc spécifier un délai d'attente et espérer le meilleur. Vous tirerez davantage parti des connexions UDP si l'entrée standard est alimentée à partir d'une source de données qui ressemble à divers types de requêtes de serveur.

OK, alors peut-être que ce n'est pas une bonne explication, mais c'est ce que j'ai pu trouver.

Si vous ne l'avez pas encore fait, vous voudrez peut-être expérimenter toutes les options netcat que vous pouvez trouver qui auraient à voir avec l'attente... avez-vous expérimenté :

  • en utilisant -l ainsi que -u pour vous assurer que vous êtes en mode "écoute"

  • -vv pour voir exactement ce qui se passe

  • -q -1 ... qui devrait "attendre indéfiniment" même après avoir reçu EOF (espérons-le, réécouter ?)


Vous pouvez utiliser socat pour ça. Il a une très belle option fork :

fork Après avoir établi une connexion, gère son canal dans un processus enfant et laisse le processus parent tenter de produire plus de connexions, soit en écoutant, soit en se connectant en boucle (exemple).

Client (oui, vous l'exécutez depuis le client) :

$ ssh -L 7753:localhost:7753 YourServer.com "/usr/bin/socat tcp4-listen:7753,reuseaddr,fork UDP:8.8.8.8:53"

Client :

$ sudo socat udp4-listen:53,reuseaddr,fork tcp:localhost:7753
$ dig @127.0.0.1 google.com

Linux
  1. Une introduction aux pare-feu d'applications Web pour les administrateurs système Linux

  2. Musique – Un lecteur de musique pour une expérience d'écoute unique

  3. netcat - continue d'écouter la connexion dans Debian

  4. Alimentez tout le trafic via OpenVPN pour un espace de noms de réseau spécifique uniquement

  5. Comment puis-je identifier quel processus génère du trafic UDP sous Linux ?

4 distributions Linux pour les jeux

Une introduction à bpftrace pour Linux

Choisir une imprimante pour Linux

Comment vérifier les ports d'écoute sous Linux (ports utilisés)

Comment utiliser Wireshark pour capturer et analyser les paquets réseau

5 exemples de la commande Netcat (nc) sous Linux