Base de conocimientos

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

Prueba del rango de puertos NAT

Para que funcione según lo previsto, la aplicación que desea ejecutar a través del sistema NAT IPv4 debe cumplir los siguientes requisitos:
- La aplicación debe ser de doble pila (es decir, admitir conectividad IPv4 e IPv6).
- Debe poder escuchar en formatos de dirección IPv6 e IPv4 (es decir, [::]::0 y 0.0.0.0/0, las direcciones generales para IPv6 e IPv4).
- Específico solo para el uso de UDP: debe enviar un flujo continuo de paquetes a través de UDP.

Casi todas las aplicaciones escritas para Linux admiten conectividad de doble pila. Entre las excepciones notables y conocidas se incluyen:
- SOCKS 4 y SOCKS 4a (es compatible con SOCKS 5);
- Docker solo con versiones inferiores a la 27.0.1 (que se lanzó el 24 de junio de 2024). Algunas distribuciones siguen implementando la versión anterior 26, principalmente Debian 12 y 13, por ejemplo; Se ha confirmado que Ubuntu 24.04 LTS es compatible con Docker en la versión 27.5, por ejemplo, lo que lo convierte en una alternativa viable;
- Kubernetes (solo versiones anteriores a diciembre de 2021). Debian 10 no es compatible, la primera compatibilidad es en Debian 11.
- Otro software anterior a 2017/2018.

La dirección IPv4 NAT informada en las calculadoras de puertos NAT que tenemos no es necesario proporcionarla a la aplicación en el VPS. Basta con que la aplicación esté configurada para escuchar todas las direcciones. El tráfico enviado en un rango de puertos determinado se dividirá automáticamente mediante nuestro puente NAT y, cuando no sea posible acceder directamente a través de la dirección IPv6, se enrutará automáticamente a través de la IPv4.

Ejemplos de prueba para TCP y UDP

Recuerde: los puertos siempre se abren automáticamente en el rango dado para usted. No es necesario que nos envíe un ticket.

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é configurado en No y sin comentar (sin el símbolo #), y que «PasswordAuthentication» esté configurado en Yes y sin comentar. Guarde. Ahora haga lo siguiente:

sudo systemctl restart sshd [para Debian, AlmaLinux, Rocky Linux, Fedora], o
sudo systemctl restart ssh [para Ubuntu]

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

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

Esto se probó en un cliente MobaXterm bajo Windows y una conexión solo IPv4, con socat como tecnología subyacente, el 29-10-2024, bajo AlmaLinux 9.4 y Debian 12.

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

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

donde [número de tu puerto] será el rango de puertos exclusivo de UDP que tienes en tu VPS para NAT IPv4 (consulta el artículo de la base de conocimientos para el cálculo del puerto NAT IPv4).

El proceso comenzará a escuchar, a través de IPv6, en el puerto que haya elegido, y permanecerá así.

Después de eso, intente enviar cualquier cosa (texto, mensaje, etc.) a través de UDP:

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

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

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

Si recibe «Test UDP» en su VPS, todo funciona correctamente.

Esto se probó el 29-10-2024, en un cliente MobaXterm bajo Windows y un acceso solo 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» en sistemas basados en RHEL sea el equivalente técnico del netcat-openbsd disponible en Debian y Ubuntu (no se ha probado), también debido a su costumbre de dar marcha atrás en los cambios, pero podemos asegurar que el paquete netcat-traditional no es adecuado para esta tarea, ya que no admite el parámetro -6 para la escucha IPv6.

En cuanto a la conectividad ICMP sobre IPv4

El ping ICMP IPv4 saliente en MultiVPS, fuera del rango de puertos asignado, no es compatible debido a una especificidad técnica: la implementación de DNS64 ejecutada, tanto en el servidor principal como en el servicio público de respaldo. El encabezado del paquete se modifica en el proceso y el DNS64 necesita traducir primero la solicitud a un nombre de dominio adecuado, lo que significa que no es reconocible de IP a IP.

Por lo tanto, el ping a una IPv4 se puede hacer si esa IPv4 está contenida como nombre de dominio.

El ICMP sobre IPv6 a IPv6 directo siempre es compatible en todos los protocolos, independientemente de si se realiza un ping a una IP o a un dominio.

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