Ao se deparar com a questão e passar por uma grande quantidade de documentação, tente sistematizar e anotar o que aprendeu para melhor memorização. Além disso, faça um guia sobre esse assunto para que não precise passar por todo o caminho novamente.
A documentação original está amplamente disponível em
Formulação do problema
O cliente deseja unir vários servidores alugados em uma única rede para evitar a necessidade de pagar por várias sub-redes adicionais, conectar tudo ao roteador, atribuir endereços locais internamente e proteger-se com um firewall. Para que todo o tráfego da administração circule dentro da VLAN. Além disso, migrar as máquinas virtuais de um servidor antigo para um novo e descontinuar o antigo, atualizar o hardware usado e, ao mesmo tempo, migrar para um novo Proxmox.
Inicialmente, o cliente tem 5 servidores, cada um com uma sub-rede adicional, o primeiro endereço da sub-rede dedicada é atribuído a uma bridge adicional no Proxmox.
As VMs estão funcionando com Windows e têm o endereço 85.x.x.177/29 com gateway 85.x.x.176.
E de forma semelhante, todos os 5 servidores estão configurados com suas máquinas virtuais.
Curiosamente, essa configuração está errada na configuração da rede em princípio, usando o endereço da rede para o primeiro nó e o mesmo como gateway. Se tentar essa configuração em uma máquina virtual no Ubuntu, a rede não funcionará.
Implementação
- Criamos um vSwitch na interface, atribuímos um VlanID a ele e adicionamos esse vSwitch a todos os servidores necessários.
- Criamos um servidor de teste para que seja possível configurar e migrar sem problemas.
Subimos a primeira máquina virtual chr conforme .
Se você estiver usando o script fornecido, preste atenção que, no início, verifica-se a existência do diretório -d /root/temp, e se não existir, um diretório /home/root/temp é criado, mas o trabalho continua sendo feito com o diretório /root/temp. O script deve ser corrigido para criar o diretório correspondente.
- Configuramos a rede para Proxmox.
Adicionamos um subinterface com o número VLAN, indicando que a configuração de endereços ocorrerá nas bridges usando inet manual. IMPORTANTE. Não configure endereços IP nas interfaces que você irá incluir na bridge, pois como isso funcionará e se funcionará, ninguém sabe.
Em seguida, criaremos a ponte vmbr0 – e atribuímos a ela o primeiro endereço do servidor, fornecido pelo provedor Hetzner, indicando a porta da ponte – a primeira interface física sem VLAN, além de indicar com um comando adicional a adição da rota para nossa rede adicional, solicitada na Hetzner para este servidor através desta ponte. A adição da rota funcionará quando a interface for ativada.
A segunda ponte será a nossa interface para tráfego local, adicionamos um endereço para garantir a conectividade entre diferentes servidores Proxmox na rede local sem acesso à internet e indicamos como porta a subinterface eno1.4000, que foi designada para nosso VlanID.
Durante a configuração inicial, encontramos conselhos sobre a possibilidade de instalar adicionalmente o pacote ifupdown2 para que, ao alterar as interfaces de rede, o servidor não precise ser reiniciado completamente. No entanto, isso é característico apenas para a configuração primária, e ao usar pontes e configurar máquinas virtuais, surgem problemas de queda de rede nas VMs. Quando, por exemplo, você altera a interface vmbr2, ao aplicar a configuração, a rede cai em todas as interfaces internas e não se restaura até a reinicialização completa do servidor. ifdown&&ifup não ajudam. Se alguém tiver uma solução – serei grato.
A primeira interface configurada no servidor permanece funcional e acessível.
Atribuição de um endereço para CHR para não perder endereços do pool
O pool de endereços que a Hetzner fornece parece bastante estranho para um administrador de rede, aproximadamente assim:
A estranheza é que é sugerido usar o próprio endereço do servidor físico como gateway.
A opção clássica, proposta pela própria Hetzner, está descrita na formulação da tarefa e foi implementada pelo cliente de forma autônoma. Nesta opção, o cliente perde o primeiro endereço para o endereço da rede, o segundo endereço na ponte proxmox que também será o gateway, e o último endereço para o broadcast. Endereços IPv4 não são demais. Se você tentar diretamente atribuir ao CHR o endereço IP 136.x.x.177/29 e o gateway para 0.0.0.0/0 como 148.x.x.165, você conseguirá, no entanto, o gateway não estará Direct Connected e, portanto, será inatingível.
Você pode contornar a situação usando uma rede de 32 bits para cada endereço e como nome da rede, utilizando o endereço desejado, que pode ser qualquer um. Isso resulta em uma conexão semelhante a ponto a ponto.
Nesse caso, o gateway estará disponível, e tudo funcionará como precisamos.
Tenha em mente que, nessa configuração, não é recomendado usar a regra SRC-NAT masquerade, porque o endereço de saída será indefinidamente diferente; é melhor especificar a ação: src-NAT e o endereço específico a partir do qual você irá liberar o cliente.
- E por último.
Para bloquear o acesso ao próprio Proxmox da internet, use as ferramentas integradas: há um ótimo firewall.
Não é aconselhável usar o firewall oferecido pela hetzner, para não confundir o local das configurações. Além disso, a hetzner funcionará em todas as redes, incluindo aquelas configuradas no CHR, e para abrir e encaminhar portas, será necessário fazê-lo também na interface web do provedor.
Fonte: habr.com
