Herstellung einer Site-to-Site Verbindung Fritzbox / Sophos SG UTM

Die Herstellung einer solchen Verbindung ist etwas experimentell, da sich die im Internet zu findeden Anleitungen und technischen Beschreibungen zu widersprechen scheinen.

Die vorliegende Config ist getestet auf einer FRITZ!Box 7430 mit FRITZ!OS: 07.01 und unterstützt Verschlüsselungseinstellungen, die auch auf der Sophos-Gegenstelle zur Verfügung stehen.

Alle Stellen die mit <…> bezeichnet sind müssen auf die eigene Umgebung konfiguriert werden. Die spitzen Klammern müssen dabei entfernt werden.

vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = „<symbolischer Gegenstellen-Name>“;
always_renew = yes;
keepalive_ip = <interne ip der vpn-gegenstelle>;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = <externe ip der Gegenstelle>;
remote_virtualip = 0.0.0.0;
remotehostname = „<fqdn der Gegensstelle>“;
localid {
fqdn = „<fqdn der externen Seite der Fritzbox, bspw xxxxxxxxx.myfritz.net>“;
}
remoteid {
ipaddr = „<externe ip der Gegenstelle>“;
}
mode = phase1_mode_idp;
phase1ss = „alt/all-no-aes/all“;
keytype = connkeytype_pre_shared;
key = „<eingeheimerschlüssel>“;
cert_do_server_auth = no;
use_nat_t = no;
use_xauth = no;
use_cfgmode = no;

phase2localid {
ipnet {
ipaddr = <lokales internes Netz, bspw: 192.168.178.0>;
mask = <lokale interne NW-Maske: bspw 255.255.255.0>;
}
}
phase2remoteid {
ipnet {
ipaddr = <remote internes Netz, bspw 192.168.0.0>;
mask = <remote interne NW-Maske, bspw 255.255.255.0>;
}
}
phase2ss = „esp-3des-sha/ah-no/comp-no/pfs“;
accesslist = „permit ip any <remote internes Netz, s.o.> <remote interne NW-Maske, s.o.>“;
}
ike_forward_rules = „udp 0.0.0.0:500 0.0.0.0:500“,
„udp 0.0.0.0:4500 0.0.0.0:4500“;
}
// EOF

Cisco 2960 Checks

Eine größere Lieferung Switche für ein Kundenprojekt war eingetroffen, und musste geprüft werden. Die Switche waren zum Teil bereits in Benutzung gewesen, daher mussten alte Konfigurationen gelöscht werden.

Daneben wurden Performance- und Latenztests gemacht. Dazu wurden die Switche kaskadiert verkabelt und dann Ende-Ende Verbindungen hergestellt.

 

Es zeigt sich, dass auf TCP/IP Ebene keine Latenzeinbrüche messbar sind, auch wenn wie hier 23 Switche hintereinander liegen.  Die typische Latenz über einen Switch beträgt beim Cisco 2960 (ohne Berücksichtigung von Jumbo-Frames) ca. 6-8 μs , über alle Switche ergibt das eine erwartbare Latenz von 200 μs und liegt daher deutlich unter der Toleranz-Schwelle üblicher TCP/IP Netzwerktools.

 

Ipsec Verbindung zwischen Telekom Digitalisierungsbox Standard und Sophos UTM 9

Da im Internet nur sehr vage oder veralterte Anleitungen zur Herstellung einer solchen Ipsec Verbindung zu finden sind werden hier die wichtigen Stellen als Screenshots dargestellt.

Digibox:  Zunächst erstellt man mit dem Assistenten eine Verbindung und ändert diese an entsprechend den Screenshot ab. Der Zugangs-/Darstellungslevel sollte auf „Vollzugriff“ stehen. (Achtung – Fehler im Screenshot: „Compression“ bitte AUS-schalten.)

Sophos:   Vorab werden Objekte für lokale und remote Netzwerk(e) erstellt. Danach wird eine Ipsec Verbindung nach folgendem Muster erzeugt:

 

