Base de connaissances

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

Test de la 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 être double pile (c'est-à-dire prendre en charge la connectivité IPv4 et IPv6) ;
- Elle doit être capable d'écouter les formats d'adresse IPv6 et IPv4 (c'est-à-dire [::]::0 et 0.0.0.0/0, les adresses génériques pour IPv6 et IPv4) ;
- Spécifique à l'utilisation UDP uniquement : elle doit envoyer un flux de paquets continu via UDP.

Presque toutes les applications écrites pour Linux prennent en charge la connectivité double pile. Les exceptions notables et connues sont les suivantes :
- SOCKS 4 et SOCKS 4a (pris en charge par SOCKS 5) ;
- Docker uniquement avec les versions antérieures à 27.0.1 (lancée le 24 juin 2024). Certaines distributions continuent d'utiliser la version 26 précédente, notamment Debian 12 et 13, par exemple ; Ubuntu 24.04 LTS prend en charge Docker 27.5, ce qui en fait une alternative utilisable ;
- Kubernetes (uniquement les versions antérieures à décembre 2021). Debian 10 ne prend pas en charge cette fonctionnalité, la première prise en charge se trouve dans Debian 11.
- Autres logiciels antérieurs à 2017/2018.

L'adresse IPv4 NAT indiquée dans nos calculateurs de port NAT n'a pas besoin d'être fournie à l'application sur le VPS. Il suffit que l'application soit configurée pour écouter toutes les adresses. Le trafic envoyé à une plage de ports donnée sera automatiquement divisé par notre pont NAT et, lorsqu'il n'est pas possible d'atteindre directement l'adresse IPv6, il sera automatiquement acheminé via l'adresse IPv4.

Exemples de test pour TCP et UDP

Rappel : les ports sont toujours pré-ouverts automatiquement dans la plage donnée pour vous. Vous n'avez pas besoin de nous envoyer un ticket.

Exemple pour TCP : essayez de modifier /etc/ssh/sshd_config pour un port dans la plage de ports prévue de votre VPS.
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. Procédez maintenant comme suit :

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

afin que le service SSH redémarre. Assurez-vous qu'il écoute les deux formats avant de procéder à tout test.

Ensuite, vous pouvez essayer de vous connecter à l'aide de PuTTY, MobaXterm ou n'importe quel client SSH, en saisissant l'adresse IPv4 du serveur global, l'utilisateur Linux du VPS (root) et le port spécifique que vous venez de définir dans le service SSH. Tout fonctionnera parfaitement.

Ceci a été testé sur un client MobaXterm sous Windows et une connexion IPv4 uniquement, avec socat comme technologie sous-jacente, le 29-10-2024, sous AlmaLinux 9.4 et Debian 12.

Exemple pour UDP : installez netcat-openbsd, disponible sous les systèmes 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 exclusive UDP dont vous disposez sur votre VPS pour 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 n'importe quoi (texte, message, etc.) via UDP :

À partir de 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()

À partir de Linux
echo « Test UDP » | nc -u -w1 116.xxx.xxx.xxx [numéro de votre port]

où « 116.xxx.xxx.xxx » est l'adresse IPv4 publique globale au niveau du serveur dont vous disposez, et [numéro de votre port] sera le numéro de port exclusif UDP, qui doit être exactement le même que celui sur lequel votre processus écoute sur le VPS, ET ÉGALEMENT exactement le même que celui de votre plage de ports UDP.

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

Ceci a été testé le 29-10-2024, sur un client MobaXterm sous Windows et un accès IPv4 uniquement, via un VPS avec Debian 12. Socat est également la technologie sous-jacente.

Nous ne pouvons pas garantir que le paquet « nc » sous les systèmes basés sur RHEL soit l'équivalent technique du netcat-openbsd disponible sous Debian et Ubuntu (non testé), notamment en raison de leur habitude de revenir sur les modifications, mais nous pouvons vous assurer que le paquet netcat-traditional n'est pas adapté à cette tâche, car il ne prend pas en charge le paramètre -6 pour l'écoute IPv6.

Concernant la connectivité ICMP sur IPv4

Le ping ICMP IPv4 sortant sur MultiVPS, en dehors de la plage de ports allouée, n'est pas pris en charge, en raison d'une spécificité technique : l'implémentation DNS64 exécutée, à la fois sur le serveur principal et sur le service public de secours. L'en-tête du paquet est modifié au cours du processus, et le DNS64 doit d'abord traduire la requête en un nom de domaine adéquat, ce qui signifie qu'il n'est pas reconnaissable d'IP à IP.

Le ping d'une adresse IPv4 est donc pris en charge si cette adresse IPv4 est contenue dans un nom de domaine.

L'ICMP sur IPv6 vers IPv6 direct est toujours pris en charge dans tous les protocoles, qu'il s'agisse d'un ping vers une adresse IP ou vers un domaine.

Si vous voulez calculer les ports NAT IPv4 sur votre VPS, cliquez ici.