Achtung: Fehlfunktion durch ablaufende Sicherheitszertifikate bei den Dell OS10 Switches

Dell hat gerade seine Kunden gerade per E-Mail angeschrieben und vor einem besonders heimtückischen Problem bei den OS10 Switches gewarnt. Bestimmte Versionen von OS10 (beginnend mit 10.4.1.4 bis 10.5.0.7 P3) enthalten ein Standardzertifikat, das für VLT Peer Establishment und die SFS-Cluster-Bildung verwendet wird. Und genau dieses Standardzertifikat läuft am 27. Juli 2021 ab. Dell beschreibt im Knowledge Artikel 000184027, wie man das Ablaufen des Zertifikates verhindern kann. In den meisten Konstellationen wird ein Update des OS10 auf eine aktuelle Version empfohlen. Ein Update von OS10 verursacht einen Netzwerkausfall. Deshalb sollten betroffenen diesen Artikel unbedingt zu Ende lesen.

Wenn das Zertifikat abläuft kann es zu massiven Fehlfunktionen bei betroffenen Switches kommen, sofern auf diesen VLT Peer Establishment und die SFS-Cluster-Bildung verwendet wird. Es könnte z.B. zu einem nachfolgenden Switch-Neustart, einer Link-Flap-Lösung, einer Operator-ausgelösten Konfigurationsänderung, VMotion und anderen Netzwerkereignissen kommen.

Aktualisierung von OS10 löst das Problem

Auf den von mir betreuten Switchen war die OS10 Version 10.5.0.1P1 installiert. Somit waren diese betroffen. Um das Problem zu lösen, empfiehlt Dell ein Update auf die aktuelle OS10 Version. Deshalb habe ich die Switche auf die OS10 Version 10.5.2.3 aktualisiert. Wie das im einzelnen geht, habe ich bereits in dem Blogartikel Dell OpenNetwork Switches mit OS10 beschrieben. Wer in der gleichen Situation wie ich ist, kann dort eine Anleitung für das Update der Switche finden.

Netzwerkausfall bei der Aktualisierung der Switche

Da Ich VLT Peer Establishment über jeweils zwei Switche verwende, wähnte ich mich vor einem Netzwerkausfall in Sicherheit. Genau dazu ist die VLT Technik ja schließlich gedacht. Wenn ein Switch ausfällt sollte der andere ohne Ausfall übernehmen. Dies war aber leider ein Trugschluss. Obwohl der Versionssprung von 10.5.0.1P1 auf 10.5.2.3 keine großen Änderungen suggeriert, wurde die Version des VLT Protokolls von Version 2.3 auf die Version 3.1 angehoben. Diese Versionen scheinen nicht kompatibel zu sein und es kommt nach dem Update des ersten Switches zu einer Netzwerkstörung, bis der zweite aktualisiert wurde.

Was sagt der Dell Support dazu?

Ich habe nach auftreten der Störung sofort den Support von Dell angerufen. Da kein Support-Mitarbeiter in deutscher Sprache verfügbar war, wurde zwar sofort aber auf englisch sehr freundlich beraten. Leider erhielt ich aber nur die Aussage, dass die Versionen der VLT Protokolle eben nicht kompatibel sind und man mit diesem Netzwerkausfall während dem Update eben leben müsse. Der Support versprach aber auch, dass sich nochmal ein Spezialist melden würde, der uns zu dem Update berät. Deshalb haben ich die Updates zunächst unterbrochen und werde noch mal ein paar Tage abwarten, ob sich jemand meldet. Vielleicht gibt es ja doch noch eine Lösung ohne Netzwerkausfall. Sofern dies der Fall sein sollte, werde ich den Blogeintrag hier entsprechend ergänzen.

Persönliches Fazit

Wir hatten uns für die hochpreisigen Switche von Dell entschieden, um mit VLT genau solche Ausfälle zu vermeiden. Deshalb bin ich aktuell etwas enttäuscht. Nach gerade mal zwei Jahren, kommt es durch ein kurzfristig notwendiges Update zu genau einem solchen Ausfall. Ansonsten haben uns die Switche bis jetzt aber noch nicht im Stich gelassen und wir sind sehr zufrieden mit ihnen. Insofern hoffe ich, dass dies ein unglücklicher Einzelfall war, der sich so schnell nicht wiederholen wird.

