Base de connaissances

ICMP - Pings IPv4 et NAT Test de la plage de ports IPv4

Test de plage de ports NAT

Pour fonctionner correctement, l'application que vous souhaitez exécuter via le système NAT IPv4 doit répondre aux exigences suivantes :

- L'application doit de préférence être compatible double pile (c'est-à-dire prendre en charge la connectivité IPv4 et IPv6) ;

- Elle doit pouvoir écouter sur [::]::0 et/ou 0.0.0.0/0, les adresses génériques pour IPv6 et IPv4 ;

- Spécifiquement pour une utilisation UDP : elle doit de préférence envoyer un flux de paquets continu via UDP.

Presque toutes les applications Linux prennent en charge la connectivité double pile. Parmi les exceptions notables, on peut citer :

- SOCKS 4 et SOCKS 4a (pris en charge à partir de SOCKS 5) ;

- Docker uniquement avec les versions antérieures à la version 27.0.1 (lancée le 24 juin 2024). Certaines distributions utilisent encore la version précédente 26, notamment Debian 12 et 13. Ubuntu 24.04 LTS est compatible avec Docker à partir de la version 27.5, ce qui en fait une alternative viable.

- Kubernetes (uniquement les versions antérieures à décembre 2021). Debian 10 n'est pas compatible ; la compatibilité est prévue à partir de Debian 11.

- Autres logiciels antérieurs à 2017/2018.

L'adresse IP NAT IPv4 renseignée dans les mappages de ports NAT de VirtFusion (sur le VirtPortal, à l'adresse virtportal.cfld.uk) n'a pas besoin d'être fournie à l'application sur le VPS, qui disposera d'une adresse IPv4 privée et d'une adresse IPv6 publique. Il suffit que l'application écoute sur des adresses génériques. Le trafic envoyé sur une plage de ports donnée sera automatiquement réparti par notre pontage Libvirt et, si l'une des adresses est inaccessible, le trafic sera acheminé vers l'autre.

Exemples de test pour TCP et UDP

Rappel : les ports sont automatiquement pré-ouverts sur la plage de ports sortants spécifiée. Il vous suffit de les associer aux ports internes du schéma affiché sur VirtPortal, en choisissant le port interne de votre choix. Inutile de nous contacter : nous n’offrons aucun support pour les opérations de NAT, qui doivent être entièrement gérées par l’utilisateur.

Exemple pour TCP : tentez de modifier un service, par exemple `/etc/ssh/sshd_config`, pour utiliser un port de votre VPS (sauf les ports inférieurs à 1024 ou le port 22).

Assurez-vous que `PubkeyAuthentication` est défini sur `No` et non commenté (sans le `#`), et que `PasswordAuthentication` est défini sur `Yes` et non commenté. Enregistrez. Exécutez maintenant :

sudo systemctl restart sshd [pour Debian, AlmaLinux, Rocky Linux, Fedora] ou

sudo systemctl restart ssh [pour Ubuntu]

afin de redémarrer le service SSH. Assurez-vous qu'il écoute sur les deux protocoles avant tout test.

Vous pouvez ensuite tenter de vous connecter à l'aide de PuTTY, MobaXterm ou tout autre client SSH, en saisissant l'adresse IPv4 du serveur, l'utilisateur Linux du VPS (root) et le port sortant spécifique disponible sur le portail VirtFusion, VirtPortal (par exemple, 43560). Ce port correspondra directement au port interne que vous avez spécifié pour SSH (par exemple, 4096), et la connexion fonctionnera parfaitement.

Une autre solution intéressante consiste à installer une configuration dynamique serveur/client iperf3, votre VPS faisant office de serveur iperf3 et n'importe quel ordinateur Linux faisant office de client iperf3. Cette configuration fonctionne par défaut en TCP avec un seul flux. Vous pouvez toujours effectuer des tests avec un plus grand nombre de flux et/ou en utilisant le protocole UDP. Vous pouvez définir n'importe quel port interne de votre VPS pour ces tests, conformément à la configuration NAT de VirtPortal.

De nombreux guides sont disponibles en ligne pour les paquets iperf3, et ils sont compatibles avec nos systèmes VPS, car nous utilisons une NAT IPv4 standard. Assurez-vous simplement, depuis le client, de toujours cibler l'adresse IPv6 ou l'adresse IPv4 publique du système (l'adresse IP globale du serveur dédié), et le tour est joué.

Exemple pour UDP : installez netcat-openbsd, disponible sous Debian ou Ubuntu. Après l'installation, assurez-vous de ne pas vouloir exécuter d'autres commandes avant netcat, puis exécutez la commande suivante :

nc -6 -u -l -p [numéro de votre port]

où [numéro de votre port] correspond à la plage de ports UDP exclusive configurée sur votre VPS pour la NAT IPv4 (consultez l'article de la base de connaissances pour le calcul des ports NAT IPv4).

Le processus commencera à écouter, via IPv6, sur le port que vous avez choisi et restera ainsi.

Ensuite, essayez d'envoyer un message (texte, etc.) via UDP :

Depuis Windows PowerShell :

$message = "Test UDP"; $udpClient = New-Object System.Net.Sockets.UdpClient; $udpClient.Connect("116.xxx.xxx.xxx", [numéro de votre port]); $bytes = [Text.Encoding]::ASCII.GetBytes($message); $udpClient.Send($bytes, $bytes.Length); $udpClient.Close()

Depuis Linux :

echo "Test UDP" | nc -u -w1 116.xxx.xxx.xxx [numéro de votre port]

Où « 116.xxx.xxx.xxx » correspond à l'adresse IPv4 publique de votre serveur, et [numéro de votre port] au numéro du port UDP dédié. Ce dernier doit être identique au port d'écoute de votre processus sur le VPS, et il est recommandé qu'il corresponde également à la plage de ports UDP sortants, pour simplifier la configuration.

Si vous recevez « Test UDP » sur votre VPS, tout fonctionne correctement.