xwiki Mysql Datenbank umziehen / Upgrade

Beim Versuch ein xwiki auf einem neuen Server zu importieren hatten wir zuletzt das Problem, dass tomcat diese Wiki nicht starten wollte. Wir hatten auf dem alten Server die zum Wiki zugehörige MySql-Datenbank wie üblich gedumpt und auf dem neuen Server die DB neu angelegt und den Dump eingespielt.

Man lernt halt nie aus: Das Einspielen des Dumps reicht nicht zwingend.

Der Mysql-Server hatte eine für xwiki unpassende Default Kollation (hier: utf8mb4_general_ci), und mit dieser wurden auch die von Hand angelegten Datenbanken angelegt und dies wurde beim Import des Dump auch nicht überschrieben.

Die vom Dump angelegten *Tabellen* sind alle richtig, aber xwiki legt zwischenzeitlich temporär weitere Tabellen an, ohne eine kollation anzugeben, und die werden dann mit der (Default-)Kollation der Datenbank selbst angelegt, was aber nicht zingend die von xwiki gewünschte ist.

Abhilfe:

Mittels „ALTER database <meine-db> DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;“ die Kollation auf utf8_bin für jene Datenbank umstellen, die mittels Dump zurückgespielt wurde.  Danach startete Tomcat und man konnte die Migration durchführen.

xwiki-mysql

Elastistor NAS

Eine kurze Begegnung mit CloudBase Elastistor/Elasticenter

Es gibt eine ganze Reihe Nas Software-Appliances am Markt, bei zfs Backend dünnt es sich das Angebot schon deutlich aus. Der Autor hat  Erfahrung mit zfs-Linux und mit Nexenta, mit denen er seit Jahren arbeitet. Dieser Test wurde aufgrund der beworbenen HA-Fähigkeit von ElastiStor gemacht, CloudBase bietet seine Appliance bis bei Nutzung 25 TB als dauerhaft kostenfrei nutzbare Software an. Getestet wurde auf einem HP360-G5 mit 2*4-Core 5450 CPU, 64GB Ram und 2*146GB Platten für das System, an dem eine HP MSA70 mit 25*146 GB SAS Platten für den Storage angebunden war. Server und JBOD Shelf stehen nicht auf der CloudBase Hardware Kompatibilitäs Liste.

Installation

Bei der schnellen und problemlosen Installation fiehl auf, dass Elastistor das MSA70 Disk-Shelf nicht als solches erkennt, sondern nur die einzelnen verbauten Platten, diese werden mit Ihren IDs und Devicenamen angezeigt. Nach der Installation wurde klar, dass Elastistor auf die „internen“ Festplatten des DL360 keinen Zugriff hatte, und das System selbst bereits auf eine der Festplatten auf dem Shelf durchgeführt hatte. Auch später konnten die internen Laufwerksschächte (bspw. für L2Arc oder Log Aufgaben) nicht genutzt werden.

elasti-node
ElastiCenter – zeigt einen Node mit Shelf (unten) und angelegten Pools

Webgui

Elastistor umfasst eine Web-GUI „Elasticenter“, die auch unter Last immer sehr flüssig lief (von Nexenta ist man hier anderes gewohnt). Die Oberfläche glänzt mit aussagefähigen Grafiken, die jederzeit einen guten Eindruck von Leistung und Kapazität vermitteln. Die Konfigurationen sind zum Teil an Stellen versteckt, die zunächst gewöhnungsbedürftig erscheinen. Nach kurzer Zeit findet man sich aber gut zurecht.

Architektur

WorkflowToSetupYourStorageEnvironmentUsingCloudByteElastiCenter
Architektur und Workflow in Elastistor

