Al enfrentar un problema y revisar una gran cantidad de documentación, intenta sistematizar y registrar lo que has aprendido para recordar mejor. Además, crea una guía sobre este tema para no tener que recorrer todo el proceso nuevamente.
La documentación original está disponible en gran cantidad en
Planteamiento del problema
El cliente quiere combinar varios servidores alquilados en una sola red para eliminar la necesidad de pagar por varias subredes adicionales, conectar todo su equipo a través de un enrutador, asignarles direcciones locales dentro de la red y protegerse con un firewall. De este modo, todo el tráfico de servicio se moverá dentro de VLAN. Además, trasladar las máquinas virtuales de un viejo servidor a uno nuevo y abandonar el anterior, actualizar el hardware viejo utilizado y además mudarse a un nuevo Proxmox.
Inicialmente, el cliente tiene 5 servidores, cada uno con una subred adicional, la primera dirección de la subred asignada se destina a un puente adicional en Proxmox.
Las máquinas virtuales funcionan en Windows y tienen configurada la dirección 85.x.x.177/29 con la puerta de enlace 85.x.x.176.
Y de manera similar están configurados todos los 5 servidores con sus máquinas virtuales.
Es curioso que esta configuración es errónea en la configuración de red en principio, usar la dirección de red para el primer nodo y ésta también como puerta de enlace. Si intentas establecer tal configuración en una máquina virtual en Ubuntu, la red no funcionará.
Implementación
- Creamos un vSwitch en la interfaz, asignamos el VlanID a este vSwitch y lo añadimos a todos los servidores que necesitamos.
- Creamos un servidor de prueba para poder configurar y trasladar sin problemas.
Configuramos la primera máquina virtual chr según .
Si utilizas el script proporcionado, ten en cuenta que al inicio se verifica la existencia del directorio -d /root/temp, y si no existe, se crea el directorio /home/root/temp; sin embargo, el trabajo continúa usando el directorio /root/temp. Es necesario corregir el script para que cree el directorio correspondiente.
- Configuramos la red para Proxmox.
Añadimos un subinterfaz con el número VLAN, indicando que la configuración de direcciones se llevará a cabo en los puentes usando inet manual. IMPORTANTE. No se pueden configurar direcciones IP en las interfaces que luego incluirás en el puente, cómo funcionará esto y si funcionará en absoluto es desconocido para todos.
A continuación, creamos el puente vmbr0 y le asignamos la primera dirección del servidor, otorgada por nuestro proveedor Hetzner. Indicamos el puerto del puente como el primer interfaz físico sin VLAN, y también indicamos, con un comando adicional, la adición de una ruta a nuestra red adicional, contratada en Hetzner para este servidor a través de este puente. La adición de la ruta funcionará cuando la interfaz se active.
El segundo puente será nuestra interfaz para tráfico local. Añadimos una dirección para establecer conectividad entre diferentes servidores Proxmox a través de la red local sin salir a Internet, indicando como puerto la subinterfaz eno1.4000, que está designada para nuestro VlanID.
Durante la configuración inicial, se encuentran consejos que sugieren instalar el paquete ifupdown2 para Proxmox, lo que permite que el servidor no se reinicie por completo al realizar cambios en las interfaces de red. Sin embargo, esto solo se aplica a la configuración primaria, y al utilizar puentes y configurar máquinas virtuales, se presentan problemas de desconexión de red en las virtuales. Por ejemplo, al modificar la interfaz vmbr2, al aplicar la configuración, la red se desconecta en todas las interfaces internas y no se restablece hasta que se reinicia completamente el servidor. ifdown&&ifup no ayudan. Si alguien tiene una solución, lo agradecería.
La primera interfaz configurada en el servidor sigue siendo operativa y accesible.
Asignación de una dirección para CHR para no perder direcciones del pool.
El pool de direcciones que asigna Hetzner es bastante extraño para el administrador de red, aproximadamente así:
La extrañeza es que se sugiere utilizar la propia dirección del servidor físico como puerta de enlace.
La opción clásica, propuesta por Hetzner, se indica en el enunciado del problema y fue implementada de forma independiente por el cliente. En esta opción, el cliente pierde la primera dirección para la red, la segunda dirección para el puente proxmox, que también será la puerta de enlace, y la última dirección para el broadcast. Las direcciones IPv4 nunca sobran. Sin embargo, si intentas directamente asignar a CHR la dirección IP 136.x.x.177/29 y la puerta de enlace 0.0.0.0/0 148.x.x.165, podrás hacerlo, pero la puerta de enlace no estará conectada directamente y, por lo tanto, será inalcanzable.
Se puede encontrar una solución si se utiliza una red de 32 para cada dirección y se indica el nombre de la red como la dirección deseada, que puede ser cualquier dirección. Esto resulta en una conexión análoga a un punto a punto.
En este caso, la puerta de enlace estará disponible y todo funcionará como necesitamos.
Tenga en cuenta que en una configuración como esta no se recomienda utilizar la regla SRC-NAT masquerade, porque la dirección de salida será indefinidamente variable. Es más correcto especificar action: src-NAT y una dirección concreta desde la cual liberará al cliente.
- Y, por último.
Para bloquear el acceso a Proxmox desde internet, utilice las herramientas integradas: hay un excelente firewall.
No se debe utilizar el firewall ofrecido por Hetzner para no confundirse con la ubicación de la configuración. Además, Hetzner aplicará a todas las redes, incluidas las que están configuradas en CHR, y para abrir y redirigir puertos será necesario hacerlo también en la interfaz web del proveedor.
Fuente: habr.com
