web-dev-qa-db-fra.com

Test de la connectivité du port UDP

J'essaie de tester si je peux accéder à un port particulier sur un serveur distant (auquel j'ai accès tous les deux) via UDP.

Les deux serveurs font face à Internet. J'utilise netcat pour avoir un certain port d'écoute.

J'utilise ensuite nmap pour vérifier ce port pour voir s'il est ouvert, mais il ne semble pas l'être.

Iptables est désactivé.

Des suggestions pourquoi cela pourrait être? Je vais finalement configurer un tunnel VPN, mais parce que je suis très nouveau dans les tunnels, je veux m'assurer d'avoir une connectivité sur le port UDP 1194 avant d'avancer.

centosudpnetworking
43
Lock

Il n'y a pas de port UDP "ouvert", du moins pas dans le sens où la plupart des gens pensent (qui répond à quelque chose comme "OK, j'ai accepté votre connexion"). UDP est sans session, donc "un port" (lire: le protocole UDP dans la pile IP du système d'exploitation) ne répondra jamais "succès" seul.

Les ports UDP n'ont que deux états: écoute ou non. Cela se traduit généralement par "avoir un socket ouvert par un processus" ou "ne pas avoir de socket ouvert". Ce dernier cas doit être facile à détecter car le système doit répondre avec un paquet ICMP Destination Unreachable avec le code = 3 (Port inaccessible). Malheureusement, de nombreux pare-feu peuvent supprimer ces paquets, donc si vous ne récupérez rien, vous ne savez pas avec certitude si le port est dans cet état ou non. Et n'oublions pas que ICMP est également sans session et ne fait pas de retransmissions: le paquet Port inaccessible pourrait très bien être perdu quelque part sur le net.

Un port UDP dans l'état "écoute" peut ne pas répondre du tout (le processus qui l'écoute reçoit juste le paquet et ne transmet rien) ou il peut renvoyer quelque chose (si le processus agit à la réception et s'il agit en répondant via UDP au port IP d'origine de l'expéditeur). Encore une fois, vous ne savez jamais avec certitude quel est l'état si vous ne récupérez rien.

Vous dites que vous pouvez avoir le contrôle de l'hôte récepteur: cela vous permet de construire votre propre protocole pour vérifier l'accessibilité du port UDP: il suffit de mettre un processus sur l'hôte récepteur qui écoutera sur le port UDP donné et répondent en retour (ou vous envoient un e-mail, ou simplement paniquent et unlink() tout sur le système de fichiers hôte ... tout ce qui déclenchera votre attention sera faire).

50
Luke404

Pour tester si le port udp répond, utilisez netcat.

Un exemple de la page de manuel :

nc -v -u -z -w 3 example.Host 20-30
    Send UDP packets to ports 20-30 of example.Host, and report which ones
    did not respond with an ICMP packet after three seconds.

Bien sûr, si un pare-feu est DROPing, ce qui est normalement le cas pour les passerelles Internet, vous ne recevrez pas de réponse ICMP.

63
motobói
  1. à la fois sur l'installation client et serveur nc: yum install nc (pour les centos)
  2. sur le serveur écouter le port UDP: nc -ul 6111
  3. sur le client nc -u <server> 6111
  4. tapez n'importe quoi sur le client et appuyez sur Entrée - vous devriez voir ce texte sur le serveur

Remarque: Lorsque vous exécutez le nc -ul commande sur le serveur, il se connectera uniquement pour la première connexion qui lui parviendra. Vous ne pouvez pas, comme je l'ai découvert, basculer entre les serveurs lui envoyant une requête ping sans arrêter et redémarrer nc -ul. En fait, si vous ^ C arrêtez le client (nc -u ...), vous ne pouvez pas non plus redémarrer le client sans redémarrer d'abord l'écouteur du serveur.

34
Sasha

Tester les ports UDP ouverts avec nmap est semé d'embûches - il n'y a pas de prise de contact à trois voies pour indiquer l'ouverture. À moins que le processus d'écoute ne réponde à ce que nmap envoie, il n'y a aucun moyen pour nmap de faire la différence entre un port ouvert qui ne répond pas et un port filtré.

Il est beaucoup plus facile d'écouter à une extrémité avec netcat et d'utiliser netcat à l'autre extrémité pour envoyer des paquets et de voir qu'ils arrivent à l'autre extrémité. Faites-le dans les deux sens, assurez-vous simplement. Vous pouvez également tcpdump pour voir les paquets arriver là où ils doivent aller.

10
womble

J'avais un problème similaire et j'ai trouvé une bonne solution en utilisant netcat ici: http://en.wikipedia.org/wiki/Netcat#Test_if_UDP_port_is_open:_simple_UDP_server_and_client

nc -vzu <Host> <port>

J'ai pu confirmer que mon port UDP était ouvert, puis j'ai pu tester mon code réel.

10
tmarkiewicz

Vous pouvez analyser les ports udp en utilisant la commande suivante

nmap -sU -v <hostname or ip>
3
Koray Güclü

J'ai une approche simple. Si le serveur UDP ne renvoie pas les données attendues, j'arrête simplement de collecter les dgrammes, en supposant qu'il a baissé:

LINE: while(1)
{
    my $line;
    my $flags;

    local $SIG{ALRM} = sub {die "exceeded timeout for recv"};
    alarm 5;
    eval {
        $socket->recv($line,2024,$flags);
    };

    unless($line =~ /\{.*\}/){
        if($verbose){
            print STDERR "Invalid or empty dgram:\n",'"', $line, '"',"\n";
        }

        last LINE;
    }
}
1
David Waddell

Vous pouvez le faire avec netcat (nc) ou iperf, en supposant que vous avez une autre machine à tester en dehors du réseau. Mon choix serait une analyse UDP nmap à partir d'un système en dehors de votre environnement. Quelle était votre ligne de commande nmap? Y a-t-il des pare-feu matériels ou d'autres appareils dans le mélange?

1
ewwhite