Configuração de rede Hetzner - dicas profissionais para as suas próprias configurações

Vou mostrar-vos como podem rede hetzner e configurá-lo corretamente para aumentar o desempenho, a segurança e a escalabilidade de uma forma orientada. Faço uma abordagem prática: desde o painel da nuvem e as variantes de encaminhamento até IPs de failover, MACs virtuais, IPv6, segurança, diagnóstico de falhas e monitorização.

Pontos centrais

• Espaço de endereçamento escolher: Utilizar o RFC 1918 de forma limpa, planear sub-redes limpas.
• Modo determinar: Routed, Bridge ou vSwitch, consoante a aplicação.
• Linux-Configuração: ifupdown, netplan, systemd-networkd manter a coerência.
• Transferência em caso de falha MAC: Atribuir corretamente MACs virtuais, definir rotas de anfitriões.
• Segurança & Monitorização: Estabelecer segmentação, firewalls, registos e verificações.

Noções básicas da configuração de rede Hetzner

Um planeamento adequado evita despesas posteriores e proporciona benefícios tangíveis. Desempenho. Eu separo os sistemas internos numa rede de nuvem separada, isolo os componentes sensíveis e mantenho o vetor de ataque público pequeno, o que minimiza a Segurança aumentou significativamente. As redes privadas na Hetzner Cloud permitem-me um controlo granular, caminhos claros para os fluxos de dados e menos ruído de difusão. Defino desde o início quais os servidores que necessitam de endereços públicos e quais os que apenas falam internamente, para que o encaminhamento, as firewalls e a atribuição de IP permaneçam lógicos. Esta clareza compensa assim que o failover, os equilibradores de carga ou a orquestração de contentores entram em jogo e tenho de gerir vários servidores. Sub-redes claramente organizado.

Hetzner Cloud-Panel: Criar rede e selecionar espaço de endereço

No painel da nuvem, crio uma nova rede, atribuo um nome exclusivo por projeto e selecciono um intervalo de endereços RFC 1918, como 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16, como o Bloco IP. Planeio sub-redes numa fase inicial, como /24 para camadas de aplicações, /28 para acesso à administração ou /26 para bases de dados, de modo a que o crescimento permaneça claramente mapeado. Em seguida, integro servidores, equilibradores de carga e serviços adicionais para que a comunicação seja estabelecida imediatamente. Para os recém-chegados à plataforma, tenho todo o gosto em fornecer o compacto Visão geral do servidor em nuvemque resume as opções mais importantes. Assim que a rede está pronta, testo a acessibilidade básica e verifico os grupos de segurança, para que não sejam deixadas portas desnecessárias abertas e o meu FirewallAplicam-se as regras.

Conceção de sub-redes e planeamento de IP em pormenor

Trabalho com convenções claras de nomeação e numeração para poder reconhecer intuitivamente as sub-redes mais tarde. A cada zona (por exemplo, app, db, mgmt, edge) é atribuído um intervalo de números fixo e um tamanho padrão documentado. Reservo deliberadamente áreas tampão entre sub-redes para permitir extensões sem renumeração. Nos casos em que os serviços escalam horizontalmente, prefiro planear vários /25 ou /26 em vez de um grande /22; isto mantém as ACLs e as rotas reduzidas. Mantenho um /28 de gestão separado para acesso de administrador, que fortaleço de forma consistente e torno acessível através de VPN ou bastion hosts. Quando ligo locais externos, defino áreas claras e não sobrepostas desde o início e defino rotas estáticas especificamente para que não haja conflitos.

Routed, Bridge ou vSwitch: o modo correto

Estou a centrar-me em três variantes principais: Encaminhado para sub-redes adicionais e endereços de failover, bridge se os convidados tiverem que agir como seus próprios servidores, e vSwitch para configurações flexíveis e NAT. Com o modelo encaminhado, os endereços adicionais são anexados ao MAC principal do anfitrião; ativo o encaminhamento de IP para IPv4 e IPv6 e defino rotas do anfitrião para o gateway. Com o Bridge, os convidados necessitam de um MAC visível na rede; solicito um MAC virtual para cada IP atribuído e ligo-o ao convidado. Combino o vSwitch com o masquerading para que as VMs com endereços privados possam aceder à Internet enquanto os serviços internos permanecem protegidos. Esta seleção controla o esforço posterior, Transparência e tolerância a falhas da minha plataforma.

Modo	Utilização	Pré-requisitos	Vantagens	Perigos de tropeçar
Encaminhado	Sub-redes adicionais, IPs de failover	Reencaminhamento IP, rota do anfitrião	Encaminhamento claro, bom Escalonamento	Manter a rota gateway/hospedeiro de forma limpa
Ponte	Convidados como "servidores próprios"	MAC virtual por IP	Visibilidade real por hóspede	Gestão MAC no Robô necessário
vSwitch + NAT	VMs privadas com Internet	Masquerading, Firewall	Elevado isolamento interno	Manter as regras NAT corretamente

Configurações híbridas: nuvem, dedicada e transições

Em ambientes híbridos, ligo redes em nuvem a servidores dedicados através de instâncias de router explícitas. Uma sub-rede de trânsito claramente definida e rotas estáticas garantem que ambos os lados vejam apenas os prefixos necessários. Dependendo dos requisitos de segurança, permito que o tráfego passe por uma instância de borda via NAT ou roteie sub-redes de forma transparente. É importante que o gateway seja concebido para alta disponibilidade - por exemplo, com duas VMs de router que verificam o estado uma da outra e assumem o controlo sem problemas em caso de falha. Também tenho uma lista de verificação pronta: as rotas no painel da nuvem estão corretas, o reencaminhamento está ativo, os estados da firewall são consistentes e as verificações de saúde verificam não só o ICMP, mas também as portas relevantes.

Configuração do Linux: utilização correta do ifupdown, netplan e systemd-networkd

Em Debian/Ubuntu com ifupdown eu armazeno a configuração em /etc/network/interfaces ou em /etc/network/interfaces.d e mantenho o Rota do anfitrião correto. Para o endereçamento IP do anfitrião, utilizo /32 (255.255.255.255) e defino a gateway como pointopoint para que o kernel conheça o vizinho. No netplan (Ubuntu 18.04, 20.04, 22.04) eu defino endereços, rotas e on-link para que a rota padrão corresponda imediatamente. Se eu trocar de hardware, verifico a designação da interface e altero-a de eth0 para enp7s0, por exemplo, para que a placa de rede volte a funcionar. Para o systemd-networkd, eu gerencio os arquivos .network e .netdev, recarrego os serviços e então sempre testo DNS, roteamento e Conectividade.

Afinação da rede: MTU, descarregamento, encaminhamento de políticas

Verifico o MTU de ponta a ponta, especialmente quando entram em jogo VPNs, sobreposições ou túneis. Se os valores não estiverem corretos, ocorrem fragmentações ou quedas. Ativo a sondagem de MTU TCP nas gateways e defino grampos MSS em locais adequados para manter as ligações robustas. Utilizo as funcionalidades de descarregamento (GRO/LRO/TSO) deliberadamente: desativo-as parcialmente em hipervisores ou para gravação de pacotes, mas deixo-as activas para caminhos de dados puros - dependendo dos valores medidos. Se tenho vários fluxos ascendentes ou políticas de saída diferenciadas, utilizo o encaminhamento baseado em políticas com as minhas próprias tabelas de encaminhamento e regras ip. Eu documento cada regra especial para que alterações posteriores não provoquem efeitos colaterais despercebidos.

IPs de failover, MACs virtuais e balanceadores de carga na prática

Para IPs adicionais, aplico no Robô Hetzner por endereço virtual MAC e atribuo-os ao convidado para que o ARP funcione corretamente. Na configuração roteada, o MAC principal permanece no host e eu roteio as sub-redes explicitamente para o convidado. Em cenários de ponte, o convidado recebe o seu próprio MAC visível, para que actue como um servidor independente. Para a transferência em caso de falha, defino qual a máquina que anuncia atualmente o IP; ao mudar, ajusto o encaminhamento e, se necessário, o ARP gratuito para que o tráfego chegue imediatamente. Utilizo equilibradores de carga para dissociar o tráfego de front-end dos sistemas de back-end, garantir uma distribuição uniforme e, assim, aumentar a Disponibilidade.

Conceção simples das comutações IP

Eu confio em mecanismos claros para comutações activas: ou a instância ativa anuncia um IP através de ARP/NDP e a passiva permanece em silêncio, ou eu especificamente puxo a rota padrão para a nova máquina ativa. Ferramentas como implementações de VRRP ajudam, mas eu sempre testo toda a interação, incluindo firewalls, caches de vizinhos e possíveis prazos de ARP. Importante: Após a troca, verifico a acessibilidade tanto da rede interna quanto de pontos de teste externos. Para serviços com muitas ligações TCP, programo períodos de carência curtos para que as sessões abertas expirem de forma limpa ou sejam rapidamente restabelecidas.

Configurar o IPv6: Implementar pilha dupla de forma limpa