UniFi Access Point U6 Lite mit Wi-Fi 6

In den aktuellen Zeiten wird immer mehr an die Haustür geliefert. Auch heute klingelte ein Paketbote und lieferte wie fast jeden Tag ein Paket ab. Diesmal war allerdings etwas besonderes und langerwartetes in dem Paket. Der UniFi Access Point U6 Lite mit Wi-Fi 6 von Ubiquiti. Endlich! Diese hatte ich schon vor Monaten bestellt.

Wie viele Hersteller hat auch Ubiquiti seit langem Wi-Fi 6 Produkte angekündigt. Diese waren aber ewig nicht lieferbar. Die Chipindustrie hat aktuell enorme Probleme mit der Produktion nachzukommen. Und insbesondere WLAN-Chips scheinen aktuell knapp zu sein. Dies führt dazu, dass angekündigte Produkte oft erst Monate später lieferbar sind. Aus diesem Grund musste ich mehrer Monate auf die bestellten Wi-Fi 6 Access Points von Ubiquiti warten, bevor diese endlich an meiner Haustür ankamen.

Was ist Wi-Fi 6?

Für diejenigen die es noch nicht wissen: Wi-Fi 6 ist der neue WLAN-Standard von der Wi-Fi Alliance mit der Bezeichnung IEEE 802.11ax. Der Nachfolger von Wi-Fi 5 mit der Bezeichnung  IEEE 802.11ac. Da die Bezeichnungen dieser Standards sehr kryptisch sind und dem normalen Benutzer nicht erkennen lassen, welcher Standard der neuere ist, hat sich die Wi-Fi Alliance im Jahr 2018 für die Vermarktung den einfacheren Namen Wi-Fi mit fortlaufender Nummer ausgedacht. Die Verwendung der neuen Namen wurde anschließend per Pressemitteilung angekündigt. Inzwischen sind deshalb die meisten WLAN-Produkte nur noch mit den neu ausgedachten Namen gekennzeichnet.

Warum Wi-Fi 6?

Die vorherigen WLAN-Standards legten den Fokus auf schnellere Datenübertragungen und größere Reichweite. Man konnte dadurch Daten schneller und weiter übertragen. Bei Wi-Fi 6 ist das anders. Hier verbessern sich vor allem die Geschwindigkeiten, wenn viele Geräte gleichzeitig das WLAN nutzen. So richtig bemerken wird man Wi-Fi 6 also erst, wenn man viele Teilnehmer in einem WLAN hat, die Wi-Fi 6 unterstützen und viele Daten senden. Wenn man nur wenige Gärten oder noch viele Wi-Fi 5 Geräte hat, wird man den Unterschied kaum wahrnehmen.

Um bei vielen Geräten in einem WLAN die Geschwindigkeit zu verbessern, befinden sich die wesentlichen Änderungen von Wi-Fi 6 in der Multi-User-MIMO-Antennentechnik. Bei dieser wird die bisherige Technik namens Orthogonal Frequency Division Multiple Access (OFDMA) zur Multi User Orthogonal Frequency Division Multiple Access (MU-OFDMA) erweitert. Dadurch ist es zukünftig möglich, dass mehrere Teilnehmer in einem WLAN gleichzeitig Daten übertragen.

Bis Wi-Fi 5 konnte konnte immer nur ein Teilnehmer zur Zeit Daten übertragen. Dies führte dazu, dass bei vielen Teilnehmern nicht genügend Zeit vorhanden war, damit alle Daten übertragen werden konnten. Da weit entfernte Teilnehmer die Daten nur langsam Übertagen konnten, verbrauchten diese zu viel Sendezeit. Dies hatte die Folge, dass für Teilnehmer in der unmittelbaren Nähe nicht genügend Zeit verblieb. Durch diesen Mangel an Sendezeit reduzierte sich die Geschwindigkeit bei den Datenübertragungen stark und diese WLAN Netzwerke blieben weit hinter den theoretischen Übertragungsraten zurück.

Bei Wi-Fi 6 können jetzt mehrere Teilnehmer gleichzeitig senden. Dadurch steht für die Teilnehmer eines WLAN erheblich mehr Sendezeit zur verfügung. Es kommt bei vielen Teilnehmern also nicht mehr so schnell zu einem Mangel an Sendezeit.

