centos:kvm:network1

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
centos:kvm:network1 [08.08.2011 20:21. ] – [Konfigurationen] djangocentos:kvm:network1 [20.05.2021 12:41. ] (aktuell) – Externe Bearbeitung 127.0.0.1
Zeile 1: Zeile 1:
 +====== virtuelle Netzwerke mit QEMU/KVM unter CentOS 6 ======
 +Nach der [[centos:install6|Grundinstallation]] unseres CentOS 6 Wirtsystemes und anschließender Installation der [[centos:kvm:wirt|Virtualisierungsumgebung]] stellt uns das System einen virtuelln Switch zur Verfügung. 
 +===== vHost mit NAT =====
 +Die Einfachste Variante für die Vernetzung und Anbindung der virtuellen Gastsysteme ist die Nutzung von NAT((**N**etwork **A**dress **T**ranslation)) mit Hilfe von **libvirt**.
 +==== Netzwerkbeispiel / -übersicht ====
 +Diese einfache Variante der Vernetzung, die uns die Basisinstallation von Haus aus mitbringt, zeigt beispielshaft die nachfolgende Graphik.
 +
 +<uml>
 +
 +state Switch {
 +  Switch : Physikalischer Netzwerk-Switch
 +  Switch : Netz 192.168.100.0/24
 +}
 +
 +state Wirt_System {
 +  
 +  state vSwitch {
 +    vSwitch : virbr0
 +    vSwitch : =============================
 +    vSwitch : Link encap:Ethernet
 +    vSwitch : Hardware Adresse B1:4C:49:FC:DF:71
 +    vSwitch : inet Adresse:192.168.122.1
 +    vSwitch : Bcast:192.168.122.255            
 +    vSwitch : Maske:255.255.255.0
 +  }
 +
 +  vSwitch -down-> Switch
 +         
 +}
 +
 +</uml>
 +==== Konfigurationen ====
 +Auf unserem Wirt finden also breits unser //default virtual network//, welches wir bei der Standardinstallation von [[http://libvirt.org/|libvirt]], vor.
 +
 +Ein Blick "unter die Haube" zeigt uns auch das entsprechende Netzwerk an.
 +
 +   # ip addr
 +<code>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
 +    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 +    inet 127.0.0.1/8 scope host lo
 +    inet6 ::1/128 scope host 
 +       valid_lft forever preferred_lft forever
 +2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100
 +    link/ether 00:25:90:13:ba:a0 brd ff:ff:ff:ff:ff:ff
 +    inet 192.168.101.233/24 brd 192.168.10.255 scope global eth0
 +    inet6 fe80::225:90ff:fe13:baa0/64 scope link 
 +       valid_lft forever preferred_lft forever
 +3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
 +    link/ether 00:25:90:13:ba:a1 brd ff:ff:ff:ff:ff:ff
 +4: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
 +    link/ether fe:54:00:0b:4a:75 brd ff:ff:ff:ff:ff:ff
 +    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
 +</code>
 +Neben dem loopbackdevice und den beiden physikalischen Netzwerkschnittstellen unseres Wirtsystems haben wir also bereits das Netzwerkgerät **virbr0** in unserem System.
 +
 +Mit **virsh** können wir auch überprüfen, ob das NAT-Defaultnetzwerk aktiv ist.
 +   # virsh net-list --all
 +
 +   Name                 Status     Automatischer Start
 +   -----------------------------------------
 +   default              Aktiv      yes       
 +
 +Sobald unser //default network// läuft, sehen wir unsere Netzwerk-Bridge, bei dem natürlich ohne ein Gastsystem weder eine physikalische Netzwerkschnittstelle verbunden, noch ein Gastsystem mit einer Virtuellen Schniottstelle angebunden ist (wie auch, denn wir haben noch keinen Gast installiert). Über dieses Netzwerk-Device können dank NAT und IP-Forwardingwir Verbindungen der vHOSTs zur Außenwelt aufbauen.
 +
 +   # brctl show
 +
 +   bridge name     bridge id               STP enabled     interfaces
 +   virbr0          8000.fe54000b4a75       yes
 +===== vHost mit bridged NIC =====
 +==== Netzwerkbeispiel / -übersicht ====
 +<uml>
 +
 +state Switch {
 +  Switch : Physikalischer Netzwerk-Switch
 +  Switch : Netz 192.168.100.0/24
 +}
 +
 +state CentOS_6_Wirt_System {
 +  
 +  state vSwitch {
 +    vSwitch : virtuelle Netzwerkswitch
 +    vSwitch : mit NAT (virbr0)
 +    vSwitch : -------------------------------------------
 +    vSwitch : Link encap:Ethernet
 +    vSwitch : Hardware Adresse FE:54:00:66:BF:0C
 +    vSwitch : inet Adresse:192.168.122.1
 +    vSwitch : Bcast:192.168.122.255            
 +    vSwitch : Maske:255.255.255.0
 +    vSwitch : DHCP-Range: 192.168.122.100-254
 +  }
 +  
 +  state vml000010 {
 +    vml000010 : vml000010.nausch.org
 +    vml000010 : -------------------------------------------
 +    vml000010 : CPU: 1
 +    vml000010 : RAM: 1024/512 MB
 +    vml000010 : HD: 10240 MB 
 +    vml000010 : Imageformat qcow2
 +    vml000010 : -------------------------------------------
 +    vml000010 : Link encap:Ethernet
 +    vml000010 : Hardware Adresse 52:54:00:c0:15:c4
 +    vml000010 : inet Adresse:192.168.100.100
 +    vml000010 : Uplink direkt an Switch via br0
 + 
 +  }
 +
 +  vSwitch -down-> Switch
 +  vml000010 -down-> Switch
 +         
 +}
 +
 +</uml>
 +==== Konfigurationen ====
 +Auf unserem [[centos:kvm:hardware#hardware_distributor|Wirt-System]] haben wir in Summe drei Netzwerkinterfaces:
 +  - **eth0** : Unser Interface für die NAT-Anbindung von virtuellen Maschinen
 +  - **eth1** : Die Netzwerkschnittstelle die wir für das gebridgde Netzwerk verwenden
 +  - **IPMI** : Netzwerk-Port füf das Managemnt via IPMI (Webbrowser und/oder SSH)
 +=== eth1 ===
 +Die Konfiguration des Bridging-Interfaces nehmen wir direkt an der Konfikuartionsdatei im Verzeichnis //**/etc/sysconfig/network-scripts/**// vor, da wir uns entschlossen haben auf den [[centos:kvm:wirt#loeschen_von_nicht_benoetigeten_paketen_-_und_systemdiensten|NetzwerkManager]] zu verzichten. Diese hat ja auch auf einem (Virtualisierungs-)Server wenig zu suchen.
 +   # vim /etc/sysconfig/network-scripts/ifcfg-eth1
 +<code># Django: 2011-08-04 Konfiguration für Bridging-Interface
 +DEVICE="eth1"
 +HWADDR=00:25:90:13:BA:A1
 +ONBOOT="yes"
 +BRIDGE=br0
 +MTU=9000
 +</code>
 +=== br0 ===
 +Für die Verknüpfung der physikalischen Netzwerkschnittstelle **eth1** des Wirt-Systemes mit einer virtuellen Netzwerkschnittstelle eines Gastsystems/vHOSTs definieren wir uns nun ein neues Netzwerkdevice **//br0//**.
 +   # vim /etc/sysconfig/network-scripts/ifcfg-br0
 +<code># Django: 2011-08-04 Konfiguration des Bridging-Interfaces von eth1 zu einm vHOST via br0
 +DEVICE=br0
 +TYPE=Bridge
 +ONBOOT=yes
 +DELAY=0
 +</code>
 +=== Aktivierung ===
 +Nach Definition der beiden Netzwerkschnittstellen aktivieren wir das geänderte bzw. des neu erstellte Netzwerkgerät, indem wir den Dienst //network// durchstarten.
 +   # service network restart
 +Damit nun auch noch die Virtualisierungs-API //**libvirt**// Kenntnis von unserem geänderten Netzwerk hat, bedarf es auch hier eines Neustarts des betreffenden Dienstes.
 +   # service libvirtd restart
 +Neben dem bereits vorhandenem Netzwerkgerät **virbr0** aus unserer Standardkonfigurationsumgebung [[centos:kvm:network1#vhost_mit_nat|vHOST mit NAT]] haben wir nun weitere Interfaces, die wir wie gewohnt abfragen können.
 +   # ip addr
 +<code>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
 +    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 +    inet 127.0.0.1/8 scope host lo
 +    inet6 ::1/128 scope host 
 +       valid_lft forever preferred_lft forever
 +2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100
 +    link/ether 00:25:90:13:ba:a0 brd ff:ff:ff:ff:ff:ff
 +    inet 192.168.10.13/24 brd 192.168.10.255 scope global eth0
 +    inet6 fe80::225:90ff:fe13:baa0/64 scope link 
 +       valid_lft forever preferred_lft forever
 +3: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 100
 +    link/ether 00:25:90:13:ba:a1 brd ff:ff:ff:ff:ff:ff
 +    inet6 fe80::225:90ff:fe13:baa1/64 scope link 
 +       valid_lft forever preferred_lft forever
 +4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN 
 +    link/ether 00:25:90:13:ba:a1 brd ff:ff:ff:ff:ff:ff
 +    inet 192.168.10.212/24 brd 192.168.10.255 scope global br0
 +    inet6 fe80::225:90ff:fe13:baa1/64 scope link 
 +       valid_lft forever preferred_lft forever
 +5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
 +    link/ether ca:d2:dc:46:a5:fe brd ff:ff:ff:ff:ff:ff
 +    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
 +</code>
 +Über das Device **br0** haben nun die vHOSTS einen direkten Zugriff auf die Netzwerk-Schnittstelle **eth1** auf unserem Server. Diese Schnittstelle werden wir dann in einer späteren Konfigurationsschritt als Uplink zu unserem ISP benutzen.
 +Unsere nunmehr beiden Bridges könen wir auch mit Hilfe der Ethernet Bridge Ddministration Tools **brctl** aus dem RPM-Paket **bridge-utils** abfragen.
 +   # brctl show
 +<code>bridge name     bridge id               STP enabled     interfaces
 +br0             8000.00259013baa1       no              eth1
 +                                                        vnet0
 +virbr0          8000.000000000000       yes
 +</code>
 +
 +===== vHosts mit bridged NIC und interner Bridge =====
 +Als weitere Steigerung zum vorgenannten Konfigurationsbeispiel, wollen wir nun einen vHOST als Gateway/Paketfilter benutzen und für einige virtuellen Gastsysteme einen virtuellen Switch einrichten. Die vHOSTS können dann untereinander über diesen Switch Daten austauschen und kommunizieren. Den Weg nach Außen müssen dies jedoch immer über einen dedizierten vHOST nehmen, der über das direkt gebridgete Netzwerkinterface **br0** die Verbindung zur realen physischen Netzwerkinfrastruktur aufbaut. Das nachfolgende Schaubild zeigt exemplarische den Netzwerkaufbau an Hand von zwei vHOSTs.
 +==== Netzwerkbeispiel / -übersicht ====
 +<uml>
 +
 +state Switch {
 +  Switch : Physikalischer Netzwerk-Switch
 +  Switch : Netz 192.168.100.0/24
 +}
 +
 +state CentOS_6_Wirt_System {
 +  
 +  state vSwitch {
 +    vSwitch : virtueller Netzwerkswitch
 +    vSwitch : mit NAT (virbr0)
 +    vSwitch : -------------------------------------------
 +    vSwitch : Link encap:Ethernet
 +    vSwitch : Hardware Adresse FE:54:00:66:BF:0C
 +    vSwitch : inet Adresse:192.168.122.1
 +    vSwitch : Bcast:192.168.122.255            
 +    vSwitch : Maske:255.255.255.0
 +    vSwitch : DHCP-Range: 192.168.122.100-254
 +  }
 +
 +  state brdmz {
 +    brdmz : virtueller Netzwerkswitch
 +    brdmz : nur innerhalb der DMZ (brdmz)
 +    brdmz : -------------------------------------------
 +    brdmz : Link encap:Ethernet
 +    brdmz : Netz:10.0.0.0/24
 +    brdmz : statische IP-Adressvergabe            
 +  }
 +  
 +  state vml000010 {
 +    vml000010 : vml000010.nausch.org
 +    vml000010 : -------------------------------------------
 +    vml000010 : CPU: 1
 +    vml000010 : RAM: 1024/512 MB
 +    vml000010 : HD: 10240 MB 
 +    vml000010 : Imageformat qcow2
 +    vml000010 : -------------------------------------------
 +    vml000010 : Link encap:Ethernet
 +    vml000010 : Hardware Adresse 52:54:00:c0:15:c4
 +    vml000010 : inet Adresse:192.168.100.100
 +    vml000010 : Uplink direkt an Switch via br0
 +    vml000010 : -------------------------------------------
 +    vml000010 : Link encap:Ethernet
 +    vml000010 : Hardware Adresse 52:54:00:c0:15:c4
 +    vml000010 : inet Adresse:10.0.0.10
 +    vml000010 : Uplink an interne DMZ-Bridge (brdmz)     
 +  }
 +  
 +   state vml000020 {
 +    vml000020 : vml000020.nausch.org
 +    vml000020 : -------------------------------------------
 +    vml000020 : CPU: 1
 +    vml000020 : RAM: 1024/512 MB
 +    vml000020 : HD: 10240 MB 
 +    vml000020 : Imageformat qcow2
 +    vml000020 : -------------------------------------------
 +    vml000020 : Link encap:Ethernet
 +    vml000020 : Hardware Adresse 52:54:00:c0:15:c4
 +    vml000020 : inet Adresse:10.0.0.20
 +    vml000020 : default Gateway: 10.0.0.10
 +    vml000020 : Uplink nur an interne DMZ-Bridge (brdmz)
 +  
 +  } 
 +
 +  brdmz -down-> vml000010
 +  brdmz -right-> vml000020
 +  vSwitch -down-> Switch
 +  vml000010 -down-> Switch
 +         
 +}
 +
 +</uml>
 +==== Konfigurationen am Wirtsystem ====
 +=== brdmz ===
 +Neben dem Interface **br0** aus dem vorgenannten [[centos:kvm:network1#konfigurationen1|Beispiel]] legen wir uns auf unserem Wirtsystem eine weitere Netzwerkschnittstelle an, die den internen Switch mit dem Namen **brdmz**((**br** = Bidge/switch - **dmz** =  Demilitarized Zone)) abbilden soll. 
 +   # vim /etc/sysconfig/network-scripts/ifcfg-brdmz
 +<code># Django: 2011-08-04 Konfiguration des Bridging-Interfaces
 +DEVICE=brdmz
 +TYPE=Bridge
 +ONBOOT=yes
 +DELAY=0
 +</code>
 +=== Aktivierung ===
 +Für die Aktivierung des neuen Netzwerkinterfaces starten wir nun den Dienst **network** und auch den Dienst **libvirt** einmal durch.
 +   # service network restart && service libvirtd restart
 +Für die Weiterleitung der IP-Pakete durch die Bridge erweiteren wir noch unseren Paketfilterregelsatz.
 +   # iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
 +Anschließend speichern wir die gänderten //iptables//-Regeln ab, damit sie bbei einem späteren Neustart wieder zur Verfügung stehen.
 +   # service iptables save
 +   iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]
 +Neben dem bereits vorhandenem Netzwerkgerät **virbr0** aus unserer Standardkonfigurationsumgebung [[centos:kvm:network1#vhost_mit_nat|vHOST mit NAT]] haben wir nun weitere Interfaces, die wir wie gewont abfragen können.
 +<code># ip addr
 +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
 +    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 +    inet 127.0.0.1/8 scope host lo
 +    inet6 ::1/128 scope host 
 +       valid_lft forever preferred_lft forever
 +2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100
 +    link/ether 00:25:90:13:ba:a0 brd ff:ff:ff:ff:ff:ff
 +    inet 192.168.10.13/24 brd 192.168.10.255 scope global eth0
 +    inet6 fe80::225:90ff:fe13:baa0/64 scope link 
 +       valid_lft forever preferred_lft forever
 +3: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 100
 +    link/ether 00:25:90:13:ba:a1 brd ff:ff:ff:ff:ff:ff
 +    inet6 fe80::225:90ff:fe13:baa1/64 scope link 
 +       valid_lft forever preferred_lft forever
 +4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN 
 +    link/ether 00:25:90:13:ba:a1 brd ff:ff:ff:ff:ff:ff
 +    inet 192.168.10.212/24 brd 192.168.10.255 scope global br0
 +    inet6 fe80::225:90ff:fe13:baa1/64 scope link 
 +       valid_lft forever preferred_lft forever
 +5: brdmz: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
 +    link/ether fe:54:00:0a:f0:a7 brd ff:ff:ff:ff:ff:ff
 +    inet6 fe80::fc54:ff:fe0a:f0a7/64 scope link 
 +       valid_lft forever preferred_lft forever
 +6: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
 +    link/ether ca:d2:dc:46:a5:fe brd ff:ff:ff:ff:ff:ff
 +    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
 +</code>
 +Über das Device **br0** haben nun die vHOSTS einen direkten Zugriff auf die Netzwerk-Schnittstelle **eth1** auf unserem Server. Diese Schnittstelle werden wir dann in einer späteren Konfigurationsschritt als Uplink zu unserem ISP benutzen. Das Device **brdmz** nutzen wir nun ausschließlich für die Vernetzung der betreffenden DMZ-vHOSTS in unserer Virtualiiserungsumgebung. 
 +Die drei Bridges könen wir auch mit Hilfe der Ethernet Bridge Ddministration Tools **brctl** aus dem RPM-Paket **bridge-utils** abfragen.
 +   # brctl show
 +<code>bridge name     bridge id               STP enabled     interfaces
 +br0             8000.00259013baa1       no              eth1
 +                                                        vnet0
 +brdmz           8000.fe54000af0a7       no              vnet1
 +                                                        vnet2
 +virbr0          8000.000000000000       yes
 +</code>
 +==== Konfigurationen auf dem Gastsystem ====
 +=== Erstellen einer zweiten Netzwerkkarte ===
 +Unser vHOST der die Trennung der DMZ-Umgebung mit der Außenwelt herstellt, definieren wir uns bei der Installation einfach eine weitere Netzwerkschnittstelle. Beim letzten Konfigurationsfenster beim Anlegen eines neuen vHOSTs wählen wir nun unter dem Punkt **Erweiterete Optionen** unser Bridge **br0** an, da der Host eine direkte Verbindung zur eth1 des Wirt-systemes bekommen soll.
 +
 +{{ :centos:kvm:virt-manager_024.png?375 |Photo: Neue VM anlegen}}
 +
 +Weiterhin setzen wir noch das Häkchen bei **Konfig__u__ration vor der Instalation anpassen**, weil wirgleich noch eine weitere Netzwerkschnittstelle für den internen virtuellen Switch **brdmz** definieren möchten. Auf dem folgenden Fenster wählen wir dann die Schaltfläche **Har__d__ware hinzufügen**.
 +
 +{{ :centos:kvm:virt-manager_025.png?450 |Photo: Neue Hardware hinzufügen}}
 +
 +Da wir eine neue Netzwerkkarte hinzufügen möchten fällt die nachfolgende Auswahl nicht schwer.
 +
 +{{ :centos:kvm:virt-manager_026.png?450 |Photo: Neue Netzwerk-Hardware hinzufügen}}
 +
 +Auf dem nun folgenden Konfigurationsfenster wäheln wir bei dem Punkt **__H__ost Gerät** unseren internen Switch **brdmz** aus, da die weitere Netzwerkschnittstelle mit dieser verbunden werden soll.
 +
 +{{ :centos:kvm:virt-manager_027.png?450 |Photo: Neue Netzwerk-Hardware hinzufügen}}
 +
 +Zu guter letzt werden un nochmals alle relevanten Konfigurationsdaten unserer zweiten virtuellen Netzwerkkarte angezeigt.
 +
 +{{ :centos:kvm:virt-manager_028.png?450 |Photo: Neue Netzwerk-Hardware fertigstellen}}
 +
 +Anschließend beenden wir die Konfiguration mit einem //klick// auf den grünen Haken **Installation abschließen** links oben und beginnen wir gewohnt mit der Installation unseres Gast-Betriebssystemes.
 +=== Konfiguration an vHOST ===
 +Da wir auf die Dienste des NetworkManagers auf unserem virtuellen Serversystem verzichten, bearbeiten wir unsere Netzwerkschnittstellen wie gewohnt direkt im System.
 +== eth0 (untrust network) ==
 +Für die Anbindung an die Außenwelt benutzen wir die bei der Installation festgelegten Netzwerkschnittstelle **eth0**, welche die Verbindung zur Außenwelt (untrusted network) herstellt.
 +   # vim /etc/sysconfig/network-scripts/ifcfg-eth0
 +<code>DEVICE="eth0"
 +NM_CONTROLLED="yes"
 +ONBOOT=yes
 +HWADDR=52:54:00:C0:15:C4
 +TYPE=Ethernet
 +BOOTPROTO=dhcp
 +DEFROUTE=yes
 +PEERDNS=yes
 +PEERROUTES=yes
 +IPV4_FAILURE_FATAL=yes
 +IPV6INIT=no
 +NAME="System eth0"
 +UUID=5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03
 +</code>
 +== eth1 (trusted network) ==
 +Die Verbindung zu unserem vertrauenswürdigen interenen Netzwerk ermöglichen wir über die zweite Netzwerkschnittstelle **eth1** die wir bei der Definition unseres vHOSTs mit der Bridge **brdmz** verbunden hatten. 
 +   # vim /etc/sysconfig/network-scripts/ifcfg-eth1
 +<code>DEVICE="eth1"
 +NM_CONTROLLED="yes"
 +ONBOOT=yes
 +TYPE=Ethernet
 +BOOTPROTO=none
 +IPADDR=10.0.0.10
 +PREFIX=24
 +DNS1=192.168.10.1
 +DOMAIN=dmz.nausch.org
 +DEFROUTE=yes
 +IPV4_FAILURE_FATAL=yes
 +IPV6INIT=no
 +NAME="System eth1"
 +UUID=9c92fad9-6ecb-3e6c-eb4d-8a47c6f50c04
 +HWADDR=52:54:00:0A:FA:3E
 +</code>
 +== Port Forwarding und iptables Regeln ==
 +Damit unser neuer vHOST nun die IP-Pakete auds dem internen Netzwerk **brdmz** auch an die Schnittstelle **eth0**, also zum //untrusted Netwok// weiterreichen kann, aktivieren wir noch das Portforwarding für IPv4, indem wir in die betreffende Konfigurationsdatei einfach eine **logische 1** eintragen.
 +   # vim /etc/sysctl.conf 
 +<code># Kernel sysctl configuration file for Red Hat Linux
 +#
 +# For binary values, 0 is disabled, 1 is enabled.  See sysctl(8) and
 +# sysctl.conf(5) for more details.
 +
 +# Controls IP packet forwarding
 +# Django  : 2011-08-04 Portforwarding aktiviert
 +# default : net.ipv4.ip_forward = 0
 +net.ipv4.ip_forward = 1
 +
 +# Controls source route verification
 +net.ipv4.conf.default.rp_filter = 1
 +
 +# Do not accept source routing
 +net.ipv4.conf.default.accept_source_route = 0
 +
 +# Controls the System Request debugging functionality of the kernel
 +kernel.sysrq = 0
 +
 +# Controls whether core dumps will append the PID to the core filename.
 +# Useful for debugging multi-threaded applications.
 +kernel.core_uses_pid = 1
 +
 +# Controls the use of TCP syncookies
 +net.ipv4.tcp_syncookies = 1
 +
 +# Disable netfilter on bridges.
 +net.bridge.bridge-nf-call-ip6tables = 0
 +net.bridge.bridge-nf-call-iptables = 0
 +net.bridge.bridge-nf-call-arptables = 0
 +</code>
 +Die beiden Themen //Masquerading// und //Portforwarding// erschlagen wir nun mit der Erweiterung des bestehenden iptables-Regelwerkes. 
 +  * **Masquerading** ''-A POSTROUTING -o eth0 -j MASQUERADE''
 +  * **IP Forwarding (//ankommend//)** ''-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT''
 +  * **IP Forwarding (//abgehend//)** ''-A FORWARD -i eth1 -o eth0 -j ACCEPT''
 +Beides tragen wir nun in unsere Konfigurationsdatei des Paketfilters iptables ein.
 +   # vim /etc/sysconfig/iptables 
 +<code># Firewall configuration written by system-config-firewall
 +# Manual customization of this file is not recommended.
 +*nat
 +:PREROUTING ACCEPT [0:0]
 +:OUTPUT ACCEPT [0:0]
 +:POSTROUTING ACCEPT [0:0]
 +# Django : 2011-08-04 Masquerading aktiviert
 +-A POSTROUTING -o eth0 -j MASQUERADE
 +# Django : end
 +COMMIT
 +*filter
 +:INPUT ACCEPT [0:0]
 +:FORWARD ACCEPT [0:0]
 +:OUTPUT ACCEPT [0:0]
 +-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 +-A INPUT -p icmp -j ACCEPT
 +-A INPUT -i lo -j ACCEPT
 +-A INPUT -i eth1 -j ACCEPT
 +-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
 +-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
 +-A FORWARD -p icmp -j ACCEPT
 +-A FORWARD -i lo -j ACCEPT
 +# Django : 2011-08-04 Portforwarding aktiviert eth0 = untrusted und eth1 trusted
 +-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
 +-A FORWARD -i eth1 -o eth0 -j ACCEPT
 +# Django : end
 +-A INPUT -j REJECT --reject-with icmp-host-prohibited
 +-A FORWARD -j REJECT --reject-with icmp-host-prohibited
 +COMMIT
 +</code>
 +Anschließend aktivieren wir unser geändertes Regelwerk durch einen Neustart des Systemdienstes //**iptables**//.
 +
 +Sobald nun weitere vHOSTs über die interne Netzwerk-Bridge **brdmz** aktiviert werden, können diese über unseren Firewall-HOST Daten nach außen schicken und natürlich auch die gewünschten Antwortpakete empfangen.
 +====== Links ======
 +  * **[[centos:kvm:start|Zurück zum Kapitel >>Virtualisierung mit Hilfe von KVM, QEMU und libvirt unter CentOS 6<<]]**
 +  * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]**
 +  * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
 +