Schlagwort-Archive: netzwerk

Bonding

IMG_20150805_162906-cut

Zwischenstadium beim Einrichten. Ein Upllink zu BelWue und der erste 4-er-Bond/Trunk zum Server.

Mit vier Netzwerkkabeln vom Server zum Core-Switch und vom dem aus weiter mit jeweils 4 Kabeln zum nächsten …

apt-get install ifenslave-2.6 net-tools ethtool

Die /etc/network/interfaces dazu

# The loopback network interface
auto lo
iface lo inet loopback

# Erst alle echten Interfaces hochziehen
auto eth0
iface eth0 inet manual
        bond-master bond0

auto eth1
iface eth1 inet manual
        bond-master bond0

auto eth2
iface eth2 inet manual
        bond-master bond0

auto eth3
iface eth3 inet manual
        bond-master bond0

# Trunk0 / Bond0
auto bond0
iface bond0 inet manual
        bond-slaves eth0 eth1 eth2 eth3
        bond-mode 0

# VLAN   FARBE   INHALT
# 100    BLACK   KABEL BW / Fritz BOX
# 101    GREY    Infrastruktur (Switches etc.)
# 102    RED     BELWUE Netze
# 20     BROWN   VWNetz
# 40     GREEN   paedagogisches Netz
# 41     BLUE    WLAN public (päd. Netz)
# 50     PINK    WLAN lehrer

# The LINK to BELWUE
auto bond0.102
iface bond0.102 inet static
        address xxx.xx.xx.194
        netmask 255.255.255.240
        network xxx.xx.xx.192
        broadcast xxx.xx.xx.207
        gateway xxx.xx.xx.193
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers xxx.xx.xx.4
        dns-search domain.tld
        # iptables vorbereiten - evtl. unnoetig
        up sysctl -w net.ipv4.ip_forward=1
        up modprobe ip_tables iptable_nat
        # Portweiterleitung von K9393 auf B443 fuer OMD
        up iptables -t nat -A PREROUTING -p tcp -i bond0.102 --dport 9393 -j DNAT --to-destination 192.168.0.2:443
        up iptables -A FORWARD -p tcp -d 192.168.0.2 --dport 9393 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT


auto bond0.101
iface bond0.101 inet static
        vlan-raw-device bond0
        address 192.168.0.1
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        dns-nameservers 127.0.0.1
        dns-search grey
        # add NAT / Masquerade for grey network
        up sysctl -w net.ipv4.ip_forward=1
        up modprobe ip_tables iptable_nat
        up iptables -A FORWARD -o bond0.102 -i bond0.101 -s 192.168.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
        up iptables -A FORWARD -o bond0.102 -i bond0.101 -s 192.168.0.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
        up iptables -t nat -A POSTROUTING -o bond0.102  -j MASQUERADE

auto bond0.40
iface bond0.40 inet manual
        vlan-raw-device bond0
        up ifconfig $IFACE up
        down ifconfig $IFACE down

auto bond0.41
iface bond0.41 inet manual
        vlan-raw-device bond0
        up ifconfig $IFACE up
        down ifconfig $IFACE down

auto bond0.50
iface bond0.50 inet manual
        vlan-raw-device bond0
        up ifconfig $IFACE up
        down ifconfig $IFACE down

auto bond0.20
iface bond0.20 inet manual
        vlan-raw-device bond0
        up ifconfig $IFACE up
        down ifconfig $IFACE down

Im Switch die Trunks einrichten und die VLANs den Trunks zuweisen. Reboot. Tut.

IMG_20150810_165043-2

Die zentralen Switches sind nun verkabelt und auch der Neubau hängt mit immerhin 2 Glasfasterleitungen an der Strippe.

Zuerst hatten wir Mode 4 eingerichtet. Die Geschwindigkeit war aber enttäuschend. Mit Round Robin / Mode 0 geht jetzt aber heftig mehr durch die Leitungen, wenn auch nicht das 4-fache. Außerdem: Einzelne Räume bleiben etwas magerer angebunden – z.B. der Neubau, der nun mit „nur“ 2 Glasfaserleitungen am Core-Switch hängt.

