Solución:
Hetzner había dejado de asignar direcciones IPv4 públicas a servidores virtuales. Por lo que puedo decir, este cambio ocurrió cuando cambiaron el nombre del producto de VQ a CX. Sin embargo, el uso de NAT no se menciona en la descripción del producto.
Finalmente, Hetzner introdujo una plataforma en la nube más nueva en la que las máquinas virtuales obtienen direcciones IPv4 públicas reales y un prefijo IPv6 enrutado / 64. Ambas versiones comparten el nombre CX.
Los servidores virtuales pedidos en 2012 y 2013 mantendrían su dirección IPv4 pública hasta 2019, cuando se suspendió la línea VQ. Pero los servidores virtuales pedidos en 2016 solo tienen una dirección RFC1918, y Hetzner no enrutará una dirección IPv4 pública a dicho servidor virtual.
Aún así, asignaron una dirección IPv4 pública dedicada a cada servidor virtual, que NAT a la dirección RFC1918 asignada. Hetzner creía que esto no era un problema porque era un NAT 1: 1.
Como descubrió, esto es propenso a errores al configurar el servidor. Tienes que conocer este NAT. Y tienes que buscar el mapeo cada vez que configuras algo. Para el primer servidor virtual que obtuvimos en tal configuración, se configuró incorrectamente dos veces en los primeros días debido a esto.
Cualquier software que se base en conocer la dirección IPv4 pública se romperá o necesitará una configuración especial. Además, algunas VPN y túneles IP pueden tener problemas porque los paquetes tunelizados no se convertirán en NAT.
Si ha establecido que estos problemas potenciales no afectan su uso previsto, y si se siente cómodo con tener que tener en cuenta la asignación entre direcciones públicas y privadas al realizar cambios de configuración, puede aceptar la situación.
Sin embargo, tenga en cuenta que la mayoría de las implementaciones de NAT tienen estado. Si el NAT es de hecho con estado, es posible que las conexiones TCP se detengan cuando se pierde el estado.
No sé si el NAT utilizado por Hetzner tiene estado o no. La forma más obvia en la que podría pensar en las pruebas de estado es en el establecimiento de la conexión del túnel y deshabilitar el túnel una vez que se establece una conexión TCP. Por desgracia, este tipo de tunelización es exactamente lo que no funcionará, por lo que para realizar este experimento, primero tendría que replicar su configuración NAT 1: 1. No intenté este experimento bastante complicado.
Estas son las opciones que tienes:
- Actualice a la línea CX más nueva en la que Hetzner le dará una dirección IPv4 real y un prefijo IPv6 enrutado / 64.
- Acepte que su tráfico pasará por un NAT 1: 1 con los inconvenientes que presenta.
- Realice todo su tráfico importante en IPv6, ya que Hetzner enruta el tráfico IPv6 correctamente sin NAT.
- Cambie a un servidor dedicado (suponiendo que aún obtengan una dirección IPv4 pública, lo cual es difícil de averiguar ya que el uso de NAT no se menciona en ninguna parte de la descripción del producto).
- Cambie a otro proveedor.