Di fronte a una domanda e a una pausa da una grande quantità di documentazione, prova a organizzare e scrivere ciò che hai imparato per ricordare meglio. E fornisci anche istruzioni su questo problema in modo da non ripetere l'intero percorso.
La documentazione sorgente è disponibile in grandi quantità su
Formulazione del problema
Il cliente vuole unire più server noleggiati in un'unica rete per evitare di pagare per diverse sottoreti aggiuntive, appendere tutta la sua famiglia dietro un router, assegnare loro indirizzi locali ed essere protetto da un firewall. In modo che tutto il traffico del servizio venga eseguito all'interno della VLAN. Inoltre, sposta le macchine virtuali da un vecchio server a uno nuovo e abbandonalo, aggiorna il vecchio hardware che stai utilizzando e allo stesso tempo passa al nuovo Proxmox.
Inizialmente il client dispone di 5 server, ciascuno con una sottorete aggiuntiva, il primo indirizzo della sottorete dedicata viene assegnato al bridge aggiuntivo su Proxmox
Allo stesso tempo, le VM funzionano su Windows e hanno l'indirizzo 85.xx177/29 configurato con un gate 85.xx176
E tutti e 5 i server con le proprie macchine virtuali sono configurati in modo simile.
È curioso che questa configurazione sia sbagliata in linea di principio nell'impostazione della rete; utilizzare l'indirizzo di rete per il primo nodo e lo stesso per il gateway. Se provi a eseguire questa configurazione su una macchina virtuale in Ubuntu, la rete non funziona.
implementazione
- Creiamo un vSwitch nell'interfaccia, gli assegniamo un VlanID e aggiungiamo questo vSwitch a tutti i server di cui abbiamo bisogno.
- Stiamo realizzando un server di prova in modo da poterlo configurare e spostare senza problemi.
Alziamo la prima macchina virtuale chr di .
Se usi lo script sopra, tieni presente che prima controlla la presenza della directory -d /root/temp e, se non è presente, viene creata la directory /home/root/temp, ma resta ancora del lavoro da svolgere uscire con la directory /root/temp. Lo script deve essere corretto per creare la directory appropriata.
- Configurazione di una rete per Proxmox.
Aggiungiamo una sottointerfaccia con un numero VLAN, indicando che gli indirizzi verranno configurati sui bridge utilizzando il manuale inet. IMPORTANTE. Non è possibile configurare gli indirizzi IP sulle interfacce che poi inserirete nel bridge; come funzionerà e se funzionerà non sarà noto a nessuno.
Successivamente, creiamo un bridge vmbr0 - e alleghiamo ad esso il primo indirizzo del server stesso, fornitoci dai provider Hetzner, indichiamo la porta del bridge - la prima interfaccia fisica senza VLAN, e specifichiamo anche con un comando aggiuntivo l'aggiunta di un percorso verso la nostra rete aggiuntiva, ordinato da Hetzner per questo server attraverso questo bridge. L'aggiunta di un percorso funzionerà quando l'interfaccia sarà attiva.
Il secondo bridge sarà la nostra interfaccia per il traffico locale, aggiungiamo un indirizzo per ottenere la connettività tra diversi server Proxmox su una rete locale senza accesso a Internet e specifichiamo la porta come sottointerfaccia eno1.4000, che è allocata per il nostro VlanID.
Durante la configurazione iniziale, ti viene consigliato di installare un pacchetto ifupdown2 aggiuntivo per Proxmox e di non dover riavviare l'intero server se ci sono modifiche nelle interfacce di rete. Tuttavia, questo è tipico solo per la configurazione iniziale e quando si utilizzano bridge e si configurano macchine virtuali, si riscontrano problemi con guasti di rete nelle macchine virtuali. Nonostante tu abbia modificato, ad esempio, l'interfaccia vmbr2 e quando applichi la configurazione, la rete si interrompe su tutte le interfacce interne e non viene ripristinata finché il server non viene completamente riavviato. ifdown&&ifup non aiuta. Se qualcuno avesse una soluzione gli sarei grato.
La primissima interfaccia configurata sul server rimane funzionante e accessibile.
-
Assegnazione di un indirizzo per CHR per non perdere indirizzi dal pool
Il pool di indirizzi che Hetzner produce sembra molto strano a un networker, qualcosa del genere:
La cosa strana è che il gate suggerisce di utilizzare il proprio indirizzo del server fisico.
L'opzione classica proposta dallo stesso Hetzner è indicata nella dichiarazione del problema ed è stata implementata autonomamente dal cliente. In questa opzione il client perde il primo indirizzo per l'indirizzo di rete, il secondo indirizzo per il bridge proxmox e sarà anche il gateway, e l'ultimo indirizzo per il broadcast. Gli indirizzi IPv4 non sono mai ridondanti. Se provi direttamente a registrare l'indirizzo IP 136.x.x.177/29 e il gateway per 0.0.0.0/0 148.x.x.165 sul CHR, puoi farlo, ma il gateway non sarà Direct Connected e quindi sarà irraggiungibile .
Possiamo uscire da questa situazione utilizzando la rete 32 per ogni indirizzo e specificando come nome della rete l'indirizzo di cui abbiamo bisogno, che può essere qualsiasi cosa. Risulta essere un analogo di una connessione punto a punto.
In questo caso, il gateway sarà ovviamente disponibile e tutto funzionerà secondo le nostre necessità.
Tieni presente che in tale configurazione non è consigliabile utilizzare la regola di masquerade SRC-NAT, poiché l'indirizzo di output sarà indefinitamente diverso, ed è più corretto specificare action: src-NAT e l'indirizzo specifico da cui partirai rilasciare il cliente.
- E infine.
Per bloccare l'accesso a Proxmox stesso da Internet, utilizza gli strumenti integrati: c'è un ottimo firewall.
Non dovreste utilizzare il firewall offerto da Hetzner per non confondervi sulla posizione delle impostazioni. Hetzner lavorerà anche su tutte le reti, comprese quelle stabilite su CHR, e per aprire e inoltrare le porte sarà necessario aprirle anche nell’interfaccia web del provider.
Fonte: habr.com