LM 6.1

Auf linuxmuster.net liegt seit ein paar Tagen die Beta der nächsten Version als VM für alle möglichen VM Hostsysteme. Ich hab das hier mal unter VirtualBox auf meinem Laptop für eine Konfiguration ausprobiert, die nur green und red als Interfaces nutzt.

Die heruntergeladenen Archive lokal mit tar xvfJ archiv.tar.xz entpacken und dann in VBox über das Menü /Datei /Appliance importieren in VBox … naja, eben: importieren. Dann erfolgen einige Anpassungen.

Da ich auf meinem, doch etwas älteren, Laptop als VMHost nur 4GB RAM habe, gab ich der Firewall die voreingestellten 256MB, dem Server 1GB und dem Client unter Lubuntu 512MB. Da musste mein Laptop zwar schwer schnaufen – und auch der virtualisierte Server – aber es läuft, wenn man Lubuntu 12.04 von der Alternate CD installiert .

Firewall

lm6-1_ipfire - Ändern_001

Die MAC Adresse der Netzwerkkarte, die später die rote Schnittstelle werden soll, habe ich hinten mit einer 0 versehen und lasse diese NATen.

lm6-1_ipfire - Ändern_002

Die Schnittstelle, die später mal grün sein soll, versah ich am Ende der MAC mit einer 1 und stellte diese auf „Internes Netzwerk“.

lm6-1_ipfire - Ändern_003

Blau will ich hier auf dem Laptop zum Testen nicht nutzen, also hab ich das „Kabel“ schlicht entfernt und die Schnittstelle nicht angeschlossen.

lm6-1_ipfire [wird ausgeführt] - Oracle VM VirtualBox_004

Beim Hochfahren des IPCop wählte ich nicht den voreingestellten PAE Kernel. Die Firewall kommt mit 256 MB RAM. Da erschien mir das nicht sinnvoll zu sein.

lm6-1_ipfire [wird ausgeführt] - Oracle VM VirtualBox_005

IPFire motzt dann beim Hochfahren, dass es seine Schnittstellen nicht finden kann, was an dieser Stelle nicht weiter stört.

lm6-1_ipfire [wird ausgeführt] - Oracle VM VirtualBox_006

Hat man sich als root und dem Passwort muster einmal eingeloggt, kann man sich durch den Setup-Prozess von IPFire hangeln, den ein setup auslöst.

Die bestehende Zuordnung der Netzwerkkarten muss man zuerst entfernen und dann neu vornehmen. Die vorher vergebenen MAC Adressen helfen bei der Orientierung.

Ein Ping ins Netz zeigt nach Beendigung des Setups, ob alles geklappt hat.

Server

Das Netzwerkinterface des Servers konfiguriert man sich in VBox wie die grüne Schnittstelle des IPFire als „Internes Netzwerk“.

Im Detail ist der Setup-Prozess im Handbuch für Version 6.0 beschrieben.

Nach dem Hochfahren des Servers einloggen (linuxadmin, muster), etwas Zeit verstreichen lassen, bis der Server Kontakt über die VBox interne Schnittstelle zum IPFire erhalten hat und dann mit ping testen, ob die Namensauflösung klappt. Dann mit sudo apt-get update ; sudo apt-get dist-upgrade evtl. vorhandene Updates einspielen und nun – nach einem Wechsel in eine Root-Shell mit sudo su – – das eigentliche Setup beginnen durch Eingabe von

linuxmuster-setup –first

Das kann dauern. LM6.1 zieht nun alle möglichen Pakete aus dem Netz, bis der eigentliche Installationsdialog beginnt (zu diesem siehe den Link zum Handbuch weiter oben).

Subnetting hab ich nicht aktiviert. Ich will vor allem mit Linbo spielen, weil wir schulintern gerade einige Höllenprobleme mit einer zickigen Hardwareklasse (Lenovo T410) haben. Alle anderen Einstellungen habe ich deswegen so übernommen, wie vom Installer als default vorgesehen.

Clients

Die Netzwerkkarten von virtuellen Clients werden wie die grüne Schnittstelle am IPFire bzw. wie die Serverschnittstelle als Internes Netzwerk konfiguriert.

Will man echte Clients testen, dann muss man sich mehr Arbeit machen. In diesem Fall legt man sich auf dem Host-System eine Netzwerkbrücke auf einer unkonfigurierten physischen Schnittstelle ethX an und verpasst dieser eine passende interne IP (siehe Netzwerksetup Homeserver NXT). Statt mit dem Internen Netzwerk von VBox verbindet man dann IPFire und Server mit dieser Bridge.

Ich weiß nicht, ob ich das extra schreiben muss, aber das klappt nur mit Netzwerkschnittstellen am Host in die man ein Kabel stecken kann. WLAN Interfaces sind außen vor. Wer WLAN virtualisiert und keine AccessPoints hierzu nutzen will, kann sich mit USB WLAN Sticks helfen, die man als USB Gerät an die VM durchreicht.

An diese physikalische Schnittstelle des Hosts hängt man einen Switch und an den Switch wiederum den physikalischen Client. Voila.

Sofern die MAC Adressen gleich bleiben, kann man dann zwischen dem physikalischen, ge-bridge-ten Netz und dem VBox internen Netz an den ausgeschalteten VMs hin- und her-schalten wie man will.

Netzwerksetup für Homeserver NXT

Die ID88 bringt wie bereits geschildert zwei Netzwerkschnittstellen mit, die dann an die virtuellen Maschinen durchgereicht werden müssen. Damit dies reibungslos funktioniert und auch die Zusammenarbeit mit dem Router (hier: Fritzbox) klappt, kann man wie folgt vorgehen, um sich eine virtualisierte Firewall zu installieren:

In der Fritzbox wird der DHCP abgeschaltet. Die IP für den Host / den Homeserver wird auf dessen nach Außen / zum Router zeigendem / rotem Interface händisch vergeben. In meinem Fall wäre das eth1 auf dem Host.

  • Der Router hat die IP 192.168.2.1 und nutzt eine Netzmaske 255.255.255.0
  • Das vom Host zum Router zeigende Interface erhält im folgenden Beispiel die IP 192.168.2.200

Auf dem nach Innen / zum Heimnetz zeigenden / grünen Interface des Hosts / Homeservers (in meinem Fall eth0) benötigt man eine Bridge, damit alle virtuellen Maschinen im internen Netz mit ihren eigenen MACs (und damit später auch ihren eigenen IP-Adressen) auftauchen können. Hier ist die IP der Bridge auf dem Host nicht mehr als die IP eines Switches – die IP Adresse des Gastes wird im Gast selbst festgelegt.

  • Nach Innen erhält der Host die IP 10.16.1.100 (eingestellt auf dessen Bridge br0 und nicht auf eth0. Eth0 auf dem Host bleibt komplett unkonfiguriert)
  • Das Heimnetz selbst ist ein 10.16er Netz mit Netzmaske 255.255.0.0 oder  10.16.0.0/16 (damit bekomme ich genug Freiraum für die nächsten Jahre und kann außerdem dafür sorgen, dass Geräte, die ich zwischen Schule und zu Hause hin und her trage immer die gleiche IP haben)

Sollte Ubuntu als Host-Betriebssystem zum Einsatz kommen, dann greift man zur Server-Ausgabe. Diese bringt keinen network-manager mit, der einem beim Setup dazwischen schießen würde. Setzt man eine Desktop-Version ein, dann muss der network-manager zuerst entfernt werden. Das Setup funktioniert nur, wenn man die Interfaces selbst konfigurieren kann.

Zusammengefasst: Auf dem Host steht in /etc/network/interfaces:

# Das Interface in Richtung Router
auto eth1
iface eth1 inet static
address 192.168.2.200
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1
dns-nameservers 213.73.91.35 192.168.2.1 85.214.20.141

# Das Interface in Richtung Heimnetz
auto br0
iface br0 inet static
address 10.16.1.100
netmask 255.255.0.0
bridge_ports eth0
bridge_fd 5
bridge_stp no

Eth0 auf dem Host bleibt – wie oben schon geschildert – unkonfiguriert. Der Host ist dann aus dem Heimnetz unter der IP der Bridge direkt zu erreichen und lässt sich so leicht warten.

Eth1 auf dem Host habe ich nicht nur mit dem Nameserver auf dem Router, sondern zusätzlich noch mit den DNS des CCC und Foebud versorgt. Man weiß ja nie.

Nun legt man sich die erste Virtuelle Maschine (hier unter VirtualBox, das unter einem normalen Benutzeraccount läuft) mit zwei Netzwerkkarten an.

vbox_eth_nat

Das „zum Router“ zeigende Interface der VM wird als NAT angelegt.

Damit ich die Netzwerkkarten später in der VM wieder finde, schreibe ich deren MAC Adressen immer so um, dass „rot“ eine 1 (für eth1 des Hosts) am Ende hat – und „grün“ eine 0 (für eth0 des Hosts).

vbox_eth_bridged

Das „nach Innen“ ins Heimnetz zeigende Interface der VM wird an die Bridge br0 des Hosts angeschlossen.

Ist der erste Host (hier IPFire als Firewall) gestartet, richtet man dessen Interfaces ebenfalls händisch her. Das nach Außen zeigende, rote Interface erhält vom DHCP auf dem NAT der VirtualBox irgendeine 10er Adresse. Welche, ist relativ egal. Später eingerichtete Portweiterleitungen übernimmt VirtualBox. Wichtig sind die Angaben für das interne, grüne Interface (also das, das an der Bridge des Hosts hängt). Hier muss die /etc/network/interfaces des Gastes angepasst werden (im Falle von IPFire über dessen Weboberfläche).

# Das rote Interface zeigt in Richtung Router und haengt am VBox NAT
auto eth0
iface eth0 inet dhcp

# Das gruene Interface zeigt in Richtung Heimnetz und haengt an der Bridge des Hosts
auto eth1
iface eth1 inet static
address 10.16.1.1
netmask 255.255.0.0

Die erste VM ist aus dem Heimnetz dann unter 10.16.1.1 zu erreichen.

So lange auf dem IPFire noch kein DHCP Server auf grün läuft, muss man sich auf einem Client eine 10.16.er Adresse händisch selbst zuweisen, damit man an die Weboberfläche kommt.

Die Installation weiterer VMs hängt direkt vom Sicherheitsbedürfnis ab. Zwei Wege sind möglich: einer führt über virtuelle Netzwerkkarten an der Firewall-VM (blau und orange), der andere richtet VMs „neben“ der Firewall ein.

vbox_internalnetwork

Wählt man die sicherere Variante (weitere Netzwerkkarten in der Firewall-VM), richtet man diese NICs in VirtualBox als „Internes Netzwerk“ ein. Die VMs hängen dann mit ihrem roten Interface direkt an der Firewall und ebenfalls im VM-internen-Netzwerk. Das wäre z.B. ein Weg, um ein orangenes Netz einzurichten (siehe Bild oben für die Netzwerkkarte eines Webservers im orangen Netz von IPFire).

Aside: Ein blaues Netz ist nicht so einfach zu haben, weil WLAN Karten auf dem Host nicht als solche in VMs hinein gereicht werden können. Man kann sich hier aber mit USB-WLAN-Sticks helfen, die an die VM gebunden und aus dieser heraus konfiguriert werden.

Wählt man die unsicherere Variante, richtet man weitere VMs „neben“ der Firewall ein. Das Setup entspricht hierbei jeweils der Einrichtung der ersten VM: Eth1 des Gastes mit VBox-NAT zeigt nach Außen. Die nach Innen zeigende Schnittstelle des Gastes (eth0) wird im Gast händisch mit einer IP versorgt und klebt an der Bridge br0 auf dem Host.