Eu ativo o IPv6 em paralelo com o IPv4 para que os clientes possam utilizar Conectividade e as firewalls são duplicadas. Para cada interface, defino os prefixos atribuídos, a rota de gateway e verifico a descoberta de vizinhos e o SLAAC ou a atribuição estática. Eu verifico se os serviços devem escutar em :: e 0.0.0.0 ou se ligações separadas fazem sentido. Os testes com ping6, tracepath6 e curl através de registos AAAA mostram-me se o DNS e o encaminhamento estão corretos. Nas firewalls, espelho as regras do IPv4 para o IPv6 para que não haja lacunas e eu possa usar o mesmo Nível de segurança alcance.

Segurança: segmentação, regras, reforço

Segmento as redes de acordo com a função, como aplicações, dados, gestão e transições seguras com ACLs. Cada departamento obtém apenas o acesso de que necessita, enquanto o acesso administrativo é efectuado através de VPN ou de anfitriões bastião. As firewalls bloqueiam todo o tráfego de entrada por defeito, depois permito portas específicas para serviços. Protejo o SSH com chaves, controlos de portas, limites de taxas e bloqueio de portas opcional para invalidar os exames. Testo as alterações de forma controlada, documento-as imediatamente e reverto-as rapidamente em caso de problemas, para que o Segurança operacional permanece elevado.

Orquestrar firewalls de nuvem e de host

Combino firewalls de nuvem com regras baseadas em host. As primeiras dão-me uma camada central que restringe de forma fiável o acesso básico, enquanto as segundas protegem as cargas de trabalho de forma granular e podem ser modeladas. A consistência é importante: as portas padrão e o acesso de gerenciamento recebem regras idênticas em todas as zonas. Mantenho as políticas de saída restritivas para que apenas os objectivos definidos possam ser alcançados. Para ambientes sensíveis, também utilizo anfitriões de salto com acesso de curta duração e proteção multi-fator. Correlaciono os registos de forma centralizada para compreender rapidamente os bloqueios e reduzir os falsos alarmes.

Resolução de problemas: reconhecer rapidamente os erros típicos

Se um servidor não tiver rede após uma troca, verifico primeiro o nome da interface e ajusto o Configuração em. Se o roteamento falhar, eu reativo o encaminhamento de IP e verifico as rotas do host e o gateway padrão. Erros de digitação em endereços, máscaras de rede ou on-link muitas vezes levam à inacessibilidade; comparo a configuração e as rotas reais do kernel. No caso de problemas de bridge, verifico os MACs virtuais e as tabelas ARP para garantir que os mapeamentos estão corretos. Os registos em /var/log/syslog, journalctl e dmesg fornecem-me informações sobre drivers, erros de DHCP ou bloqueios de Pacotes.

Resolução sistemática de problemas e diagnóstico de pacotes

• Verificação de camadas: Ligação, velocidade/duplex, estado da VLAN/ponte, depois IP/rota e depois serviços.
• Comparação real/alvo: ip addr/route/rule vs. ficheiros de configuração, registar os desvios por escrito.
• Gravação de pacotes: direcionada para a interface e o anfitrião, observar a descarga, verificar o TLS-SNI/ALPN.
• Verificação cruzada: Testes de várias fontes (internas/externas) para detetar problemas de assimetria.
• Capacidade de reversão: planear um caminho de retorno definido antes de cada alteração.

Monitorização, documentação e escalonamento orientados

Monitorizo a latência, a perda de pacotes e o jitter com verificações ICMP, verificações de portas e análises de fluxo, para poder detetar anomalias atempadamente e Tendências reconhecer. Faço cópias de segurança das versões dos estados de configuração, descrevo as alterações com precisão e mantenho os manuais prontos. Para registos DNS e convenções de nomenclatura limpas, utilizo o compacto Guia DNSpara que os serviços possam ser resolvidos de forma consistente. À medida que a plataforma cresce, expando as sub-redes, adiciono mais equilibradores de carga e normalizo os grupos de segurança. Isto permite-me escalar de forma segura, minimizar as interrupções e manter padrões de segurança claros. Estruturas.

Automatização: Terraform, Ansible e implementações consistentes

Construo redes reproduzíveis: Os nomes, sub-redes, rotas, firewalls e atribuições de servidores são mapeados como código. Isto permite-me criar topologias de teste e produção idênticas, testar as alterações antecipadamente e reduzir os erros de digitação. Ao nível do anfitrião, gero ficheiros de configuração a partir de modelos e injeto parâmetros como IP, gateway, rotas e MTU por função. Utilizo o Cloud-init para definir as bases de rede e SSH diretamente durante o aprovisionamento do servidor. Quando faço alterações, primeiro valido-as em staging, depois faço-o em pequenos lotes e mantenho-me atento à telemetria.