Erste Erfahrungen mit dem UniFi Access Point U6 Lite

Ich habe den neuen Access Point in meinem Setup gleich mal mit einem seiner Vorgänger dem UniFi Access Point nanoHD mit Wi-Fi 5 verglichen. In meinem Setup sind die folgenden Parameter für das WLAN eingestellt:

  • 5 GHz Band
  • Channel width HE40
  • Security Protokoll WPA-3

Ein nicht ganz fairer Vergleich, da der nanoHD mehr Antennen als der U6 Lite hat und doppelt so teuer ist. Der von der Antennen Anzahl und Preis vergleichbarer UniFi Access Point U6 LR ist aber noch nicht geliefert. Sobald dieser da ist, werde ich auch mit dem Vergleichen.

Um die Access Points zu vergleichen, habe ich diese in meinen UniFi Controller eingebunden, was mit einem klick erledigt war. Einzige Voraussetzung ist, dass der UniFi Controller mindestens die Version 5.14.3 hat und bei mir läuft sogar schon die Version 6.1.71. (Wie man einen UniFi Controller auf einem Ubuntu aktualisiert, erkläre ich im Blogbeitrag Ubiquiti Unifi: Releaseupgrade eines Ubuntu 16.04 auf 18.04 mit einer Mongodb)

Danach habe ich mit Hilfe des Programms NetIO von Kai Uwe Rommel die Netzwerkperformance zwischen zwei MacBook Pro gemessen, die im selben Raum etwa 3 Meter von dem AccessPoint entfernt waren.

Wie man sieht, sind die Wi-Fi 5 Access Points sogar 10% schneller als die neuen Wi-Fi 6. Eventuell liegt das an der größeren Anzahl von Antennen.

kristian@Kristians-MacBook-Pro mac-osx-10.5 % ./osx-10.5-x86_64 -t 192.168.38.64

NETIO - Network Throughput Benchmark, Version 1.31
(C) 1997-2010 Kai Uwe Rommel

TCP connection established.
Packet size  1k bytes:  10.30 MByte/s Tx,  10.63 MByte/s Rx.
Packet size  2k bytes:  10.30 MByte/s Tx,  10.72 MByte/s Rx.
Packet size  4k bytes:  10.69 MByte/s Tx,  10.78 MByte/s Rx.
Packet size  8k bytes:  10.68 MByte/s Tx,  10.76 MByte/s Rx.
Packet size 16k bytes:  10.65 MByte/s Tx,  10.72 MByte/s Rx.
Packet size 32k bytes:  10.81 MByte/s Tx,  10.93 MByte/s Rx.
Done.
kristian@Kristians-MacBook-Pro mac-osx-10.5 % ./osx-10.5-x86_64 -t 192.168.38.64

NETIO - Network Throughput Benchmark, Version 1.31
(C) 1997-2010 Kai Uwe Rommel

TCP connection established.
Packet size  1k bytes:  11.70 MByte/s Tx,  12.51 MByte/s Rx.
Packet size  2k bytes:  11.36 MByte/s Tx,  12.55 MByte/s Rx.
Packet size  4k bytes:  12.14 MByte/s Tx,  13.19 MByte/s Rx.
Packet size  8k bytes:  12.22 MByte/s Tx,  13.12 MByte/s Rx.
Packet size 16k bytes:  12.11 MByte/s Tx,  13.29 MByte/s Rx.
Packet size 32k bytes:  11.85 MByte/s Tx,  13.25 MByte/s Rx.
Done.

Nach dem ersten Test, habe habe ich die Access Points 6 Meter entfernt in den Nebenraum gestellt, 20 WLAN Clients verbunden und erneut getestet. Diesmal war die Geschwindigkeit vergleichbar.

kristian@Kristians-MacBook-Pro mac-osx-10.5 % ./osx-10.5-x86_64 -t 192.168.38.64
 NETIO - Network Throughput Benchmark, Version 1.31
 (C) 1997-2010 Kai Uwe Rommel
 TCP connection established.
 Packet size  1k bytes:  9876.59 KByte/s Tx,  9935.61 KByte/s Rx.
 Packet size  2k bytes:  9846.24 KByte/s Tx,  10.11 MByte/s Rx.
 Packet size  4k bytes:  10.01 MByte/s Tx,  10.11 MByte/s Rx.
 Packet size  8k bytes:  10.18 MByte/s Tx,  10.17 MByte/s Rx.
 Packet size 16k bytes:  10.33 MByte/s Tx,  10.15 MByte/s Rx.
 Packet size 32k bytes:  10.27 MByte/s Tx,  10.12 MByte/s Rx.
 Done.
