Bei Hostern wie Server4You und Hetzner ist unter Umständen eine Port Security auf den Switchen aktiv. Diese erlaubt meist nur eine MAC-Adresse am Switchport, die des Servers den der Hoster vergeben hat. Eine Virtualisierung im Bridge-Mode wird somit erschwert. Da die KVM Gäste eine eigene MAC-Adresse durch Proxmox VE erhalten ist ein wenig Trickserei nötig damit eure KVM Gäste mit einer öffentlichen IP-Adresse zu erreichen sind.
Ich gehe von einem bereits funktionierenden Proxmox VE Setup aus.
Punkt 1: Vorbereitungen am Hostsystem
Auf dem Hostsystem schalten wir zuerst das IPv4-Forwarding ein.
|
1 |
net.ipv4.ip_forward=1 |
Optional auch für IPv6.
|
1 |
net.ipv6.conf.all.forwarding=1 |
Einstellungen übernehmen.
|
1 |
sysctl --system |
Punkt 2: Netzwerk Bridge einrichten
Proxmox VE basiert auf Debian, somit richten wir auf dem Hostsystem in /etc/network/interfaces folgende Bridge ein.
- Als Beispiel verwende ich die IP-Adresse
10.10.30.1, diese könnt ihr frei wählen - Eine odere mehrere öffentliche IP-Adressen werden mittels
route addin das Interfacevmbr1geroutet
|
1 2 3 4 5 6 7 8 9 |
auto vmbr1 iface vmbr1 inet static address 10.10.30.1 netmask 255.255.255.0 bridge_ports none bridge_stp off bridge_fd 0 post-up route add -host 188.138.xx.201/32 dev vmbr1 [..] |
Das Interface kann nun gestartet werden.
|
1 |
host:~# ifup vmbr1 |
Wir überprüfen ob das Interface UP ist und ob die Route gesetzt wurde.
|
1 2 3 4 5 |
host:~# ip a ls vmbr1 33: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether ee:4e:01:cd:66:9e brd ff:ff:ff:ff:ff:ff inet 10.10.30.1/24 brd 10.10.30.255 scope global vmbr1 valid_lft forever preferred_lft forever |
|
1 2 3 |
host:~# ip r ls | grep vmbr1 10.10.30.0/24 dev vmbr1 proto kernel scope link src 10.10.30.1 188.138.xx.201 dev vmbr1 scope link |
Punkt 3: KVM Gast einrichten
Im Gastsystem richten wir die Netzwerkinterfaces wie folgt ein. Hier in einem Debian Beispiel.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
auto eth0 iface eth0 inet static address 10.10.30.2 netmask 255.255.255.0 network 10.10.30.0 broadcast 10.10.30.255 gateway 10.10.30.1 auto eth0:1 iface eth0:1 inet static address 188.138.xx.201 netmask 255.255.255.255 post-up ifconfig eth0 10.10.30.2 netmask 255.255.255.0 up |
Nach einem Reboot sollte nun die VM vom Hostsystem aus erreichbar sein und umgekehrt.
|
1 2 3 4 5 6 7 |
host:~# ping -c1 10.10.30.2 PING 10.10.30.2 (10.10.30.2) 56(84) bytes of data. 64 bytes from 10.10.30.2: icmp_seq=1 ttl=64 time=0.095 ms --- 10.10.30.2 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.095/0.095/0.095/0.000 ms |
|
1 2 3 4 5 6 7 |
vm:~# ping -c1 10.10.30.1 PING 10.10.30.1 (10.10.30.1) 56(84) bytes of data. 64 bytes from 10.10.30.1: icmp_seq=1 ttl=64 time=0.104 ms --- 10.10.30.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.104/0.104/0.104/0.000 ms |
Ich habe bewusst eine /24 Netzmaske gewählt damit mehrere VMs untereinander kommunizieren können, auch in andere Subnetze. Wer das nicht braucht kann die Netzmaske /32 verwenden und die SNAT Regel auslassen.
|
1 2 3 4 5 |
auto eth0:1 iface eth0:1 inet static address 188.138.93.211 netmask 255.255.255.255 post-up ifconfig eth0 10.10.30.2 netmask 255.255.255.255 up |
Damit die VM nach außen sprechen kann und die korrekte Source IP-Adresse verwendet wird benötigen wir noch eine kleine SNAT Regel.
|
1 |
iptables -t nat -A POSTROUTING -s 10.10.30.2/32 ! -d 10.0.0.0/8 -j SNAT --to 188.138.xx.201 |
0