Base de conocimientos

ICMP - Pings IPv4 y NAT Pruebas de rango de puertos IPv4

(Última actualización: 25-02-2025. Incluye traducción de idiomas.)

El ping ICMP saliente a sitios web vía IPv4 en MultiVPS, fuera del rango de puertos asignado, no es soportado en su mayoría, debido a una especificidad técnica - la implementación NAT64 ejecutada, tanto en el servidor principal como en el fallback de servicio público. La cabecera del paquete es cambiada, lo que significa que no sería reconocible.

ICMP sobre IPv6-a-IPv6 directo es siempre soportado en todos los protocolos.

Si desea utilizar el rango de 10 puertos para TCP o el rango de 5 puertos para UDP, previsto por nuestra implementación NAT IPv4

La alternativa a esto es probar cualquier conexión usando un proceso que esté escuchando, en el VPS y sobre IPv6, y luego intentar enviar cualquier cosa desde el otro lado sobre los puertos enlazados. Recuerde, los puertos están siempre pre-abiertos en el rango dado para usted.

Ejemplo para TCP: intente cambiar /etc/ssh/sshd_config a un puerto dentro del rango de puertos previsto de su VPS.
Asegúrese de que «PubkeyAuthentication» está en No y sin comentar (sin el #), y «PasswordAuthentication» está en Sí y sin comentar. Guardar. Ahora haga:

sudo systemctl restart sshd

para que el servicio SSH se reinicie. Asegúrese de que está escuchando en ambos formatos antes de cualquier prueba.

Después de eso, puede intentar iniciar sesión usando PuTTY, MobaXterm o cualquier cliente SSH, insertando la IPv4 del servidor global, el usuario Linux del VPS (root) y ese puerto específico que acaba de poner en el servicio SSH, y funcionará sin problemas.

Esto fue probado en un cliente MobaXterm bajo Windows y una conexión sólo IPv4, con socat como tecnología subyacente, en 29-10-2024, bajo AlmaLinux 9.4 y Debian 12.

Ejemplo para UDP: instale netcat-openbsd, disponible bajo sistemas Debian o Ubuntu. Después de la instalación, asegúrese de que no desea ejecutar ningún otro comando antes de netcat, y ejecute el siguiente comando:

nc -6 -u -l -p [número de su puerto]

donde [número de su puerto] será el rango de puertos exclusivos UDP que tiene en su VPS para NAT IPv4 (revise el artículo de la Base de Conocimiento para el cálculo de puertos NAT IPv4).

El proceso empezará a escuchar, sobre IPv6, en el puerto que has elegido, y se quedará así.

Después, intenta enviar cualquier cosa (texto, mensaje, etc) vía UDP:

Desde Windows Powershell
$mensaje = «Prueba UDP»; $udpClient = Nuevo-Objeto System.Net.Sockets.UdpClient; $udpClient.Connect(«116.xxx.xxx.xxx», [número de su puerto]); $bytes = [Text.Encoding]::ASCII.GetBytes($mensaje); $udpClient.Send($bytes, $bytes.Length); $udpClient.Close()

Desde Linux
echo «Prueba UDP» | nc -u -w1 116.xxx.xxx.xxx [número de su puerto]

donde «116.xxx.xxx.xxx» es el IPv4 global público a nivel de servidor que tiene, y [número de su puerto] será el número de puerto exclusivo UDP, que debe ser el mismo número exacto de puerto que su proceso está escuchando en el VPS, Y TAMBIÉN el mismo número exacto de puerto de su rango de puertos UDP.

Si usted recibe «Test UDP» en su VPS, todo está funcionando.

Esto fue probado en 29-10-2024, en un cliente MobaXterm bajo Windows y un acceso sólo IPv4, a través de un VPS con Debian 12. Socat es también la tecnología subyacente.

No podemos garantizar que el paquete «nc» bajo sistemas basados en RHEL sea el equivalente técnico del netcat-openbsd disponible en Debian y Ubuntu (no fue probado), también debido a su costumbre de retroceder en los cambios, pero podemos asegurar que el paquete netcat-tradicional no es adecuado para esta tarea, porque no soporta el parámetro -6 para escucha IPv6.

Si desea calcular los puertos NAT IPv4 en su VPS, haga clic aquí.