kristian@Kristians-MacBook-Pro mac-osx-10.5 % ./osx-10.5-x86_64 -t 192.168.38.64

NETIO - Network Throughput Benchmark, Version 1.31
(C) 1997-2010 Kai Uwe Rommel

TCP connection established.
Packet size  1k bytes:  10002.87 KByte/s Tx,  10.17 MByte/s Rx.
Packet size  2k bytes:  10207.72 KByte/s Tx,  9672.17 KByte/s Rx.
Packet size  4k bytes:  10.43 MByte/s Tx,  10.21 MByte/s Rx.
Packet size  8k bytes:  10.49 MByte/s Tx,  9814.45 KByte/s Rx.
Packet size 16k bytes:  10072.42 KByte/s Tx,  9679.28 KByte/s Rx.
Packet size 32k bytes:  10.42 MByte/s Tx,  10.07 MByte/s Rx.
Done.

Fazit

Die Wi-Fi 6 Access Points von Ubiquiti sind bei meinem Setup im ersten Vergleich mit den vorherigen HD Access Points mit Wi-Fi 5 sogar etwas langsamer. Nur bei sehr vielen Geräten können sie ihren Vorteile im Multi-User-MIMO ausspielen. Der Geschwindigkeitsunterschied dürfte auch an der geringeren Antennenanzahl gegenüber den HD Access Points liegen und sollte in der Praxis kaum zu bemerken sein.

Der UniFi Access Point U6 Lite mit Wi-Fi 6 scheint ein ausgereiftes Produkt zu einem fairen Preis zu sein. Er kostet nicht mehr als die Vorgängermodelle. Er dürfte in den meisten Setups aber auch keinen großen Vorteil bringen.

Wenn man bereits gute Wi-Fi 5 Access Points hat, gibt es aktuell kaum Gründe auf Wi-Fi 6 umzusteigen. Sofern man jetzt aber neue Access Points benötigt, würde ich die Modelle mit Wi-Fi 6 kaufen, um zukunftssicherer zu sein und besser mit vielen WLAN Geräten agieren zu können.

Roadwarrior bei OpenVPN anlegen

Das anlegen eines Roadwarrior bei OpenVPN kann auf der Kommandozeile mit wenigen Befehlen erfolgen. Man gibt dazu einfach die folgenden Befehle ein.

cd /etc/openvpn/easy-rsa/
./easyrsa gen-req MaxMustermann
cp pki/private/MaxMustermann.key /etc/openvpn/client-configs/keys/
./easyrsa sign-req client MaxMustermann
cp pki/issued/MaxMustermann.crt /etc/openvpn/client-configs/keys/
cd /etc/openvpn/client-configs/
./make-config.sh MaxMustermann

Danach befindet sich in dem Ordner /etc/openvpn/client-configs/files/ eine Datei mit dem Namen MaxMustermann.ovpn, welche das Zertifikat und und die Konfiguration für den Roadwarrior enthält.

Debug einer IPSec Anbindung auf einer Cisco ASA

Die ASA (Adaptive Security Appliance) Firewalls von Cisco zeigen in der Standardeinstellung nur wenige Meldungen zu einem Aufbau eines IPSec VPN-Tunnels an. Wenn eine solche Verbindung nach der Einrichtung nicht funktioniert, kann es jedoch sinnvoll sein den Loglevel zu erhöhen und alle Meldungen anzuzeigen. Damit im Anschluss nicht zu viele Meldungen angezeigt werden, sollten die Meldungen vorher aber auf einen bestimmten IPSec VPN-Tunnel beschränkt werden. 

Beispiel

Gehen wir zum Beispiel mal davon aus, dass die Phase 1 bei einer IPSec Verbindung nicht aufgebaut wird und bei dieser das Protokoll IKEv2 verwendet wird.

Mit den folgenden drei Befehlen bringt man die Konsole der Cisco ASA dazu nur noch die Meldungen für den VPN-Tunnel zu der angegebenen IP-Adresse anzuzeigen und schaltet das höchste Loglevel für IKEv2 ein. Danach werden alle Meldungen zu dem Aufbau der Phase 1 des IPSec Tunnels zu der angegebenen IP-Adresse auf der Konsole angezeigt.

debug crypto condition peer <ip adresse>
debug crypto ikev2 protocol 255
debug crypto ikev2 platform 255

IPv6 auf einem Ubuntu 18.04 Server deaktivieren

Selbst in der heutigen Zeit bereiten Server die sowohl eine IPv4 als auch eine IPv6 Adresse haben manchmal Probleme. Deshalb kann es nützlich sein, wenn man die IPv6 Adressen eines Server komplett deaktiviert. Bei Ubuntu 18.04 LTS geht das wie folgt.

Man legt die Datei /etc/sysctl.d/01-disable-ipv6.conf mit dem folgenden Inhalt an und startet den Server hinterher neu.

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Test einer Synology DS416play mit DSM 6.1

Synology DS416play

Die taiwanische Firma Synology wurde im Jahr 2000 von den ehemaligen Microsoft Managern Cheen Liao und Philip Wong gegründet und hat sich zum Ziel gesetzt Network Attached Storage-Geräten (kurz NAS) mit umfangreicher Software auf Basis von Linux zu bauen. Dabei nennt Synology die Hardware DS (DiskStation) und die Software DSM (DiskStation Manager).

Als ich vor 10 Jahren die ersten NAS (Network Attached Storage) Geräte von Synology eingerichtet habe, war ich bereits überrascht wir groß der Funktionsumfang der Software und die Anpassungsmöglichkeiten dieser Geräte waren. Man merkte den Geräten aber an, dass sie eher für kleinere Firmen und den privaten Gebrauch gebaut wurden. Für den Einsatz in großen Firmennetzen waren sie noch nicht reif.

Inzwischen hatte ich einige Jahre keine Synology mehr in der Hand und es wurde höchste Zeit, sich so ein Gerät mit der aktuellen Software mal wieder näher anzuschauen. Als zudem noch mein Speicherplatz für das Backup meiner privaten Daten knapp wurde, beschoss ich mir ein aktuelles NAS der Firma Synology zuzulegen und dieses genauestens unter die Lupe zu nehmen.

Welches NAS von Synology ist für mich das beste?
Zunächst stellte sich die Frage, welches der aktuellen NAS-Geräte von Synology am ehesten für meine Bedürfnissen passt. Synology bietet inzwischen über 20 unterschiedliche NAS Geräte an, die für verschiedenste Einsatzzwecke ausgelegt sind. Es gibt sowohl für den Privatanwender als auch für Firmen verschiedener Größenordnungen passende Geräte zu finden. Für mich persönlich war eine große Speicherkapazität und ein geringer Stromverbrauch wichtig. Außerdem wollte ich gerne eine etwas leistungsfähigere CPU, um 4k Videos von dem NAS auf den Fernseher übertragen zu können. Nach einer Recherche im Internet entschied ich mich für das Model DS416play welches es aktuell bei Amazon für 442,19- € gibt. Es kann mit vier Platten bestückt werden und bringt eine etwas leistungsstärkere CPU mit. Mit vier Festplatten mit einer Größe von 4 TB und der Verwendung eines RAID (Redundant Array of Independent Disks) mit einer Festplatte für Redundanz erhält man über 10 TB Speicherplatz. Für meine privaten Zwecke ist das zunächst ausreichend. Zudem reicht die CPU der DS416play, um 4k Videos zum Fernseher zu übertragen.

Zusammenbauen und einrichten
Das zusammenbauen und einrichten des NAS ist für jemanden mit Computerkenntnissen schnell erledigt. Die Festplatten können ohne Schrauben eingebaut werden. Sobald man das Gerät anschaltet, holt es sich eine IP-Adresse per DHCP und ist über die URL http://diskstation:5000 erreichbar. Wenn man diese URL im Browser aufruft, landet man auf dem Desktop des DSM (DiskStation Managers). Dort kann man in der Systemsteuerung die Konfiguration des Gerätes vornehmen. Die vier von mir verbauten Festplatten hatte das NAS bereits automatisch zu einem SHR1 (Synology Hybrid RAID) zusammengefasst. Bei Bedarf kann das NAS natürlich auch andere RAID-Arten. Das SHR1 dürfte für die meisten aber auch das geeignetste RAID sein, da es am flexibelsten ist. Danach ist das Gerät prinzipiell einsatzbereit. Es gibt natürlich noch haufenweise kostenlose und kostenpflichtige Zusatzsoftware, die man über das sogenannte „Paket-Zentrum“ installieren kann. Ähnlich wie bei einem iPhone, ist das NAS damit nach Bedarf erweiterbar und kann zu einem kleinen Server mit diversen Funktionalitäten ausgebaut werden.

