Nachdem nun dieses Thema in den Medien so hochgekocht ist und auch der letzte Facebooknutzer mitbekommen hat das seine Daten nicht „privat“ sind *lach*. Kommen in der letzten Zeit vermehrt Fragen zu Verschlüsselung bei mir an. Egal ob Kunden auf der Arbeit, Bekannte vom Stammtisch oder irgendwer aus dem Internet! Zwar hat noch immer keiner etwas zu verbergen, zumindest nicht wirklich, also nur das mit den Filmen und den mp3s und den Spielen und und und….. Darum geht es ja aber nicht, denn plötzlich scheint es doch nicht mehr jeden etwas anzugehen, welche Nachrichten, E-Mails oder Bilder sie verschicken. Bla bla bla bla… War da nicht etwas mit einem Frosch der aus kochendem Wasser springt, wenn man ihn aber im Wasser erwärmt sitzen bleibt bis er tot ist? Ich habe es noch nie probiert, will es auch nicht… Der Punkt ist denn noch klar, oder? Da rennt man Jahrelang herum und predigt was das Zeug hält und nix is. Ein paar Leute sind stinkig, einige machen sich Gedanken über Verschlüsselung aber in 1 – 2 Monaten interessiert sich kein Mensch mehr dafür und alle verschicken weiterhin ihre Postkarten. Man hat ja nichts zu verbergen und wenn, soll doch so ein Agent von der NSA oder BSI oder sonst einem Verein die Urlaubsbilder sehen, richtig? *ironie alarm* Na, was soll es? Die Aluhüte mussten ihren Vorrat an Clinex und Handcreme aufstocken *i told you so* und wir sind alle noch ein kleines Bisschen mehr abgestumpft. Dann kann die nächste Welle der Empörung ja kommen.
Mal eine Frage inkl. Antwort aus dem Alltag: „Welches RIPE Handel beinhaltet noch gleich den technischen Ansprechpartner für das IP-Netz hinter dem Domainnamen xyz?“ Ein Einzeiler in der Bash hilft:
whois besorgt die Informationen für die IPv4 Adresse, welche sich aus dem Befehl: „dig www.kernel-error.de +short“ ergibt. „grep tech-c:“ fischt die Zeilen aus dem whois, welche tech-c: enthalten und „uniq“ sorgt dafür das jede Zeile nur einmal ausgegeben wird.
Veraltet: StartSSL wurde 2017 von allen Browsern als nicht vertrauenswürdig eingestuft und eingestellt. Kostenlose Zertifikate gibt es bei Let’s Encrypt.
Na wunderbar, mein Class 2 x.509 S/MIME Zertifikat läuft in kürze aus. Die Class 2 Validation ist auch ausgelaufen, also muss ich wohl was tun, hm?
Schnell alles bei StartSSL angeschoben und auf den bekannten Anruf irgendwo aus Israel warten… Es klingelte auch aber aus 001 213-341. Die Landesvorwahl ist USA und mein Android meint der Rest wäre etwas aus Los Angeles, CA! Das hat mich etwas überrascht; whatever. Wie gewohnt war das Gespräch schnell erledigt. Wobei die Dame am anderen Ende der Leitung extrem schlecht zu verstehen war. Nun warte ich also auf die Bestätigung meiner Class 2 Zertifizierung.
*UPDATE*
Na wunderbar:
### Schnipp ### To Sebastian Van De Meer,
This electronic mail message was created by StartCom’s Administration Personnel:
Congratulations! Your Class 2 Identity Validation has been confirmed and approved. You are eligible for certificates at Class 2 level until 2014-05-01. Additionally you have been awarded with StartSSL™ Web-of-Trust Notary status due to your fulfilling of all requirements. Well done!
Best Regards ### Schnapp ###
Dann kann ich ja gleich mal von diesem Zertifikat:
Man man man… Da bittet ein Kollege um ein Zertifikat, ich schraube das schnell zusammen und schiebe es im als .PEM – Base64-kodiertes Zertifikat, umschlossen von „—–BEGIN CERTIFICATE—–“ und „—–END CERTIFICATE—–“ zu.
Nun versucht dieser das Zertifikat auf seinem Windows Server zu importieren. Klappt aber so einfach nicht. Microsoft hätte nämlich gerne das Zertifikat als .PFX (.P12 – PKCS#12, kann öffentliche Zertifikate und private Schlüssel (Kennwort-geschützt) enthalten.) Macht ja auch Sinn wenn es eh in einer Zertifikatsverwaltung liegt und dass ganze Kennwortgeschützt ist. So ist es etwas sicherer, wenn die Datei mal jemanden in die Hände fällt, der es nicht haben soll!
Wie also nun aus PEM ein PFX machen? Openssl hilft:
telefon.de.key sowie telefon.de.crt sollten wir beim einfachen erstellen des Zertifikates per Openssl ja bereits haben. CACert.crt ist einfach der Zertifikat der CA, mit welchem unsere CSR unterschrieben wurde. Noch Fragen?
Vor einiger Zeit ist mir ein Buch mit dem Titel „Kabelsalat: Wie ich einem kaputten Kabel folgte und das Innere des Internets entdeckte“ empfohlen worden. Klang spannend, also bestellt. So eine Bestellung ist ja schnell gemacht, das Lesen dauert dann doch länger.
Inzwischen habe ich es durch und finde: nicht schlecht. Das Buch ist nicht so technisch, dass man es nicht versteht. Ich glaube selbst meine Mutter könnte es ohne Probleme lesen. Genau das ist aber auch der Punkt — wenn man sich für das Thema nicht interessiert, ist es trotzdem nichts. Wenn man wissen will, wie das Internet wirklich aussieht, sollte man es unbedingt lesen.
Wer ist Andrew Blum?
Andrew Blum ist Journalist und schreibt unter anderem für Wired und die New York Times. Der Anlass für das Buch war ziemlich banal: in seinem Garten in Brooklyn fing ein Eichhörnchen an, ein Kabel anzunagen. Sein Internet wurde langsam und immer wieder gestört. Beim Versuch zu verstehen, wo dieses Kabel eigentlich hinführt, stellte er fest, dass er keine Ahnung hat, wie das Internet physisch aufgebaut ist. Aus dieser Frage wurde dann eine Reise und am Ende ein Buch. Das Original heißt „Tubes: A Journey to the Center of the Internet“ und ist 2012 erschienen, die deutsche Übersetzung kam ein Jahr später im Heyne Verlag.
Was steckt drin?
Blum besucht die Orte, an denen das Internet tatsächlich existiert. Und das sind nicht „die Cloud“ oder „irgendwo im Netz“, sondern sehr konkrete Gebäude mit sehr konkreten Stromanschlüssen. Ein paar Stationen aus dem Buch:
DE-CIX in Frankfurt — einer der größten Internet-Knoten der Welt, in dem ein Großteil des europäischen Traffics zusammenläuft
MAE-East in Ashburn (Virginia) und das Equinix-Cluster drumherum, wo gefühlt das halbe US-Internet seine Pakete austauscht
Pionen, der ehemalige Atombunker in Stockholm, in dem damals unter anderem Bahnhof seine Server stehen hatte (auch Wikileaks war dort einquartiert)
Cornwall, wo Transatlantik-Glasfasern an Land kommen — inklusive der Verlegeschiffe, die das Zeug über tausende Kilometer auf den Meeresboden bringen
The Dalles in Oregon, wo Google eines seiner ersten großen Rechenzentren am billigen Strom des Columbia River gebaut hat
Blum erklärt dabei nebenbei, wie Peering überhaupt funktioniert, was ein Tier-1-Carrier ist, warum Glasfaserverbindungen genau so verlaufen, wie sie verlaufen, und wer diese ganze Infrastruktur eigentlich besitzt. Das Tempo ist dabei eher Reisereportage als Lehrbuch — wer schon BGP-Sessions konfiguriert hat, lernt fachlich nicht viel Neues, bekommt aber viele Geschichten zu Orten und Menschen, die hinter den abstrakten Begriffen stecken.
Update 2026: Was hat sich seit 2012 geändert?
Das Buch ist inzwischen über zehn Jahre alt. Die Grundstrukturen stehen noch genauso und an vielen Stellen hat sich die Logik sogar verfestigt, an ein paar Punkten ist die Realität aber weitergezogen:
Hyperscaler-Konzentration: AWS, Google, Microsoft und Meta betreiben mittlerweile eigene Backbones rund um die Welt und legen sogar eigene Seekabel. Was Blum bei Google in Oregon noch als Ausnahme beschreibt, ist heute Standard.
Submarine-Cable-Sabotage: Die Verletzlichkeit von Seekabeln war 2012 eher Theorie. Seit den Vorfällen in der Ostsee 2023/2024 reden auch Politik und Medien drüber.
RPKI und BGP-Hijacks: Routing-Sicherheit war im Buch nur am Rande Thema. Heute haben große Provider RPKI-Validierung eingeschaltet, und trotzdem gibt es regelmäßig Routenleaks. Wer mehr will, schaut bei bgp.tools oder im eigenen BGP-Beitrag vorbei.
Satelliten-Internet: Starlink, Kuiper und Co. haben einen Teil der Infrastruktur über die Wolkendecke verlagert. Das Buch endet noch mit dem Bild „alles läuft durch Glasfasern“. Stimmt nicht mehr ganz.
Datacenter-Strom: Was bei Blum als „günstiger Wasserkraftstrom in Oregon“ auftaucht, ist heute eines der Hauptthemen der Branche — Datacenter sind in vielen Regionen zur Belastung für das Stromnetz geworden.
Lohnt sich das Buch heute noch?
Ja, mit Einschränkungen. Wer das Internet nur als Cloud-Symbol auf einer Powerpoint-Folie kennt, dem öffnet das Buch die Augen. Wer schon mal in einem Rechenzentrum stand oder selbst Peering verhandelt hat, wird gelegentlich schmunzeln und sich bei den Reisebeschreibungen wiederfinden. Auf jeden Fall lesbar, nicht zu lang, gut geschrieben — und nach den 250 Seiten weiß man, warum „die Cloud“ eben doch ein paar sehr konkrete Adressen hat.
Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Alternativen: Proxmox VE oder XCP-ng.
Möchte man bei seinem Citrix Xen Server bestimmte Kernelmodule automatisch beim Booten laden, hilft folgendes.
Einfach unter /etc/sysconfig/modules/ ein passendes Konfigurationsfile für das Module anlegen und es ausführbar machen. Ich habe hier ein Beispiel für die IPMI Module:
Veraltet: Dieser Beitrag bezieht sich auf IPv6 Neighbor Discovery unter Solaris/OpenIndiana. Das Konzept (NDP statt ARP) gilt weiterhin, die gezeigten Befehle sind aber Solaris-spezifisch. Unter Linux: ip -6 neigh show.
Damit IPv4 im Ethernet funktioniert braucht man das ARP (Address Resolution Protocol) als Unterbau. Denn sonst würden die IPv4 Pakete ja ihren Weg nicht zur richtigen Netzwerkkarte finden. ARP und IPv4 sind dabei völlig unabhängige Protokolle, sie arbeiten nur seit Jahrzenhten Hand in Hand. Das vergessen viele schnell.
Möchte man also nun herausfinden welche MAC Adresse das System (im gleichen Ethernet-Netzwerk) hat, mit welchem man sich gerade unterhält… Ja, dann bemüht man das ARP.
Unter Linux:
$ arp
Address HWtype HWaddress Flags Mask Iface
errorgrab.kernel-error. ether 00:ff:c9:05:01:c7 C enp2s0
wurstsuppe.kernel-error. ether 50:ff:5d:85:73:48 C enp2s0
Unter Openindiana/Solaris 11:
$ arp -a
Net to Media Table: IPv4
Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- -------- ---------------
rge0 router.kernel-error 255.255.255.255 00:ff:42:72:2b:a6
rge0 192.168.1.31 255.255.255.255 00:ff:b0:ae:0b:eb
rge0 sebastian-solaris.kernel-error 255.255.255.255 SPLA 80:ff:73:4a:38:c7
rge0 all-routers.mcast.net 255.255.255.255 S 01:ff:5e:00:00:02
Bei IPv6 schaut es nun etwas anders aus. Man könnte sagen, hier wurde ARP direkt mit in IPv6 integriert. Es findet sich im Neighbor Discovery wieder. Möchte man hier seine „Nachbarn“ sehen klappt es so:
Unter Linux:
$ ip -6 neigh show
fe80::1 dev enp2s0 lladdr 50:ff:5d:85:73:48 router STALE
fe80::2ff:c9ff:fe05:1c7 dev enp2s0 lladdr 00:ff:c9:05:01:c7 router REACHABLE
Unter Openindiana/Solaris 11:
$ netstat -pf inet6
Net to Media Table: IPv6
If Physical Address Type State Destination/Mask
----- ----------------- ------- ------------ ---------------------------
rge0 33:33:ff:00:00:01 other REACHABLE ff02::1:ff00:1
rge0 00:ff:42:72:2b:a6 dynamic REACHABLE router.kernel-error
rge0 33:33:00:00:00:01 other REACHABLE ff02::1
rge0 33:33:00:01:00:02 other REACHABLE ff02::1:2
rge0 33:33:ff:00:00:06 other REACHABLE ff02::1:ff00:6
rge0 33:33:ff:10:98:82 other REACHABLE ff02::1:ff10:9882
rge0 33:33:ff:ad:7a:dd other REACHABLE ff02::1:ffad:7add
rge0 33:33:ff:00:00:11 other REACHABLE ff02::1:ff00:11
rge0 33:33:00:00:00:16 other REACHABLE ff02::16
rge0 46:ff:91:30:98:3d dynamic REACHABLE 2001:7d8:8001:0:ffff:bdb9:6810:9882
rge0 80:ff:73:4a:38:c7 local REACHABLE sebastian-solaris.kernel-error
rge0 80:ff:73:4a:38:c7 local REACHABLE fe80::ffff:73ff:fe4a:38c7
rge0 00:ff:42:72:2b:a6 dynamic REACHABLE fe80::fff:42ff:fe72:2ba6
rge0 33:33:ff:4a:38:c7 other REACHABLE ff02::1:ff4a:38c7
Früher war es mit dem ARP „einfacher“. Zumindest musste man sich nur einen Befehl merken und dann halt die für das jeweilige Betriebsystem nötigen Schalter herausfinden. Mit IPv6 ist es nun mit in die jeweiligen IP-Tools gewandert. Ich halte es für sauberer auch wenn man sich nun nicht mehr mit den Befehlt „arp“ behelfen kann.
BSD und ihre Ableger nutzen „ndp„. Bei Linux verschwindet alles in den iproute2-Tools mit dem Befehl: „ip“ (ifconfig, route, usw. usw…. alles im Tool ip) Microsoft wirft alles in „netsh„. Unixbasierendes hält sich ans gute alte „netstat„.
Veraltet: Solaris und OpenIndiana werden kaum noch eingesetzt. Unter Linux: ip link show, unter FreeBSD: ifconfig.
Es ändert sich im Laufe der Zeit ja mal immer wieder etwas. So auch der Weg mit Netzwerkkarten umzugehen unter Solaris. Wer also gerade versucht die MAC Adresse seiner lokalen Netzwerkkarte / NIC herauszufinden, dem wird folgender Command helfen:
Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Alternativen: Proxmox VE oder XCP-ng.
Hin und wieder bleibt beim Herunterfahren eine VM irgendwie hängen. Dann hat man über das XenCenter keine Möglichkeit mehr diese VM zum Leben zu erwecken. Damit man nun nicht den kompletten VM-Host dom0 neustarten muss, kann man erst folgenden Weg probieren.
Als erstes kann man einen force shutdown der vm probieren:
$ xe vm-shutdown –force vm=“VM-NAME“
Wenn es nicht hilft, kann man versuchen die “wartenden” pending Prozesse am XenServer zu killen:
$ xe task-list
Dann die Prozesse abbrechen welche den Shutdown zu verhindern scheinen:
$ xe task-cancel uuid=“TASK-UUID“
Bringt das alles nichts kann man als letztes noch folgendes probieren:
$ xe-toolstack-restart
Nun kann man noch einmal einen force shutdown probieren. Klappt es auch nicht, muss man wohl doch den VM-Host durchstarten!