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), 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 si ce port est ouvert, mais cela ne semble pas être le cas.

Iptables est éteint.

Des suggestions pourquoi cela pourrait être? Je vais éventuellement configurer un tunnel VPN, mais comme je suis très novice dans les tunnels, je veux m'assurer que la connectivité est établie sur le port UDP 1194 avant de poursuivre.

Il n’existe pas de port UDP "ouvert", du moins pas dans le sens où la plupart des gens pensent (ce qui revient à dire "OK, j’ai accepté votre connexion"). UDP est sans session, donc "un port" (en lecture: le protocole UDP dans la pile IP du système d'exploitation) ne répondra jamais "succès" seul.

Les ports UDP ont seulement deux états: écoute ou pas. Cela signifie généralement "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 inaccessible de destination ICMP avec le code = 3 (Port inaccessible). Malheureusement, de nombreux pare-feu peuvent rejeter ces paquets. Par conséquent, 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 qu'ICMP est également sans session et ne permet pas les retransmissions: le paquet Port Unreachable pourrait très bien être perdu quelque part sur le réseau.

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

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 en place un processus sur l'hôte récepteur qui écoute le port UDP donné et répond (ou vous envoie un e-mail, ou tout simplement paniquer et unlink()tout sur le système de fichiers hôte ... tout ce qui déclenchera votre attention fera).

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

Un exemple tiré 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 DROPactif, ce qui est généralement le cas pour les passerelles Internet, vous ne recevrez pas de réponse ICMP.

1. aussi bien sur client que sur serveur nc: yum install nc(pour centos)
2. sur le serveur, écoutez 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 la nc -ulcommande sur le serveur, celui-ci ne se connecte que lors de la première connexion. Comme je l'ai découvert, vous ne pouvez pas basculer d'un serveur à l'autre sans arrêter ni 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 d'abord redémarrer l'écouteur du serveur.

Tester des ports UDP ouverts avec nmap est semé d'embûches - il n'y a pas de négociation à trois voies pour indiquer une 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 bien plus facile d'écouter d'un côté avec netcat et d'utiliser netcat à l'autre pour envoyer des paquets et voir qu'ils arrivent à l'autre. Faites-le dans les deux sens, soyez sûr. Vous pouvez également tcpdumpvoir les paquets se rendre là où ils doivent aller.

J'avais un problème similaire et j'ai trouvé une bonne solution avec 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 et pouvoir ensuite tester mon code actuel.

Vous pouvez analyser les ports udp en utilisant la commande suivante

nmap -sU -v <hostname or ip>

Vous pouvez le faire avec netcat(nc) ou iperfsi vous avez une autre machine à tester en dehors du réseau. Mon choix serait une nmapanalyse UDP à partir d'un système situé en dehors de votre environnement. Quelle était votre ligne de commande nmap? Existe-t-il des pare-feu matériels ou d’autres périphériques?

J'ai une approche simple. Si le serveur UDP ne renvoie pas les données attendues, j'arrête simplement de collecter les programmes, en supposant que cela se soit produit:

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;
    }
}