Fazit
Die NAS Systeme von Synology sind extrem erweiterbar, haben ein sehr gutes Preis-Leistung-Verhältnis und sind fast schon kleine Applikationsserver mit diversen Funktionen. Für den privaten Gebrauch und für kleine Firmen sind sie völlig ausreichend und mehr Leistung und mehr Funktionen sind für das Geld nicht zu bekommen. Ich kann diese Geräte sehr empfehlen.

Wenn man möchte gibts die Synology DS416play bei Amazon auch bereits bestückt mit Festplatten. Die Variante mit 12 TB Speicherplatz kostet bei Amazon aktuell z.B. gerade 995,- €.

Wenn Server nach einem Neustart die Netzwerkkarten vertauscht haben

Ich hatte letztlich das Problem, dass sich Netzwerkkarten bei Linux und Windows nach einem Neustart immer wieder vertauschten. Da die Server dadurch über Netzwerk nicht mehr erreichbar sind und ausfallen, ist das natürlich sehr ärgerlich. Da ich jetzt gerade eine neuen Firewall auf Basis von Ubuntu Linux mit 9 Netzwerkkarten und 100 VPN-Tunneln eingerichtet habe, wollte ich das Problem auf jeden Fall verhindern. Deshalb habe ich das Problem noch mal genauer untersuch und viel Doku dazu gelesen. Jetzt ist mir klar warum das Problem auftritt und ich kann es zukünftig verhindern.

Ursache: Da die Betriebssysteme zum schnellen Booten alles parallel starten, kommt es beim Booten regelmäßig dazu, dass die Hardwaretreiber in anderer Reihenfolge geladen werden. Wenn man im Server zwei Netzwerkkarten mit unterschiedlichen Treibern hat, kann dabei die Reihenfolge vertauscht werden, in der die Treiber geladen werden. Da bei älteren Windows- und Linuxservern die Netzwerkkarten einfach nur anhand der Startreihenfolge durchnummeriert werden, kann es somit vorkommen, dass die IP-Konfiguratiuonen der Karten durcheinander gewürfelt werden.

Lösung bei neueren Betriebssystemen: Bei neueren Betriebssystemen wird das Vertauschen der Karten verhindert. Windows merkt sich inzwischen für welche Karte eine Konfiguration war und zählt bei neuen Karten einfach immer weiter hoch. Es bindet (vermutlich anhand der Mac-Adresse oder Seriennummer) die Konfiguration fest an eine Netzwerkkarte und vergibt eine bereits vergebene Nummer kein zweites mal. Deshalb hat man bei Windows auch machmal einen Netzwerkadapter 5 oder 6, obwohl aktuell nur eine Karte im Betriebssystem steckt. Bei Linux wird der Steckplatz der Karte mit in den Namen der Netzwerkkarte aufgenommen. Eine Netzwerkkarte auf PCI-Slot 2 heißt dann z.B. p2p1, wobei das p2 dann für den PCI-Slot 2 und das p1 für den ersten Port der Karte steht. Theoretisch kann man bei Linux also eine neue Karte in den gleichen Slot stecken und die Konfiguration sollte noch funktionieren.

Das Tunneln von X11 über SSH bei Ubuntu 14.04 geht nicht

Zu meiner Überraschung funktionierte das Tunneln von X11 über ssh auf einem Ubuntu 14.04 Server nicht mehr. Schon beim Login über den Befehl

ssh -X <Hostname>

gibt es den Fehler „X11 forwarding request failed on channel 0“,
obwohl in der /etc/ssh/sshd_config der Eintrag „X11Forwarding yes“ gesetzt ist.

Auch eine Installation der der XServer Utils

apt-get install x11-xserver-utils

