Ir al contenido 
Te mostraré cómo puedes red hetzner y configurarlo correctamente para aumentar el rendimiento, la seguridad y la escalabilidad de forma selectiva. Adopto un enfoque práctico: desde el panel de la nube y las variantes de enrutamiento hasta las IP de conmutación por error, las MAC virtuales, IPv6, la seguridad, el diagnóstico de fallos y la supervisión.
Puntos centrales
- Espacio de direcciones elegir: Usar el RFC 1918 limpiamente, planificar subredes limpias.
- Modo determinar: Routed, Bridge o vSwitch en función de la aplicación.
- Linux-Configuración: ifupdown, netplan, systemd-networkd mantienen la coherencia.
- Conmutación por error & MAC: Asignar MAC virtuales correctamente, establecer rutas de host.
- Seguridad & Supervisión: Establecer segmentación, cortafuegos, registros y comprobaciones.
Aspectos básicos de la configuración de la red Hetzner
Una planificación adecuada evita gastos posteriores y aporta beneficios tangibles. Actuación. Separo los sistemas internos en una red en nube independiente, aíslo los componentes sensibles y mantengo el vector de ataque público pequeño, lo que minimiza el Seguridad aumentado significativamente. Las redes privadas de Hetzner Cloud me permiten un control granular, rutas claras para los flujos de datos y menos ruido de difusión. Defino desde el principio qué servidores necesitan direcciones públicas y cuáles sólo hablan internamente, de modo que el enrutamiento, los cortafuegos y la asignación de IP sigan siendo lógicos. Esta claridad merece la pena en cuanto entran en juego la conmutación por error, los equilibradores de carga o la orquestación de contenedores y tengo que gestionar varios servidores. Subredes claramente organizada.
Hetzner Cloud-Panel: Crear red y seleccionar espacio de direcciones
En el panel de la nube, creo una nueva red, asigno un nombre único por proyecto y selecciono un intervalo de direcciones RFC 1918 como 10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16 como el Bloque IP. Planifico las subredes en una fase temprana, como /24 para las capas de aplicaciones, /28 para el acceso a la administración o /26 para las bases de datos, de modo que el crecimiento quede claramente asignado. A continuación, integro servidores, equilibradores de carga y servicios adicionales para que la comunicación se establezca de inmediato. Para los recién llegados a la plataforma, me complace proporcionar el compacto Visión general del servidor en nubeque resume las opciones más importantes. En cuanto la red está lista, pruebo la accesibilidad básica y compruebo los grupos de seguridad para que no queden puertos innecesarios abiertos y mi Cortafuegos-Se aplican las normas.
Diseño detallado de subredes y planificación IP
Trabajo con convenciones claras de denominación y numeración para poder reconocer intuitivamente las subredes más adelante. Cada zona (por ejemplo, app, db, mgmt, edge) tiene un rango numérico fijo y un tamaño estándar documentado. Deliberadamente reservo zonas intermedias entre subredes para permitir ampliaciones sin renumeración. Cuando los servicios se escalan horizontalmente, prefiero planificar varios /25 o /26 en lugar de un gran /22; esto mantiene las ACL y las rutas reducidas. Mantengo un /28 de gestión separado para el acceso de administración, que endurezco constantemente y hago accesible a través de VPN o hosts bastión. Cuando conecto ubicaciones externas, defino desde el principio áreas claras que no se solapen y establezco rutas estáticas específicas para que no haya conflictos.
Routed, Bridge o vSwitch: el modo correcto
Me centro en tres variantes principales: Enrutado para subredes adicionales y direcciones de conmutación por error, bridge si los invitados van a actuar como sus propios servidores, y vSwitch para configuraciones flexibles y NAT. Con el modelo enrutado, las direcciones adicionales se adjuntan a la MAC principal del host; activo el reenvío IP para IPv4 e IPv6 y establezco rutas de host a la pasarela. Con Bridge, los invitados requieren una MAC visible en la red; solicito una MAC virtual para cada IP asignada y la vinculo al invitado. Combino vSwitch con masquerading para que las máquinas virtuales con direcciones privadas puedan acceder a Internet mientras los servicios internos permanecen blindados. Esta selección controla el esfuerzo posterior, Transparencia y tolerancia a fallos de mi plataforma.
| Modo | Utilice | Requisitos previos | Ventajas | Peligros de tropiezo |
|---|---|---|---|---|
| Enrutado | Subredes adicionales, IP de conmutación por error | Reenvío IP, ruta host | Enrutamiento claro, buena Escala | Mantener limpia la ruta pasarela/host |
| Puente | Invitados como "servidores propios" | MAC virtual por IP | Visibilidad real por huésped | Gestión de MAC en la Robot necesario |
| vSwitch + NAT | Máquinas virtuales privadas con Internet | Enmascaramiento, cortafuegos | Alto aislamiento interno | Mantener correctamente las reglas NAT |
Configuraciones híbridas: nube, dedicada y transiciones
En entornos híbridos, conecto redes en la nube con servidores dedicados a través de instancias de enrutador explícitas. Una subred de tránsito claramente definida y rutas estáticas garantizan que ambos lados solo vean los prefijos necesarios. Dependiendo de los requisitos de seguridad, permito que el tráfico pase a través de una instancia de borde mediante NAT o subredes de ruta de forma transparente. Es importante que la pasarela esté diseñada para una alta disponibilidad, por ejemplo, con dos máquinas virtuales de enrutador que comprueben el estado de la otra y tomen el control sin problemas en caso de fallo. También tengo preparada una lista de comprobación: rutas en el panel de la nube correctas, reenvío activo, estados de cortafuegos coherentes y comprobaciones de salud que no solo comprueban ICMP, sino también los puertos relevantes.
Configuración de Linux: uso correcto de ifupdown, netplan y systemd-networkd
En Debian/Ubuntu con ifupdown, almaceno la configuración en /etc/network/interfaces o en /etc/network/interfaces.d y guardo el archivo Ruta del host correcto. Para el direccionamiento IP del host utilizo /32 (255.255.255.255) y configuro la puerta de enlace como pointopoint para que el kernel conozca al vecino. Bajo netplan (Ubuntu 18.04, 20.04, 22.04) defino direcciones, rutas y on-link para que la ruta por defecto coincida inmediatamente. Si cambio el hardware, compruebo la designación de la interfaz y la cambio de eth0 a enp7s0, por ejemplo, para que la tarjeta de red vuelva a funcionar. Para systemd-networkd, administro los archivos .network y .netdev, recargo los servicios y luego pruebo siempre DNS, enrutamiento y Conectividad.
Ajuste de la red: MTU, descarga, direccionamiento de políticas
Compruebo la MTU de extremo a extremo, sobre todo cuando entran en juego VPN, superposiciones o túneles. Si los valores no son correctos, se producen fragmentaciones o caídas. Activo el sondeo de MTU TCP en las pasarelas y coloco abrazaderas MSS en los lugares adecuados para mantener la robustez de las conexiones. Utilizo las funciones de descarga (GRO/LRO/TSO) deliberadamente: las desactivo parcialmente en los hipervisores o para la grabación de paquetes, pero las dejo activadas para las rutas de datos puras, en función de los valores medidos. Si tengo varios flujos ascendentes o políticas de salida diferenciadas, utilizo enrutamiento basado en políticas con mis propias tablas de enrutamiento y reglas ip. Documento cada regla especial para que los cambios posteriores no desencadenen efectos secundarios inadvertidos.
IP de conmutación por error, MAC virtuales y equilibradores de carga en la práctica
Para IPs adicionales que aplico en el Robot Hetzner por dirección un virtual MAC y las asigno al invitado para que ARP funcione correctamente. En la configuración enrutada, la MAC principal permanece en el host y enruto subredes explícitamente al invitado. En los escenarios de puente, al invitado se le asigna su propia MAC visible, para que actúe como un servidor independiente. Para la conmutación por error, defino qué máquina anuncia actualmente la IP; al conmutar, ajusto el enrutamiento y, si es necesario, la gratuidad ARP para que el tráfico llegue inmediatamente. Utilizo equilibradores de carga para desacoplar el tráfico del front-end de los sistemas back-end, garantizar una distribución uniforme y aumentar así el Disponibilidad.
Diseño limpio de las conmutaciones IP
Confío en mecanismos claros para las conmutaciones activas: o bien la instancia activa anuncia una IP mediante ARP/NDP y la pasiva permanece en silencio, o bien extraigo específicamente la ruta por defecto a la nueva máquina activa. Herramientas como las implementaciones VRRP ayudan, pero siempre pruebo toda la interacción, incluidos los cortafuegos, las cachés de vecinos y los posibles plazos ARP. Importante: Tras el cambio, compruebo la accesibilidad tanto desde la red interna como desde puntos de control externos. Para los servicios con muchas conexiones TCP, programo breves periodos de gracia para que las sesiones abiertas expiren limpiamente o se restablezcan rápidamente.
Configurar IPv6: Implementación limpia de la pila dual
Activo IPv6 en paralelo con IPv4 para que los clientes puedan utilizar los modernos Conectividad y los cortafuegos están duplicados. Para cada interfaz, establezco los prefijos asignados, la ruta de pasarela y compruebo el descubrimiento de vecinos y la asignación SLAAC o estática. Compruebo si los servicios deben escuchar en :: y 0.0.0.0 o si tienen sentido enlaces separados. Las pruebas con ping6, tracepath6 y curl mediante registros AAAA me muestran si el DNS y el enrutamiento son correctos. En los cortafuegos, reflejo las reglas de IPv4 a IPv6 para que no queden huecos abiertos y pueda usar las mismas Nivel de seguridad alcanzar.
Seguridad: segmentación, reglas, endurecimiento
Segmento las redes según su función, como app, datos, gestión y transiciones seguras con una clara ACLs. Cada departamento sólo obtiene el acceso que necesita, mientras que el acceso de administración se realiza a través de VPN o hosts bastión. Los cortafuegos bloquean todo el tráfico entrante por defecto, y luego permiten puertos específicos para los servicios. Protejo SSH con claves, controles de puertos, límites de velocidad y bloqueo opcional de puertos para invalidar los escaneos. Pruebo los cambios de forma controlada, los documento inmediatamente y los revierto con rapidez en caso de problemas para que la Seguridad operativa sigue siendo elevado.
Orquestación de cortafuegos de nube y host
Combino cortafuegos en la nube con reglas basadas en host. Los primeros me proporcionan una capa central que restringe de forma fiable el acceso básico, mientras que las segundas protegen las cargas de trabajo de forma granular y pueden planificarse. La coherencia es importante: a los puertos estándar y al acceso de gestión se les asignan reglas idénticas en todas las zonas. Mantengo las políticas de salida restrictivas para que sólo se pueda acceder a los objetivos definidos. Para entornos sensibles, también utilizo hosts de salto con acceso de corta duración y protección multifactor. Correlaciono los registros de forma centralizada para comprender rápidamente los bloqueos y reducir las falsas alarmas.
Solución de problemas: reconocer rápidamente los errores típicos
Si un servidor no tiene red después de un swap, primero compruebo el nombre de la interfaz y ajusto el Configuración on. Si el enrutamiento falla, reactivo el reenvío IP y compruebo las rutas del host y la puerta de enlace predeterminada. Los errores de escritura en las direcciones, máscaras de red o en el enlace a menudo conducen a la imposibilidad de llegar; comparo la configuración y las rutas reales del núcleo. En caso de problemas con los puentes, compruebo las MAC virtuales y las tablas ARP para asegurarme de que las asignaciones son correctas. Los registros en /var/log/syslog, journalctl y dmesg me proporcionan información sobre controladores, errores DHCP o bloqueos. Paquetes.
Solución sistemática de problemas y diagnóstico de paquetes
- Comprobación de capa: enlace, velocidad/dúplex, estado de VLAN/puente, luego IP/ruta, luego servicios.
- Comparación real/objetivo: dirección ip/ruta/regla frente a archivos config, registrar las desviaciones por escrito.
- Registro de paquetes: dirigido a la interfaz y al host, observar la descarga, comprobar TLS-SNI/ALPN.
- Comprobación cruzada: pruebas de múltiples fuentes (internas/externas) para detectar problemas asimétricos.
- Capacidad de retroceso: planifique una ruta de retorno definida antes de cada cambio.
Supervisión, documentación y ampliación específicas
Superviso la latencia, la pérdida de paquetes y el jitter con comprobaciones ICMP, comprobaciones de puertos y análisis de flujos para poder detectar anomalías a tiempo y Tendencias reconocer. Hago copias de seguridad de las versiones de los estados de configuración, describo los cambios con precisión milimétrica y tengo listos los playbooks. Para los registros DNS y las convenciones de nomenclatura limpias, utilizo el sistema compacto Guía DNSpara que los servicios puedan resolverse de forma coherente. A medida que crece la plataforma, amplío las subredes, añado más equilibradores de carga y estandarizo los grupos de seguridad. Esto me permite escalar con seguridad, minimizar las interrupciones y mantener normas de seguridad claras. Estructuras.
Automatización: Terraform, Ansible y rollouts coherentes
Construyo redes reproducibles: Nombres, subredes, rutas, cortafuegos y asignaciones de servidores se mapean como código. Esto me permite crear topologías de ensayo y producción idénticas, probar los cambios por adelantado y reducir los errores de escritura. A nivel de host, genero archivos de configuración a partir de plantillas e inyecto parámetros como IP, puerta de enlace, rutas y MTU por rol. Utilizo Cloud-init para configurar la red y los aspectos básicos de SSH directamente durante el aprovisionamiento del servidor. Cuando realizo cambios, primero los valido en la fase de puesta en marcha, luego los aplico en pequeños lotes y vigilo de cerca la telemetría.
Gestión de cambios y capacidades
Planifico ventanas de mantenimiento y defino niveles de reserva. Cada cambio en la red se somete a un pequeño plan de pruebas con puntos de medición antes y después del cambio. En cuanto a la capacidad, me fijo en el rendimiento por zona, las cargas de conexión en las pasarelas y el desarrollo de conexiones/minuto. Antes de que se produzcan cuellos de botella, añado puertas de enlace adicionales o separo las rutas de tráfico (este/oeste frente a norte/sur). Mantengo actualizada la documentación: Los planes de IP, los esquemas de enrutamiento, las políticas de cortafuegos y las responsabilidades están al día y son fáciles de encontrar para el equipo.
Comparación de proveedores para proyectos intensivos en redes
Evalúo a los proveedores según su conexión, gama de funciones, facilidad de uso y Flexibilidad. Para proyectos con altos requisitos de red, sitúo a webhoster.de en lo más alto por sus redes dedicadas y su versátil personalización. Hetzner ofrece potentes servidores dedicados y en la nube que se adaptan muy bien a muchos escenarios y puntúan muy alto. Strato cubre los casos de uso estándar, mientras que IONOS ofrece buenas opciones en algunos casos, pero da menos margen para configuraciones especiales. Esta categorización me ayuda a elegir la base adecuada y a tomar decisiones posteriores. Cuellos de botella que hay que evitar.
| Lugar | Proveedor | Características de la red | Actuación |
|---|---|---|---|
| 1 | webhoster.de | Redes dedicadas, conexión rápida, gran capacidad de personalización | Destacado |
| 2 | Hetzner | Potentes servidores dedicados y en la nube | Muy buena |
| 3 | Strato | Funciones de red estándar | Bien |
| 4 | IONOS | Opciones de gama alta, margen limitado para configuraciones personalizadas | Bien |
Kubernetes y las redes de contenedores en la práctica
Para la orquestación de contenedores, pongo los cimientos en la red. Los trabajadores reciben interfaces en la red privada, el plano de control está claramente segmentado y los pods con mucha salida reciben una ruta NAT definida. Elijo un CNI que se adapte a la configuración: Las variantes basadas en enrutamiento me facilitan la resolución de problemas y ahorran sobrecargas de superposición, mientras que las superposiciones suelen ofrecer más flexibilidad en términos de aislamiento. Los equilibradores de carga desacoplan Ingress de los backends; las comprobaciones de estado son idénticas a las de la aplicación, no sólo simples comprobaciones TCP. También ejecuto pilas duales en el clúster para que se pueda acceder limpiamente a los servicios a través de registros AAAA. Para los servicios con estado, defino políticas de red claras (este/oeste) para que sólo estén abiertos los puertos necesarios entre los pods. Siempre pruebo las actualizaciones de los componentes CNI y Kube en un clúster de prueba, incluyendo el rendimiento, la latencia y los escenarios de fallo.
Rendimiento bajo carga: optimización cuantificable
Mido con regularidad: la latencia de referencia dentro de las zonas, la latencia hacia los puntos finales públicos, el rendimiento de puerto a puerto y los requisitos de RTO/RPO para los servicios críticos. Los cuellos de botella suelen producirse en algunos puntos: Pasarelas NAT, cortafuegos con estado sobrecargados, tablas de seguimiento de conexiones demasiado pequeñas o, simplemente, poca CPU en los routers. Yo aumento sistemáticamente la capacidad, distribuyo los flujos, activo las colas múltiples en las NIC y presto atención al equilibrio de pines/IRQ cuando procede. Es fundamental evitar la inspección de estado innecesaria en las redes troncales puras este/oeste y, en su lugar, establecer ACL claras. Para la descarga TLS, separo el tráfico de datos del tráfico de control para que las cargas de trabajo L7 no compitan con las conexiones de gestión. Todo esto lo documento con valores iniciales y objetivos: las optimizaciones sólo están "terminadas" cuando aportan beneficios cuantificables.
Breve resumen: Cómo instalar eficazmente las redes Hetzner
Empiezo con un plan claro, defino los espacios de dirección, selecciono las Modo y documento cada paso. A continuación, configuro las redes Linux de forma coherente, activo el reenvío de IP si es necesario y pruebo a fondo el enrutamiento y el DNS. Integro IPs de conmutación por error y MACs virtuales de forma estructurada para que las conmutaciones funcionen sin problemas. La seguridad sigue siendo alta gracias a la segmentación, los cortafuegos potentes y la aplicación sistemática de parches, mientras que la supervisión revela las irregularidades en una fase temprana. Así consigo hetzner ofrece un rendimiento fiable al tiempo que mantiene la flexibilidad de la plataforma para el crecimiento.