Elastistore bildet die Elemente und Hierarchie einer zfs Umgebung erwartungsgemäß sauber ab und fügt weitere Komponenten (HA-Group, VSM) hinzu. dies macht den eigentlichen (Mehr-)Wert der Software aus. Alle konfigurierbaren Storage-Elemente können neben Größe auch anhand von IOPS oder Durchsatz provisioniert werden. Die erkannten Festplatten wurden hinsichlich ihrer Leistungsfähigkeit automatisch und realistisch eingeordnet. Im Folgenden gehe ich nur auf die Besonderheiten ein, die diese Lösung von einer reinen zfs Lösung abhebt:

VSM

Elastistor bietet sog. Virtual Storage Machines (VSM), die eine Abstraktionsschicht zwischen „Storage Volumes“ und zfs Pools bilden. „Volumes“ sind die „Freigaben“, die bspw. per nfs bereitgestellt werden. Diese werden auf einer VSM definiert. Eine VSM wiederum wird auf einem „Pool“ angelegt. Dieses Vorgehen eröffnet im Wesentlichen zwei Möglichkeiten:

  1. Eine VSM (und damit ein darauf befindliches Volume) kann migriert werden, und zwar sowohl auf einen anderen Pool, als auch auf einen anderen Node. Damit kann man bspw. unterbrechungsfrei auf neue Hardware migrieren.
  2. Einer VSM kann eine zweite Backup-VSM (sog. DR-VSM) zugeordnet werden, die auf einem anderen Storage Pool liegt. Mittels zfs Snapshot Replikation kann dann regelmaessig ein Remote Backup erstellt werden, dass dank des Snapshots aus Storage Sicht immer konsistent ist. Bei Bedarf oder im Fehlerfall kann die Backup-VSM jederzeit hochgestuft („aktiviert“) werden und die primäre VMS ersetzen. Dabei muss ggf. noch die geänderte NFS-Konfiguration im Clientbereich nachkonfiguriert werden. (Die VSM bietet offensichtlich kein NFS-Failover.)

HA-Group

sas_multipath
SAS Multipathing als Grundlage einer HA-Group

Eine HA-Group bildet auf unterer Ebene eine Ausfallredundanz für den Verlust eines Nodes ab. Ein Node ist definiert als ein Server, der Zugriff auf ein Disk Shelf hat. Ist ein Disk Shelf (bspw. über SAS Multipathing) an zwei Nodes angebunden, können beide in einer HA-Group zusammengefasst werden.  Ein definierter Pool ist dann über jeden Node der HA-Group verfügbar.

Nachteile

Dass Node-interne Festplatten unberücksichtigt bleiben, ist durch den HA-Ansatz grundsätzlich nachvollziehbar, aber in kleineren Umgebungen nachteilig.

Das eigentliche zpool Handling (Anlegen eines Pools, vdev Verwaltung, hinzufügen von Platten zu Spiegelsätzen etc.) ist nicht sonderlich schön abgebildet. Zudem fehlen wichtige Dinge (bspw. ist es nicht möglich gewesen, einen vdev-Mirror wieder aufzulösen bzw. den/die Spiegelplatten zu entfernen).

Fazit

Die Lese- und Schreibleistung wurde nicht quantitativ gemessen, die Performance lag im Rahmen des zu erwartenden Bereichs. Ein zStripe (Raid0) mit 24 Platten ergab lokale Schreibraten von ca. 800 MB/s und ca 3500 IOPS. Lese- und Schreibcaches wurden dabei nicht verwendet.  NFS über 1Gbit/s Ethernet wurde erwartungsgemäß komplett ausgelastet.

Die Aufgaben, die sich in einer mittelgroßen Storageumgebung (die ausschliesslich mit Disk Shelfs arbeitet) ergeben, können mit der Community Edition von Elastistore (bis 25TB) gut abgebildet werden. Besonders die gelungene Integration von zfs-Replikation und SAS Multipath-HA geht über Möglichkeiten der (freien) Nexenta-Versionen deutlich hinaus.  Der Feature-Umfang ist für eine „freie“ zfs NAS einzigartig.