brachte keine Lösung und nicht einmal xclock lief.

Nach ein bisschen Suchen stellt ich fest, dass das Paket xauth fehlt. Wenn man dieses nachinstalliert funktioniert auch das Tunneln von X11 über SSH wieder.

apt-get install xauth

VPN-Anbindung eines Internetservers mit strongSwan 4.2

Bei mir kommt es immer häufiger vor, dass ein Webserver Zugriff auf sensible Dienste eines Servers im internen Netzwerk erhalten soll. Um diesen Zugriff so sicher wie möglich zu gestallten, sollte die dazu notwendige Netzwerkverbindung verschlüsselt werden. Also muss eine VPN-Verbindung her.

Bei Linux-Servern kann man diese Verbindung ganz einfach mit der Software strongSwan einrichten. Bei den meisten Linux-Distributionen ist das dazu nötige Paket enthalten und schnell installiert. Bei Ubuntu 12.04 geht dies z.B. ganz einfach mit dem folgenden Befehl:

sudo apt-get install strongswan

Um die software einzurichten ist noch ein geheimes Kennwort für den Verbindungsaufbau und eine Konfiguration für die VPN-Verbindung notwendig. Das Kennwort wird in der Datei /etc/ipsec.secrets festgelegt. Wenn der Internetserver die IP 144.133.122.111 und die Firewall des internen Netzwerkes die IP 143.132.121.110 hat, müsste die Datei die folgende Zeile beinhalten (das Kennwort sollte natürlich anders sein):

144.133.122.111 143.132.121.110 : PSK 'HierKommtEinGeheimesLangesKennwortHin'

Die Konfiguration der VPN-Verbindung erfolgt in der Datei /etc/ipsec.conf. Für eine Verbindung mit dem Namen InternesNetzwerk kommt der folgende Abschnitt in die Datei:

conn InternesNetzwerk
        left=144.133.122.111
        leftsubnet=144.133.122.111/255.255.255.255
        right=143.132.121.110
        rightsubnet=172.30.4.0/255.255.255.0
        leftid="144.133.122.111"
        rightid="143.132.121.110"
        ike=aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3des-md5-modp1024
        esp=aes128-sha1,aes128-md5,3des-sha1,3des-md5
        ikelifetime=1h
        keylife=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        pfs=yes
        authby=secret
        auto=start
	keyexchange="ikev1"

Bei der Verbindung werden die zuvor schon genannten IP-Adressen von Webserver und Firewall verwendet. Ferner ist ein interner IP-Bereich 172.30.4.0/24 für das interne Netzwerk konfiguriert. Für die IPSec Verbindung wurde IKE in der Version 1, Dead Peer Detektion, Perfect Forward Seurity und einige andere übliche Einstellungen gesetzt. All diese Einstellungen müssen natürlich den jeweiligen Gegebenheiten angepasst werden. Außerdem müssen die IPSec Parameter denen der Firewall entsprechen.

Wenn auch die Firewall auf der Gegenseite eingerichtet ist, lässt sich die Konfiguration durch einen Neustart von strongSwan bzw. IPSec aktivieren.

sudo /etc/init.d/ipsec restart

Danach kann man sich mit dem Befehl

sudo ip xfrm state

oder dem Befehl

sudo ip xfrm policy

anzeigen lassen, ob ein Tunnel zustande gekommen ist. Eventuelle Fehlermeldungen sind wie immer in der Datei /var/log/syslog zu finden. Wenn man die letzen 50 Zeilen anzeigen lassen möchte also einfach den folgenden Befehlt eingeben:

tail /var/log/syslog -n 50

Windows Ereignis-ID 50: Time-Service Zeitdifferenz von mehr als 5000

Wenn ein Windows-Server eine Zeitdifferenz von mehr als 5000 auf 900 Sekunden feststellt, wird die Synchronisation der Systemzeit angehalten und der Server gibt selber keine Zeiten mehr raus. Dies kann z.B. durch eine schlechte Netzwerkanbindung oder eine defekte Hardwareuhr kommen. Um in diesem Fall die Synchronisation wieder zu aktivieren, gibt man auf der Kommandozeile den folgenden Befehl ein:

W32TM /resync

Ob die Zeit wieder synchronisiert wird kann man sich dann mit dem folgenden Befehl anschauen:

W32TM /query /status