OpenVSwitch GRE Tunnel zur VM Vernetzung

11 Mai 2019 Lesezeit: 3 Minuten

Ich hatte in meinem Beitrag Promox auf einem Hetznerserver mit virtuellen Netzwerken beschrieben, wie man virtuelle Netzwerke auf einem Hypervisor mit Hilfe von Linux Bridges erstellt. Diese Netzwerke können dazu verwendet werden, eigene Infrastrukturen aufzubauen und so sehr isoliert VMs zu betreiben.

Wenn nun aber die Ressourcen eines Hosts zur Neige gehen und man einen weiteren Host aufstellt, dann kommt irgendwann vielleicht der Wunsch auf VMs übergreifend in einem dieser virtuellen Netzwerke betreiben zu können. Damit diese möglich ist, muss es aber eine Verbindung dieser beiden Bridges (Netzwerke) geben, welche die Kommunikation ermöglicht.

Dazu kann man super OpenVSwitch einsetzen. Dieses Projekt ist ohnhin sehr interessant, da es sich bei vielen Lösungen wiederfindet - so zum Beispiel auch bei Proxmox und OpenStack.

Damit man über Hardwaregrenzen hinweg ein virtuelles Netzwerk aufspannen kann, muss man sich erst einen virtuelle Switch aufbauen. Zur Sicherheit aktivieren ich auch gleich STP

ovs-vsctl add-br vmbr2
ovs-vsctl set bridge vmbr2 stp_enable=true

In diesem Switch packt man dann die Netzwerkkarten der virtuellen Maschinen.

 ovs-vsctl add-port vmbr2 tap100i2

Sobald dies auf beiden Hosts passiert ist, kann man mit Hilfe eines GRE Tunnels diese beiden Switches verbinden.

ovs-vsctl add-port vmbr2 gre1 -- set interface gre1 type=gre options:remote_ip=XXX.XXX.XXX.XXX

XXX.XXX.XXX.XXX ist natürlich die IP-Adresse des anderen Servers.

Und weil ich ein Fan von Proxmox bin und grundsätzlich schon recht bequem, hab ich keine Lust das jedes Mal von Hand zu machen und trage es daher einfach in die /etc/network/interfaces ein.

auto vmbr2
allow-ovs vmbr2
iface vmbr2 inet manual
    ovs_type OVSBridge
    post-up ovs-vsctl set bridge vmbr2 stp_enable=true
    post-up ovs-vsctl add-port vmbr2 gre1 -- set interface gre1 type=gre options:remote_ip=XXX.XXX.XXX.XXX

**Quellen und Links: *** http://docs.openvswitch.org/en/latest/faq/configuration/


Promox auf einem Hetznerserver mit virtuellen Netzwerken

4 Mai 2019 Lesezeit: 3 Minuten

Wenn ich ein Thema ziemlich zweifelhaft finde, dann ist es Cloudcomputing. Ich kann verstehen wann und warum man das macht. Was mir aber nicht gelingt ist den wandel von "VServer" zu "CloudInstanz" zu akzeptieren - immerhin habe ich "damals" mehr für weniger einsatz bekommen.

Wie dem auch sei. Ich mag Proxmox als Möglichkeit seine Virtualisierung zu realisieren. Man könnte ja auf die Idee kommen, dass man das auch auf seinem Root-Server bei zum Beispiel Hetzner haben möchte. Lustiger Weise wird das sogar angeboten. Was dann leider noch zu tun ist, ist die Absicherung und vor allem aber die Einrichtung von virtuellen Netzwerken, damit man seine Infrastruktur auch fein separieren kann.

In meinem Setup mache ich das mit einfachen Linux-Bridges. Wer es nocht etwas "cooler" haben will, dem kann ich einen Cluster mit OpenVswitch empfehlen. Das kommt vielleicht ein anderes Mal.

