theonlymarkus
Goto Top

Öffentliche IP Adresse dem WAN Interface einer Firewall VM zuweisen

Liebe Admins


Ich habe mir vor ein paar Monaten bei Hetzner einen Root Server mit einer inkludierten öffentlichen IP Adresse angemietet. Auf diesem Root Server virtualisiere ich derzeit mehrere VMs auf Basis libvirt. Eine davon ist eine Firewall auf Basis pfSense. Am Root Server wurde als Host Distribution Ubuntu 14.04 LTS installiert.

Mein Vorhaben:
Zukünftig sollen alle VMs über die Firewall VM an das Internet angebunden sein. Dazu muss ich dem WAN Interface der Firewall VM eine öffentliche IP Adresse zuweisen. Der Hauptgrund warum ich mich für eine neue IP entschieden habe ist zum einen ein IPsec Site2Site VPN und zum anderen muss ich sämtliche Netzwerk Regeln nur noch an der Firewall VM konfigurieren. Über die bestehende/inkludierte IP sollen nur noch Wartungsarbeiten (Updates, Start/Stopp der VMs, Konfigurationsänderungen) am Root Server durchgeführt werden.
Bei Hetzner habe ich mir bereits eine zusätzliche IP Adresse angemietet. Für die Firewall VM wurde am Root Server ein isoliertes Netzwerk angelegt und anschließend an das DMZ Interface der Firewall VM angebunden.

Mein Problem:
Ich bekomme es ums verrecken nicht hin, die neue öffentliche IP dem WAN Interface der Firewall zuzuweisen.
Ich scheitere dabei an der Konfiguration des Root Servers. Dieser hat leider nur eine physische Netzwerkkarte. Laut Hetzner Wiki gibt es zwei Möglichkeiten die neue IP zu konfigurieren - Bridged und Routed. Warum ich bei beiden Möglichkeiten die inkludierte IP als "address" konfigurieren soll verstehe ich überhaupt nicht. Logisch wäre für mich die neue IP als "address" zu konfigurieren. Weiters würde micht interessieren ob man das WAN Interface der Firewall an das neue Interface vom Root Server anschließen kann oder man ein zusätzliches in libvirt erstellen muss. Falls ersteres möglich, welche MAC Adresse wird verwendet werden?

Ich bin grundsätzlich auch für andere Lösungsansätze offen.


Grüße
TheOnlyMarkus aka Markus

Content-Key: 276295

Url: https://administrator.de/contentid/276295

Printed on: April 16, 2024 at 17:04 o'clock

Member: broecker
broecker Jul 03, 2015 at 06:39:19 (UTC)
Goto Top
ganz habe ich Deinen Beitrag noch nicht verstanden, gerade auch keine Muße dafür, aber zu Hetzner ein Detail zur Erklärung:
die zugewiesene 1. IP muß dem physischen Interface zugewiesen bleiben, da ihre MAC wiederum in deren "Backbone-Struktur" im nächsten Switch/Router fest hinterlegt ist. Das ist als Sicherheitsfeature gemeint.
So ergibt sich, daß eine Firewall sinnvoll auch auf den Host gelegt wird (trotz Hypervisor), durch Portforwarding ist der Nachteil nicht groß.
HG
Mark
Member: aqui
aqui Jul 03, 2015 at 06:49:35 (UTC)
Goto Top
Ist wirklich etwas wirr. Aber Fakt ist das das Hypervisor Interface eine IP hat und im Bridged Mode arbeiten muss bzw. zur pfSense VM Bridging machen muss.
Die pfSense VM hat dann am WAN Port eine weitere IP Adresse: Ergo, du brauchst auf alle Fälle 2 gültige IP Hostadressen. Das die pfSense und dein Hypervisor Host eine Adresse sharen ist nicht möglich.
Member: TheOnlyMarkus
TheOnlyMarkus Jul 03, 2015 at 12:10:42 (UTC)
Goto Top
Sorry für den etwas wirr verfassten Beitrag.

Danke aqui für den Tipp mit der Bridge. Ich habe auf einem Test PC die selbe Konfiguration wie am Hypervisor nachgebaut.
Bei einem Test PC habe ich jetzt das physische Interface eth0 jetzt als Bridge br0 konfiguriert und anschließend erneut eine pfSense installiert. Dem WAN Port der pfSense habe ich der Bridge br0 zugewiesen. Nach der Installation war die pfSense in der Lage von meinem DHCP Server im LAN eine IP für den WAN Port zu beziehen.
Ist diese Konfiguration so üblich oder sollte br0 an eine virtuelle Bridge des Hypervisors diese dann am WAN Port der pfSense angebunden werden?
Member: aqui
aqui Jul 03, 2015 updated at 13:42:00 (UTC)
Goto Top
Nicht das du das hier falsch verstehst !
Niemals darf ein Bridging oder Bridge Interface auf der pfSense selber eingerichtet werden, das wäre fatal.
Das Bridging bezieht sich vielmehr auf den Hostadapter des Hypervisors. DIESER muss ein Bridging machen auf den virtuellen WAN Adapter der pfsense VM.
Beim kranken Hyper-V ist das m.W. ein separater Switch der dort definiert werden muss, da man diese Option nicht auf der NIC definiert (geraten, da bekennender Hyper V Hasser)
Bei sinnvolleren Hypervisoren wie VmWare oder Virtual Box konfiguriert man das entsprechend auf der NIC.
Member: TheOnlyMarkus
TheOnlyMarkus Jul 03, 2015 updated at 18:13:30 (UTC)
Goto Top
Aqui ich glaube ich verstehe auf was du hinaus willst. Fällt die pfSense aus, kann ich den Hypervisor nicht mehr erreichen.
Ich poste nochmal ausführlich meine derzeitige Konfiguration:

Auf dem Test PC wurde ein Ubuntu Server 14.04 LTS und folgende Pakete installiert: qemu-kvm libvirt-bin virtinst bridge-utils virt-manager qemu-system hal.
Am Test PC wurde die Datei /etc/network/interfaces so abgeändert:

  1. The loopback network interface
auto lo
iface lo inet loopback

  1. The primary network interface
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.112.136
network 192.168.112.0
netmask 255.255.255.0
broadcast 192.168.112.255
gateway 192.168.112.2
dns-nameservers 192.168.112.2
bridge_ports eth0
bridge_stp off

Danach habe ich der pfSense VM folgende virtuelle Netzwerkadapter hinzugefügt (virsh dumpxml):

<interface type='bridge'>
<mac address='52:54:00:92:8d:f2'/>
<source bridge='br0'/>
<model type='e1000'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

<interface type='network'>
<mac address='52:54:00:19:59:4f'/>
<source network='DMZ'/>
<model type='e1000'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</interface>

<source bridge='br0'/> = Test PC Bridge br0
<source network='DMZ'/> = ein isolierte virtuelle Netzwerk Bridge. Wurde durch "virsh net-define dmz.xml" hinzugefügt.

Die pfSense holt sich vom DHCP Server im LAN folgende IP: 192.168.112.137 und ist auch pingbar.
Schalte ich die pfSense aus, dann ist der Test PC (192.168.112.136) noch pingbar.
Der Test PC und die pfSense kommuniziert demnach über die Bridge br0 mit dem Internet.

Kann ich die Konfiguration so lassen?
Member: broecker
broecker Jul 03, 2015 at 17:14:32 (UTC)
Goto Top
ich glaube nicht!
DHCP treibt einem hier die Haare hoch,
das Üben wird praxisgerechter, wenn die richtigen festen IPs zugewiesen werden.
en0 braucht die öffentliche erste IP,
br0 vermutlich eine IP eines kleinen lokalen Netzes (erfunden und Hetznerkompatibel: 192.168.22.1/24
viren0 - ein erster Gast 192.168.22.2 und wenn er nach draußen soll als zweite virtuelle IP auf der gleichen en0 - also
viren0:1 die zweite öffentlich zugekaufte IP.
Die echte en0 hängt dann also mit ihrer MAC und ihrer Hetzner-IP am Hetzner Router.
HG
Mark
Member: TheOnlyMarkus
TheOnlyMarkus Jul 03, 2015 at 18:59:14 (UTC)
Goto Top
DHCP verwende ich nur testweise bei mir im LAN. Die richtigen festen IPs werden am produktiv System statisch konfiguriert werden.

Also Kommando retur?
Für mich zum Verständnis, welche gravierenden Nachteile/Security bedenken hat meine derzeitige Konfiguration.

Bitte erkläre mir genauer welche Rollen die von dir genannten Interfaces spielen sollen.

en0 = eth0?
br0 = DMZ Interface der pfSense?
viren0 = virtuelles VM Interface?
viren0:1 = ?

Ich hoffe wir reden hier nicht an einander vorbei.
Ich würde am produktiven Hypervisor aka Hetzner Root Server folgende Netzwerkkonfiguration haben:

3208fbfaa6195040aa2452df1307b6b8
Member: broecker
broecker Jul 03, 2015 updated at 19:30:49 (UTC)
Goto Top
immer noch ein Satz: die zweite IP darf bei Hetzner nicht direkt an deren "Internet" (also deren Router) hängen, sondern nur gebridged über eth0, einfach weil sonst die MAC der physischen Maschine bei den Punkt-zu-Punkt-Ethernetverbindungen nicht in Erscheinung tritt.
Also nach außen nur ein Weg über die öffentliche IP, alle anderen nur innerhalb Deines Rechtecks in der Zeichnung. (also "nur ein Strich/Weg in das Rechteck")
Was ich zu erklären versuche, Deine Idee wäre nicht generell falsch, nur funktioniert sie nur, wenn der Router/ein VLAN-nutzender Switch in Deiner Hand ist, das ist aber bei Hetzner nicht der Fall.
HG
Mark