Base de connaissances

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

(Dernière mise à jour : 25-02-2025. Inclut la traduction des langues)

Le ping de site web ICMP sortant via IPv4 sur MultiVPS, en dehors de la plage de ports allouée, n'est généralement pas supporté, en raison d'une spécificité technique - l'implémentation NAT64 exécutée, à la fois sur le serveur principal et sur le fallback du service public. L'en-tête du paquet est modifié, ce qui signifie qu'il ne serait pas reconnaissable.

ICMP over direct IPv6-to-IPv6 est toujours supporté dans tous les protocoles.

Si vous souhaitez utiliser la plage de 10 ports pour TCP ou la plage de 5 ports pour UDP, prévue par notre implémentation NAT IPv4

L'alternative est de tester toute connexion en utilisant un processus qui est à l'écoute, sur le VPS et sur IPv6, puis d'essayer d'envoyer quelque chose de l'autre côté sur les ports liés. Rappelez-vous que les ports sont toujours pré-ouverts dans la plage donnée pour vous.

Exemple pour TCP : essayez de changer /etc/ssh/sshd_config pour un port dans la plage de ports prédite de votre VPS.
Assurez-vous que « PubkeyAuthentication » est réglé sur No et décommenté (sans le #), et que « PasswordAuthentication » est réglé sur Yes et décommenté. Sauvegardez. Maintenant, faites :

sudo systemctl restart sshd

pour que le service SSH redémarre. Assurez-vous qu'il est à l'écoute sur les deux formats avant tout test.

Après cela, vous pouvez essayer de vous connecter en utilisant PuTTY, MobaXterm ou n'importe quel client SSH, en insérant l'IPv4 du serveur global, l'utilisateur Linux du VPS (root) et le port spécifique que vous venez de mettre sur le service SSH, et cela 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, et exécutez la commande suivante :

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

où [numéro de votre port] sera la plage de ports exclusifs UDP que vous avez sur votre VPS pour le NAT IPv4 (consultez l'article de la Base de Connaissances pour le calcul des ports NAT IPv4).

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

Après cela, essayez d'envoyer quoi que ce soit (texte, message, 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()

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

où « 116.xxx.xxx.xxx » est l'IPv4 global public au niveau du serveur que vous avez, et [numéro de votre port] sera le numéro de port exclusif UDP, qui doit être le même numéro de port exact que celui que votre processus écoute sur le VPS, ET AUSSI le même numéro de port exact de votre plage de ports UDP.

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

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 de netcat-openbsd disponible sous Debian et Ubuntu (n'a pas été testé), notamment à cause de leur habitude de revenir sur les changements, mais nous pouvons 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 d'IPv6.

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