Il tuo server è stato consegnato con il primo indirizzo IPv4 configurato sull'host e nient'altro. Tutti gli altri indirizzi del tuo account sono tuoi da collocare. Questa guida illustra i tre modi per farlo su una macchina Server Room: in bridge, dove una macchina virtuale si trova sulla nostra rete con il proprio indirizzo MAC; in routing, dove l'host inoltra il traffico al suo posto; e una sottorete privata dietro il tuo indirizzo primario. Ogni configurazione qui presente è stata testata sulla nostra rete prima di essere pubblicata.
Completa prima i passaggi uno e due. Poi scegli il passaggio tre, quattro o cinque — sono tre risposte alla stessa domanda, non una sequenza.
L'email Configurazione server dedicato inviata quando la tua macchina è stata creata elenca tutti gli indirizzi a essa assegnati, prima IPv4 e poi IPv6. Lo stesso elenco si trova nel pannello di controllo nella pagina del server, sotto Accesso, rete e rDNS, dove ogni indirizzo è mostrato con il relativo record DNS inverso.
Su una build Proxmox l'email contiene una riga aggiuntiva, ed è il motivo per cui questa pagina esiste: solo il primo indirizzo è configurato sull'host. Gli altri sono tuoi da assegnare da Proxmox, alle tue macchine virtuali o all'host stesso. Il nostro installer configura deliberatamente un solo indirizzo e si ferma, perché un host che li possedesse tutti risponderebbe per ognuno di essi e non lascerebbe nulla alle tue macchine virtuali.
La netmask è sempre /24 (255.255.255.0) e il gateway è sempre il .1 della /24 in cui si trova l'indirizzo stesso. Questa seconda parte conta più di quanto sembri. Gli indirizzi ordinati insieme sono consecutivi all'interno di una /24, quindi condividono un gateway. Gli indirizzi aggiunti in seguito a un server esistente possono provenire da un intervallo diverso dei nostri, e in tal caso ognuno usa il proprio .1 — ad esempio un indirizzo in 203.0.113.0/24 usa 203.0.113.1 anche su una macchina il cui indirizzo primario è in un altro intervallo. Entrambi funzionano sulla stessa porta e sullo stesso bridge.
Il resolver configurato dal nostro installer è 209.244.0.3. Sei libero di puntare le tue macchine virtuali altrove.
Accedi via SSH come root e osserva le interfacce scritte dall'installer:
ip -br addr cat /etc/network/interfaces
Una macchina appena creata si presenta così, con il nome della tua interfaccia e il tuo indirizzo primario al posto degli esempi:
auto lo
iface lo inet loopback
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet static
address 203.0.113.10/24
gateway 203.0.113.1
bridge-ports eno1
bridge-stp off
bridge-fd 0 vmbr0 è già un bridge e l'interfaccia fisica ne è già una porta. Questo è l'intero modello in bridge, ed è per questo che il passaggio tre ti chiede di non modificare nulla sull'host.
Proxmox VE 9 è Debian 13 e utilizza ifupdown2, quindi una modifica alla configurazione non richiede un riavvio. Modifica /etc/network/interfaces e applicala con:
ifreload -a
Se invece modifichi la rete tramite l'interfaccia web di Proxmox, le modifiche vengono preparate in /etc/network/interfaces.new finché non premi Applica configurazione. In entrambi i casi, apri la console del server dal pannello di controllo prima di ricaricare. Un errore in questo file toglie la macchina dalla rete, e la console è il modo per rientrare senza aprire un ticket.
Questa è la soluzione da usare a meno che tu non abbia un motivo per non farlo. La macchina virtuale è una macchina ordinaria sullo stesso segmento dell'host, comunica direttamente con i nostri router e nulla sull'host cambia affatto.
Nell'interfaccia Proxmox, assegna alla macchina virtuale un dispositivo di rete sul bridge vmbr0 e lascia l'indirizzo MAC generato da Proxmox. Poi configura l'indirizzo all'interno della macchina virtuale esattamente come faresti su qualsiasi server. Per una macchina virtuale Debian o Ubuntu che usa ifupdown:
auto lo
iface lo inet loopback
auto ens18
iface ens18 inet static
address 203.0.113.58/24
gateway 203.0.113.1
dns-nameservers 209.244.0.3 1.1.1.1 Per una macchina virtuale Ubuntu che usa netplan, in /etc/netplan/01-netcfg.yaml:
network:
version: 2
ethernets:
ens18:
addresses: [203.0.113.58/24]
routes:
- to: default
via: 203.0.113.1
nameservers:
addresses: [209.244.0.3, 1.1.1.1] Una macchina virtuale Windows accetta gli stessi tre valori nelle proprietà IPv4 dell'adattatore. Qualsiasi sistema operativo funziona, perché dal nostro lato si tratta semplicemente di un'altra macchina sulla sottorete.
Non devi registrare l'indirizzo MAC di una macchina virtuale presso di noi, e non limitiamo quanti ne può usare la tua porta. Alcune società di hosting lo fanno, e la loro documentazione ti dice di dichiarare un MAC per ogni macchina virtuale. La nostra no: la porta dello switch a cui è collegato il tuo server non ha restrizioni sul numero di MAC e la sicurezza della porta è disattivata, quindi un MAC di una macchina virtuale viene appreso esattamente come quello dell'host. Lo abbiamo testato prima di pubblicarlo, mettendo un secondo MAC e un indirizzo libero sulla porta cliente di un server del personale e raggiungendolo da internet pubblico.
Tre cose da mantenere corrette:
• Assegna a ogni macchina virtuale un indirizzo MAC distinto. Due macchine virtuali che ne condividono uno, o una che copia quello dell'host, le rompono entrambe.
• Usa il gateway appartenente alla /24 di quell'indirizzo, dal passaggio uno.
• Configura solo un indirizzo assegnato al tuo account. Il bridge è rivolto verso una rete reale condivisa con altre macchine. Prendere un indirizzo che non è tuo porta con sé il traffico di qualcun altro.
Per lo stesso motivo, non eseguire un server DHCP, un demone di router advertisement non autorizzato o qualsiasi altra cosa che risponda per il segmento su vmbr0. Se vuoi offrire DHCP alle tue macchine virtuali, usa il modello a sottorete privata del passaggio cinque, dove il bridge non ha porte fisiche e non può raggiungere nessun altro.
Usa questa soluzione quando vuoi che ogni pacchetto da e verso una macchina virtuale passi attraverso l'host, in modo che il firewall dell'host lo veda, o quando preferisci che le tue macchine virtuali non appaiano affatto sul nostro livello 2. L'indirizzo è comunque pubblico e proviene dal tuo account; cambia solo il percorso.
L'indirizzo pubblico si sposta dal bridge all'interfaccia fisica, l'host inoltra e risponde all'ARP per conto delle macchine virtuali per cui fa routing. Sull'host:
auto lo
iface lo inet loopback
auto eno1
iface eno1 inet static
address 203.0.113.10/24
gateway 203.0.113.1
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up echo 1 > /proc/sys/net/ipv4/conf/eno1/proxy_arp
auto vmbr0
iface vmbr0 inet manual
bridge-ports none
bridge-stp off
bridge-fd 0
up ip route add 203.0.113.58/32 dev vmbr0
down ip route del 203.0.113.58/32 dev vmbr0 Aggiungi una coppia up e down per ogni indirizzo instradato. All'interno della macchina virtuale, l'indirizzo è un /32 e l'host viene raggiunto tramite una route on-link esplicita prima della route predefinita:
auto lo
iface lo inet loopback
auto ens18
iface ens18 inet static
address 203.0.113.58/32
post-up ip route add 203.0.113.10 dev ens18
post-up ip route add default via 203.0.113.10
dns-nameservers 209.244.0.3 1.1.1.1 Due note sulla stanza dell'host. La riga proxy_arp è ciò che fa funzionare il tutto qui: i nostri router chiedono sul segmento l'indirizzo della macchina virtuale e l'host risponde al suo posto. Senza quella riga la macchina virtuale è silenziosa dall'esterno. E le due righe post-up echo sono la forma documentata di Proxmox; se preferisci impostarle una volta per tutte, metti net.ipv4.ip_forward=1 e net.ipv4.conf.eno1.proxy_arp=1 in un file sotto /etc/sysctl.d/.
Il routing ti costa un po' di configurazione in ogni macchina virtuale e ti dà un host che può filtrare, contare e registrare tutto. Il bridge non costa nulla e non ti dà né l'uno né l'altro. Questo è l'intero compromesso.
Le macchine virtuali che devono solo uscire — agenti di build, worker, un database che nulla all'esterno dovrebbe toccare — non hanno affatto bisogno di un indirizzo pubblico. Mettile su un bridge senza porte fisiche e lascia che l'host traduca il loro traffico verso il proprio indirizzo in uscita. Questo non costa indirizzi ed è il modo più economico per gestire molte macchine.
Aggiungi un secondo bridge sull'host, lasciando vmbr0 com'è:
auto vmbr1
iface vmbr1 inet static
address 10.10.10.1/24
bridge-ports none
bridge-stp off
bridge-fd 0
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE Le macchine virtuali vanno su vmbr1 con un indirizzo in quell'intervallo, 10.10.10.1 come gateway e il resolver che preferisci. Raggiungono internet come il tuo server; nulla dall'esterno le raggiunge a meno che tu non lo consenta. Per pubblicare un servizio, aggiungi una regola di inoltro accanto alla regola di masquerade, scegliendo una porta che l'host non sta usando:
post-up iptables -t nat -A PREROUTING -i eno1 -p tcp --dport 8443 -j DNAT --to 10.10.10.2:443 post-down iptables -t nat -D PREROUTING -i eno1 -p tcp --dport 8443 -j DNAT --to 10.10.10.2:443
Poiché questo bridge non ha porte fisiche, un server DHCP su di esso è perfettamente sicuro ed è un modo ragionevole per assegnare indirizzi alle tue macchine virtuali.
La tua allocazione IPv6 è un insieme di indirizzi individuali, non un prefisso delegato che puoi suddividere. Sono elencati nella stessa email di configurazione, sotto quelli IPv4, e vengono collocati uno alla volta esattamente come gli indirizzi IPv4: uno sull'host se vuoi che l'host sia raggiungibile, il resto sulle macchine virtuali. L'installer non ne configura nessuno.
Configura ciascuno con una lunghezza di prefisso /64, e il gateway è il prefisso seguito da ::1 — quindi un indirizzo all'interno di 2001:db8:1234::/64 usa 2001:db8:1234::1. Sull'host, aggiungi una stanza IPv6 accanto al bridge esistente:
iface vmbr0 inet6 static
address 2001:db8:1234::2/64
gateway 2001:db8:1234::1 E in una macchina virtuale in bridge:
iface ens18 inet6 static
address 2001:db8:1234::5/64
gateway 2001:db8:1234::1 Applica con ifreload -a come prima. Poiché gli indirizzi sono individuali piuttosto che un prefisso tuo, non eseguire router advertisement né distribuire indirizzi che non ti sono stati assegnati. Se ti servono più di quelli che hai, chiediceli.
Il DNS inverso è tuo da modificare, su ogni indirizzo, senza aprire un ticket. Accedi, apri la pagina del server e trova il pannello Accesso, rete e rDNS. Ogni indirizzo dell'account è elencato lì con il record corrente e un pulsante Modifica rDNS. Sia IPv4 che IPv6 funzionano.
Il modulo accetta un hostname: solo lettere, cifre, trattini e punti, ogni etichetta tra 1 e 63 caratteri, almeno due etichette, e aggiunge il punto finale per te. Le modifiche impiegano alcuni minuti per apparire.
Se la macchina invia posta, imposta il record inverso sull'indirizzo da cui la posta effettivamente parte — che, nel modello a sottorete privata sopra, è l'indirizzo dell'host piuttosto che quello della macchina virtuale — e crea il record diretto corrispondente presso il tuo provider DNS. I server di posta riceventi verificano che i due coincidano.
Le domande che questa configurazione genera realmente.