Affrontando il problema e interrompendo 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 ripercorrere 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 evitare di dover pagare per diverse sottoreti aggiuntive, collegare tutto il proprio sistema a un router, assegnare indirizzi locali interni e proteggersi con un firewall. Così tutto il traffico di servizio potrà muoversi all'interno del VLAN. Inoltre, vuole trasferire le macchine virtuali da un vecchio server a uno nuovo e rinunciare a quello vecchio, aggiornare l'hardware usato e, nel contempo, passare a un nuovo Proxmox.
Inizialmente, il cliente ha 5 server, ciascuno con una sottorete aggiuntiva, il primo indirizzo della sottorete assegnato a un bridge aggiuntivo su Proxmox.
Le VM funzionano su Windows e hanno impostato l'indirizzo 85.x.x.177/29 con gateway 85.x.x.176.
E in modo simile, tutti e 5 i server sono configurati con le loro macchine virtuali.
È curioso notare che questa configurazione è erronea nella configurazione della rete in generale, utilizzare l'indirizzo di rete per il primo nodo e lo stesso per il gateway. Se si prova a impostare una configurazione simile su una macchina virtuale in Ubuntu, la rete non funziona.
Implementazione
- Creiamo un vSwitch nell'interfaccia, assegniamo un VlanID e aggiungiamo questo vSwitch a tutti i server di cui abbiamo bisogno.
- Creiamo un server di test, in modo da poter configurare e trasferirci senza problemi.
Alziamo la prima macchina virtuale chr secondo .
Se utilizzi lo script fornito, fai attenzione che all'inizio viene verificata l'esistenza della cartella -d /root/temp, e se non esiste, viene creata la cartella /home/root/temp; tuttavia, il lavoro successivo continua a essere svolto comunque nella cartella /root/temp. È necessario correggere lo script per creare la cartella corrispondente.
- Configuriamo la rete per Proxmox.
Aggiungiamo un subinterfaccia con il numero VLAN, indicando che la configurazione degli indirizzi avverrà sui bridge utilizzando inet manual. IMPORTANTE. Non è possibile configurare gli indirizzi IP sulle interfacce che poi verranno incluse nel bridge, poiché non è chiaro come funzionerà e se funzionerà.
Successivamente creiamo il bridge vmbr0 e associamo il primo indirizzo del server fornito dal provider Hetzner, indicando la porta del bridge – il primo'interfaccia fisica senza VLAN, e aggiungiamo un comando aggiuntivo per la configurazione della rotta sulla nostra rete secondaria, richiesta a Hetzner per questo server tramite questo bridge. L'aggiunta della rotta funzionerà quando l'interfaccia viene attivata.
Il secondo bridge sarà l'interfaccia per il traffico locale, a cui aggiungiamo un indirizzo per garantire la connettività tra i diversi server Proxmox nella rete locale senza uscire su Internet, e indichiamo come porta il subinterfaccia eno1.4000, riservato per il nostro VlanID.
Durante la configurazione iniziale vengono proposti consigli per installare il pacchetto ifupdown2 per evitare il riavvio completo del server in caso di modifiche nelle interfacce di rete. Tuttavia, questo è caratteristico solo per la configurazione iniziale, e quando si utilizzano i bridge e si configurano già le macchine virtuali ci si trova di fronte a problemi di disconnessione della rete nelle VM. Anche se avete modificato, ad esempio, l'interfaccia vmbr2, applicando la configurazione la rete si disconnette su tutte le interfacce interne e non si attiva fino al completo riavvio del server. ifdown&&&ifup non funzionano. Se qualcuno ha una soluzione, gli sarei grato.
Il primo'interfaccia configurato sul server rimane attivo 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, più o meno così:
La stranezza è che viene suggerito di utilizzare come gateway l'indirizzo fisico del server.
La soluzione classica proposta dallo stesso Hetzner è stata indicata nell'incarico ed è stata attuata dal cliente autonomamente. In questa soluzione, il cliente perde il primo indirizzo per l'indirizzo di rete, il secondo indirizzo sul bridge proxmox che fungerà da gateway, e l'ultimo indirizzo per il broadcast. Gli indirizzi IPv4 non sono mai troppi. Se provate a impostare direttamente su CHR l'indirizzo IP 136.x.x.177/29 e il gateway per 0.0.0.0/0 148.x.x.165, lo potrete fare, ma il gateway non sarà Direct Connected e quindi risulterà irraggiungibile.
È possibile risolvere il problema utilizzando una rete 32 per ogni indirizzo e specificando il nome della rete come l'indirizzo necessario, che può essere qualsiasi. Si ottiene un'analogia con una connessione point-to-point.
In questo caso, il gateway sarà ovviamente disponibile e tutto funzionerà come desideriamo.
Considera che in una configurazione simile non è consigliabile utilizzare la regola SRC-NAT masquerade, poiché l'indirizzo di uscita sarà indefinitamente variabile; è meglio specificare action: src-NAT e l'indirizzo specifico da cui rilascerai il client.
- E infine.
Per bloccare l'accesso a Proxmox da internet, utilizza gli strumenti integrati: c'è un ottimo firewall.
Non è consigliabile utilizzare il firewall offerto da hetzner, per non confondersi con la posizione delle impostazioni. Inoltre, hetzner agirà su tutte le reti, comprese quelle impostate su CHR, e per aprire e inoltrare le porte sarà necessario farlo anche nell'interfaccia web del provider.
Fonte: habr.com