Mein Ziel ist, das es eine Bridge gibt, an die ich bestimmten Traffic (in meinem Fall HTTP/HTTPS) weiterleite um dort mit Hilfe von zum Beispiel OpenSense einen Reversproxy mit SSL Offloading anzubieten. So kann ich dann "hinter" dieser Firewall beliebig viele "virtuelle Netzwerke" aufbauen und routen/regeln wie man es von einer "richtigen" Installation kennt.

Dazu richte ich mir zunächst eine Bridge ein die auch eine IP-Adresse bekommt und sorge dafür dass beim hochfahren auch gleich die notwendigen iptables Regeln gesetzt werden um zum einen das NAT für den ausgehenden Traffic zu realisieren. auch will ich, wie schon oben beschrieben, das eingehender Traffic auf Port 80 und 443 zur OpenSense Installation weitergereicht wird, die mit der Bridge verbunden ist.

/etc/network/interfaces

auto vmbr0
iface vmbr0 inet static
  address 10.11.12.1
  netmask 255.255.255.0
  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.11.12.0/24' -o ***NAME-SER-NETZWERKKARTE*** -j MASQUERADE
  post-down iptables -t nat -D POSTROUTING -s '10.11.12.0/24' -o ***NAME-SER-NETZWERKKARTE*** -j MASQUERADE
  post-up iptables -t nat -A PREROUTING -i ***NAME-SER-NETZWERKKARTE*** -p tcp --dport 80 -j DNAT --to 10.11.12.2:80
  post-up iptables -A FORWARD -j ACCEPT -p tcp --dport 80 -d 10.10.99.2
  post-up iptables -t nat -A PREROUTING -i ***NAME-SER-NETZWERKKARTE*** -p tcp --dport 443 -j DNAT --to 10.11.12.2:443
  post-up iptables -A FORWARD -j ACCEPT -p tcp --dport 443 -d 10.11.12.2

Anschließend richte ich einfach weitere Bridges ein, die ich dann verwende um private LAN innerhalb des Proxmox bereitzustellen.

auto vmbr1
iface vmbr1 inet manual
 bridge-ports none
 bridge-stp off
 bridge-fd 0

Anschließend können die neuen Bridges wie folgt aktiviert werden:

ifup vmbr0
ifup vmbr1

3Com Baseline Switch 2952 per Konsole bedienen

13 Apr 2018 Lesezeit: 2 Minuten

Es gibt Tage, an denen mag es einfach nicht laufen. So auch heute, als ich versucht habe ein Netzwerksetup an einem 3Com Baseline Switch 2952-SFP zu debuggen. In der (fürchterlichen) UI gab es viele Anlaufstellen. So viele, das ich irgendwann offenbar den Wald vor lauter Bäumen nicht mehr sah und mich kurzerhand ausgesperrt habe.

Gott sei dank hatte ich noch einen USB-Serielladapter und ein entsprechendes Konsolenkabel zur Hand. Kurzerhand bin ich dann zum Switch und wollte rückgängig machen was ich verbock hatte - doch ganz so einfach sollte es dann doch nicht sein.

Doch eine, zwei Suchen im Internet später bin ich dann zu den Informationen gelangt, welche mir das Tor zum Himmel öffnen sollten.

Die notwendigen Schritte sind die folgenden:

  1. Anschließen der ganzen Adapter-Geschichte an den Rechner
  2. sudo screen /dev/ttyUSB0 38400,81n im Terminal
  3. Switch rebooten (Stecker raus; Stecker rein)
  4. Warten bis es soweit ist: Benutzernamen und Kennwort eingeben

Jetzt ist man drin und alles ist gut - von wegen. Man hat nun so ziemlich keine brauchbaren Tools zur Hand um den Switch zu konfigurieren. Dazu ist erst ein wenig Magie notwendig um quasi in den VIP Bereich zu kommen:

  1. _cmdline-mode on
  2. Password: 512900
  3. sys

jetzt kann es richtig losgehen und der Switch dankt es einem vielen vielen neuen Funktionen.

Quellen: