Quando ti trovi di fronte a domande e a una grande quantità di documentazione, cerca di sistematizzare e annotare ciò che hai appreso per ricordarlo meglio. Inoltre, crea un'istruzione su questo argomento, in modo da non dover ripetere tutto il percorso.
La documentazione originale è disponibile in grande quantità su
Definizione del compito
Il cliente desidera unire diversi server affittati in una rete unica, per eliminare la necessità di pagare per più sotto-reti, collegare tutto al router, assegnare indirizzi locali interni e proteggere il tutto con un firewall. In modo che tutto il traffico di servizio si muova all'interno della VLAN. Inoltre, trasferire le macchine virtuali da un vecchio server a uno nuovo, dismettere il primo, aggiornare l'hardware vecchio utilizzato e nel contempo passare a un nuovo Proxmox.
Inizialmente il cliente ha 5 server, ognuno con una rete aggiuntiva, il primo indirizzo della sottorete assegnato a un bridge aggiuntivo su Proxmox.
Le VM funzionano su Windows e hanno configurato l'indirizzo 85.x.x.177/29 con gateway 85.x.x.176.
E in modo simile sono configurati tutti e 5 i server con le loro macchine virtuali.
È divertente notare che questa configurazione è errata nella gestione della rete in generale, usare l'indirizzo di rete per il primo nodo e anche come gateway. Se provi a impostare questa configurazione su una macchina virtuale in Ubuntu, la rete non funzionerà.
Implementazione
- Creiamo un vSwitch nell'interfaccia, assegniamo a esso un VlanID e aggiungiamo questo vSwitch a tutti i server necessari.
- Creiamo un server di prova in modo da poter configurare e trasferire senza problemi.
Avviamo la prima macchina virtuale chr secondo .
Se utilizzi lo script fornito, fai attenzione che all'inizio verifica la presenza della directory -d /root/temp, e se non esiste, crea la directory /home/root/temp, tuttavia il lavoro successivo prosegue comunque con la directory /root/temp. È necessario correggere lo script per la creazione della directory corretta.
- Configuriamo la rete per Proxmox.
Aggiungiamo un'interfaccia secondaria con il numero VLAN, specificando che la configurazione degli indirizzi avverrà sui bridge utilizzando inet manual. È IMPORTANTE. Non è possibile configurare indirizzi IP sulle interfacce che poi collegherai al bridge; come funzionerà e se funzionerà è sconosciuto.
Successivamente, creiamo un bridge vmbr0 e associamo il primo indirizzo del server fornito dal provider Hetzner. Indichiamo la porta del bridge come il primo'interfaccia fisica senza VLAN e aggiungiamo con un comando aggiuntivo la route per la nostra rete supplementare, ordinata presso Hetzner per questo server attraverso questo bridge. L'aggiunta della route verrà attivata quando l'interfaccia sarà attivata.
Il secondo bridge sarà l'interfaccia per il traffico locale; aggiungiamo un indirizzo per garantire la connettività tra i diversi server Proxmox sulla rete locale senza uscire su Internet e indichiamo come porta il subinterfaccia eno1.4000, allocato per il nostro VlanID.
Durante la configurazione iniziale, ci sono suggerimenti per installare il pacchetto ifupdown2 per Proxmox e per non dover riavviare completamente il server quando si modificano le interfacce di rete. Tuttavia, questo è caratteristico solo della configurazione iniziale, e quando si utilizzano i bridge e si configurano già le macchine virtuali, si possono riscontrare problemi di disconnessione della rete nelle VMs. Ad esempio, se hai modificato l'interfaccia vmbr2, applicando la configurazione la rete si stacca su tutte le interfacce interne e non si rialza fino al completo riavvio del server. ifdown && ifup non aiutano. Se qualcuno ha una soluzione, sarei grato.
La prima interfaccia configurata sul server rimane operativa e accessibile.
Assegnazione di un indirizzo per CHR per non perdere indirizzi dal pool
Il pool di indirizzi fornito da Hetzner appare piuttosto strano per un tecnico di rete, circa così:
La stranezza è che viene suggerito di utilizzare l'indirizzo fisico del server come gateway.
La soluzione classica, proposta da Hetzner, è specificata nel capitolo e implementata autonomamente dal cliente. In questo scenario, il cliente perde il primo indirizzo di rete, il secondo indirizzo sul bridge proxmox, che sarà anche il gateway, e l'ultimo indirizzo per il broadcast. Gli indirizzi IPv4 non sono mai superflui. Se provi direttamente a configurare sull'CHR l'indirizzo IP 136.x.x.177/29 e il gateway per 0.0.0.0/0 148.x.x.165, puoi farlo, ma il gateway non sarà Direct Connected e quindi sarà irraggiungibile.
Si può risolvere la situazione utilizzando una subnet di classe C per ogni indirizzo, indicandovi come nome della rete l'indirizzo che ci serve, che può essere qualsiasi. Così otteniamo un collegamento simile a un punto-punto.
In questo caso, il gateway sarà naturalmente accessibile e tutto funzionerà come desiderato.
Si tenga presente che in questa configurazione non è consigliabile utilizzare la regola SRC-NAT masquerade, poiché l'indirizzo di uscita sarà indefinito; sarà più corretto specificare action: src-NAT e un indirizzo specifico da cui si lancerà il cliente.
- E infine.
Per bloccare l'accesso a Proxmox stesso da Internet, utilizza gli strumenti integrati: c'è un eccellente firewall.
Non è consigliabile utilizzare il firewall proposto da hetzner, per non confondersi con la posizione delle impostazioni. Inoltre, hetzner agirà su tutte le reti, comprese quelle registrate su CHR, e per aprire e inoltrare le porte sarà necessario farlo anche nell'interfaccia web del provider.
Fonte: habr.com