Gestão da mudança e da capacidade

Planeio janelas de manutenção e defino níveis de recurso. Cada alteração na rede é objeto de um pequeno plano de testes com pontos de medição antes/depois da alteração. Relativamente à capacidade, analiso o débito por zona, as cargas de ligação nos gateways e o desenvolvimento de ligações/minuto. Acrescento gateways adicionais numa fase inicial ou separo as rotas de tráfego (este/oeste vs. norte/sul) antes de ocorrerem estrangulamentos. Mantenho a documentação actualizada: Os planos de IP, os esboços de encaminhamento, as políticas de firewall e as responsabilidades estão actualizados e são fáceis de encontrar pela equipa.

Comparação de fornecedores para projectos de rede intensiva

Avalio os fornecedores de acordo com a ligação, a gama de funções, a facilidade de utilização e Flexibilidade. Para projectos com elevados requisitos de rede, coloco o webhoster.de no topo devido às suas redes dedicadas e personalização versátil. A Hetzner fornece poderosos servidores dedicados e em nuvem que são muito bem adaptados a muitos cenários e têm uma pontuação elevada. A Strato cobre os casos de utilização padrão, enquanto a IONOS oferece boas opções nalguns casos, mas dá menos margem de manobra para configurações especiais. Esta categorização ajuda-me a escolher a base certa e a tomar decisões posteriores. Estrangulamentos a evitar.

Local	Fornecedor	Caraterísticas da rede	Desempenho
1	webhoster.de	Redes dedicadas, ligação rápida, elevada capacidade de personalização	Extraordinário
2	Hetzner	Poderosos servidores dedicados e em nuvem	Muito bom
3	Strato	Funções de rede standard	Bom
4	IONOS	Opções de gama alta, possibilidades limitadas de configurações personalizadas	Bom

Kubernetes e redes de contentores na prática

Para a orquestração de contêineres, eu estabeleço a base na rede. Os trabalhadores recebem interfaces na rede privada, o plano de controlo é claramente segmentado e os pods de saída pesada recebem um caminho NAT definido. Escolho um CNI que se adapte à configuração: As variantes baseadas em roteamento facilitam a solução de problemas e poupam despesas gerais de sobreposição, enquanto as sobreposições geralmente oferecem mais flexibilidade em termos de isolamento. Os balanceadores de carga desacoplam o Ingress dos backends; as verificações de integridade são idênticas às da aplicação, não apenas verificações TCP simples. Também executo pilhas duplas no cluster para que os serviços possam ser alcançados de forma limpa através de registos AAAA. Para serviços com estado, eu defino políticas de rede claras (leste/oeste) para que apenas as portas necessárias entre os pods estejam abertas. Eu sempre testo as atualizações dos componentes da CNI e do Kube em um cluster de teste, incluindo a taxa de transferência, a latência e os cenários de falha.

Desempenho em carga: otimização mensurável

Meço regularmente: latência de linha de base dentro das zonas, latência para pontos de extremidade públicos, rendimento de porta a porta e requisitos de RTO/RPO para serviços críticos. Os gargalos geralmente ocorrem em alguns pontos: Gateways NAT, firewalls stateful sobrecarregados, tabelas de rastreamento de conexão que são muito pequenas ou simplesmente pouca CPU nos roteadores. Aumento sistematicamente a capacidade, distribuo os fluxos, ativo as filas múltiplas nas placas de rede e presto atenção ao equilíbrio de pinning/IRQ quando necessário. É fundamental evitar a inspeção com estado desnecessária em backbones leste/oeste puros e, em vez disso, definir ACLs claras. Para o descarregamento de TLS, separo o tráfego de dados do tráfego de controlo para que as cargas de trabalho L7 não concorram com as ligações de gestão. Documentei tudo isto com valores iniciais e objectivos - as optimizações só são "concluídas" quando trazem benefícios mensuráveis.

Breve resumo: Como configurar eficazmente as redes Hetzner

Começo com um plano claro, defino os espaços de endereçamento, selecciono os Modo e documentar cada passo. Em seguida, configuro as redes Linux de forma consistente, ativo o reencaminhamento de IP, se necessário, e testo minuciosamente o encaminhamento e o DNS. Integro IPs de failover e MACs virtuais de forma estruturada para que as comutações funcionem sem problemas. A segurança mantém-se elevada graças à segmentação, firewalls fortes e aplicação consistente de patches, enquanto a monitorização revela irregularidades numa fase inicial. É assim que consigo hetzner A configuração da rede oferece um desempenho fiável, mantendo a plataforma flexível para o crescimento.