Fällt ein derartiger Gast in fremde Hände, steht dem Angreifer das komplette interne Netz offen. Die Firewall ist hier reduziert auf ihre Webfilter-/DHCP-Funktionen für das interne Netz. Schutz von Außen bietet sie so nur bedingt. Man sollte aber wegen einer derartigen Konstruktion nicht gleich in Panik ausbrechen. Ge-nat-ete VMs dürften von Außen schwer zu knacken sein. Bei Portweilterleitungen vom Router auf eine solche VM macht man jedoch ein Türchen für Angriffe auf und muss eine derartige VM (eine Brücke zwischen Internet und Heimnetz) dann noch einmal gesondert absichern (iptables, fail2ban, tripwire etc. pp.). Oder man spart sich das interne Interface gleich komplett.

Hier vermehren sich die VMs fast täglich: Die Firewall war zuerst da, dann kam ein Fileserver, dann ein Nameserver, ein Webserver, ein Gameserver … 10er Netze und viel RAM auf dem Host lassen viel Raum für Spinnereien 🙂

F17 XFCE Spin

Dass ein Betriebssystem heute noch so startet, dass es nicht „einfach so“ Verbindung mit dem Internet aufnehmen kann … das erlebt man wohl nur noch bei Linux. Konkret beim Fedora 17 XFCE Spin. Der fährt zwar beim Boot seine Interfaces hoch, kennt aber zu Beginn keine Nameserver.

Wenn sich die Schnittstelle p2p1 nennt, dann muss man unter

/etc/sysconfig/network-scripts/ifcfg-p2p1

Einträge für die gewünschten Nameserver nachtragen – z.B.:

DNS1=8.8.8.8

für den Nameserver von Google. Die Einträge können schlicht unten an die Datei angehängt werden.

Ist ja nett, wenn man selbst fummeln kann – aber warum holt sich F17 XFCE diese nicht schlicht vom DHCP und dann gleich passend zum lokalen Netz? Es ist schließlich häufig so, dass Port 53 blockiert wird … und dann darf man diese Anpassungen in jedem Netz erneut machen.

Oneiric ohne Netz

Nach den letzten Updates von Oneiric Beta hängte sich der Netzwerk-Manager komplett auf. Eine Lösung ist hier beschrieben:

https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/855171

Im dümmsten Fall (so wie bei mir), muss man sich das Paket libnss3 auf einem anderen Rechner hier

http://packages.ubuntu.com/de/oneiric/libnss3

herunter laden, auf USB Stick schieben und dann mit

sudo dpkg -i /pfad/zum/stick/libnss3_3.12.9+ckbi-1.82-0ubuntu6_i386.deb

auf Oneiric einspülen. Nach einem Reboot funktioniert das Netz dann wieder.

Netzwerkkartenwechsel

Bei der Virtualisierung bestehender Maschinen erhalten diese in ihrer dann virtuellen Umgebung einen anderen Netzwerkkarten Typ und damit auch eine neue Schnittstellen-Bezeichnung. Dies sorgt dann für Probleme, wenn z.B. eth0 auf eine fixe IP Adresse gelegt war, sich nun die virtuelle Maschine mit der „neuen“ Karte aber so fühlt, als hätte diese nur eth1. Diese Schnittstelle ist dann nämlich nicht konfiguriert und die VM kommt nicht ins Netz.

Abhilfe schafft die Bearbeitung der Datei

/etc/udev/rules.d/70-persistent-net.rules

In diese trägt Ubuntu ein, welcher Karte es welche Schnittstellen-Bezeichnung zugewiesen hat und hier kann man dann die nicht benötigten Zuweisungen (an die nicht mehr vorhandenen Karten) löschen und die bestehenden anpassen (also eth1 durch eth0 ersetzen).

Reboot und tut.

Auch praktisch ist dieses Vorgehen auf einem IPCop, der zwei identische NICs verbaut hat. Da darf man im Setup nämlich raten, welche NIC nun welches Netz erhalten hat. Kein Drama, wenn es den IPCop in real gibt. Da steckt man schlicht die Kabel um. Wenn man jedoch einen UnCop aufgesetzt hat und ein Interface an einer Bridge hängt, dann ist das schon fummeliger, weil die Re-konfiguration im Virtualisierer erfolgen muss.

Einfacher geht es durch Anpassung dieser Datei auf dem IPCop selbst:

/var/ipcop/ethernet/settings

Nach einem Reboot klappt es dann wieder mit der Verbindung.