IT-Blog von Sebastian van de Meer

Schlagwort: Linux (Seite 4 von 8)

Ping6 funktioniert nicht auf fe80-Adresse: Fehlerbehebung

Ja, die liebe fe80 Adressen! Wer schon mal ganz unbedarft folgendes in seine Konsole hämmert:

$ ping6 fe80::20c:42ff:fe72:2ba6
connect: Invalid argument

Wundert sich sicher im ersten Moment über die freche Antwort: „connect: Invalid argument“. ABER das ist absolut richtig. Denn wenn man mehrere Netzwerkkarten in seinem Rechner verbastelt hat, dann hat man ebenfalls mehrere fe80 link local Adressen. Nämlich mindestens eine pro Netzwerkkarte. Damit sollte es jetzt schon klingeln, hm? Noch nicht? Na woher soll das Paket den bitte wissen über welche der Netzwerkkarten es denn den Weg zur angepingten Adresse nehmen soll?!?!? Genau überhaupt nicht! Daher muss das Interface welches als „Ausgang“ genutzt werden soll immer mit angegeben werden.

$ ping6 fe80::20c:42ff:fe72:2ba6%eth0
PING fe80::20c:42ff:fe72:2ba6%eth0(fe80::20c:42ff:fe72:2ba6) 56 data bytes
64 bytes from fe80::20c:42ff:fe72:2ba6: icmp_seq=1 ttl=64 time=0.323 ms
--- fe80::20c:42ff:fe72:2ba6%eth0 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.323/0.323/0.323/0.000 ms

Unter Linux gibt man einfach %NIC-Name an und unter Windows einfach %NIC-ID:

C:\>ping -6 fe80::20c:42ff:fe72:2ba6%3

Ping wird ausgeführt für fe80::20c:42ff:fe72:2ba6%3 mit 32 Bytes Daten:
Antwort von fe80::20c:42ff:fe72:2ba6%3: Zeit<1ms
Antwort von fe80::20c:42ff:fe72:2ba6%3: Zeit<1ms

Ping-Statistik für fe80::20c:42ff:fe72:2ba6%3:
Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

C:\>

Wobei ich die Meldung eines Microsoft Windows doch schnell etwas verwirrend finde. Denn hier gibt es nur die Rückmeldung dass das Zielnetz nicht erreichbar ist. Was ja im Grunde korrekt ist, nur grenzt es leider den Fehler nicht so schön ein!

C:\>ping -6 fe80::20c:42ff:fe72:2ba6

Ping wird ausgeführt für fe80::20c:42ff:fe72:2ba6 mit 32 Bytes Daten:

Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.
Zielnetz nicht erreichbar.

Ping-Statistik für fe80::20c:42ff:fe72:2ba6:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),

C:\>

Japp, so einfach kann es sein.

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

ClamAV unter Sabayon Linux mit systemd installieren und einrichten​

Veraltet: Sabayon Linux wurde 2020 eingestellt. ClamAV lässt sich unter jedem aktuellen Linux problemlos installieren.

Ich sitze hier gerade vor einem Sabayon mit XFCE und wundere mich darüber dass der ClamAV nicht nach der Installation „out of the Box“ funktioniert.

Folgende kurze Schritte sind nötig damit er bei mir die Basisarbeit in aktueller Form aufnimmt.

$ equo install app-antivirus/clamav
$ cp /etc/freshclam.conf.sample /etc/freshclam.conf
$ systemctl enable freshclamd.service
$ systemctl enable clamd.service
$ systemctl start freshclamd.service
$ systemctl start clamd.service

So long…

Solaris 11 Shut Down / Herunterfahren Terminal

Veraltet: Solaris 11 und OpenIndiana werden kaum noch eingesetzt. Unter FreeBSD lautet der Befehl shutdown -p now, unter Linux systemctl poweroff.

Ich habe heute einen Anruf eines befreundeten Sysadmins bekommen. Der arme muss darf heute bei einem seiner Kunden den Serveraum umziehen… Dafür möchte er nun die Systeme abschalten. Jetzt steht dort ein Solaris 11 System und der zum System gehörende Admin ist krank (zufällig am Feiertag des Serverraumumzuges…)! Jetzt steht mein Bekannter also vor der Konsole und will die Kiste im Grunde nur abschalten. Folgendes Gespräch ergab sich:

Bekannter: init 0 geht nicht, beim shutdown -h now soll -h eine unknown option sein. Ich bin genervt… Wie geht das aus?
Ich: Solaris 11 im poduktiveinsatz? Dann habt ihr auch Support von Oracle; anrufen / chatte die helfen immer sofort.
Bekannter: Laber nicht rum, ich bin hier für die Microsoft Maschinen. Keine Ahnung wo ich weh anrufen kann. Du kannst das doch, oder?
Ich: Joar… Folgendes sollte dir helfen:

$ shutdown -y -i5 -g0

Bekanter: *Klacker Tipper*
Ich: Root Konsole hattest du schon oder?
Bekannter: *Klacker* japp *Klacker*
Ich: shutdown ist shutdown, -y ist damit du nicht gefragt wirst -i5 ist um die Kiste nach dem Shutdown auch aus zu machen und -g0 ist das es unverzüglich gemacht wird.
Bekannter: Warum ist das so kompliziert? Geht das nicht einfacher? Bei Linux ist das doch einfach shutdown -h now… Man… Ich will eine Maus! Ahh ich glaube er fährt runter!
Ich: Du hättest mit man shutdown den korrekten Befehl erlesen können.
Bekannter: Ach, das muss einfacher gehen!
Ich: Ok dann nimmer das nächste mal den Befehl poweroff
Bekannter: Du Sack! Danke..

Ich finde es schon sinnvoll unterschiedliche Arten eines shutdown zu haben. Vor allem mit verschiedenen Arten der Signalisierung.

IPv6 ICMP Redirect erklärt: „rt6_redirect: source isn’t a valid nexthop“

Man stolpert irgendwann über diese Meldung im Kernel-Log:

rt6_redirect: source isn't a valid nexthop for redirect target
Illustration eines IPv6-Netzwerks mit Kernel-Logmeldung „rt6_redirect: source isn't a valid nexthop for redirect target“. Ein ICMPv6-Redirect verweist fälschlich von einer Link-Local-Adresse auf eine globale IPv6-Adresse als Next Hop, was vom System abgelehnt wird.

Gerne im Zusammenhang mit IPv6, gerne dann, wenn man glaubt, eigentlich alles richtig gemacht zu haben. Routing stimmt. Neighbors sehen gut aus. Und trotzdem meckert der Kernel.

Die Kurzfassung: Der Linux-Kernel hat ein ICMPv6 Redirect bekommen und lehnt es ab, weil der vorgeschlagene Next Hop aus seiner Sicht kein gültiger First Hop ist.

Worum geht es überhaupt?

ICMPv6 Redirects (Typ 137) sind Teil von Neighbor Discovery. Ein Router sagt damit zu einem Host sinngemäß:

„Für dieses Ziel gibt es einen besseren ersten Hop als mich.“

Wichtig: erster Hop. Nicht irgendein Router irgendwo, sondern ein direkt erreichbarer Nachbar auf dem Link.

Ein Redirect enthält deshalb zwei zentrale Informationen:

  • das Target (Zieladresse, für die das Redirect gilt)
  • den Better Next Hop

Und jetzt kommt der Teil, den viele Implementierungen (und Admins) gerne unterschätzen:
Der Host muss diesem Vorschlag nicht glauben.

Was Linux hier tatsächlich prüft

Linux ist bei Redirects ziemlich streng. Zu Recht. Redirects sind ein beliebtes Einfallstor für Unsinn und Angriffe.

Bevor der Kernel ein Redirect akzeptiert, prüft er u. a.:

  • stammt das Redirect von einem Router, den ich bereits als Router kenne?
  • liegt der vorgeschlagene Next Hop auf demselben Link?
  • ist dieser Next Hop als Neighbor bekannt bzw. grundsätzlich auflösbar?
  • passt das Ganze zur bestehenden Routing-Entscheidung?

Und genau hier schlägt diese Logmeldung zu.

Der Kernel schaut auf den Better Next Hop im Redirect und stellt fest:

„Diese Adresse kann für dieses Ziel kein gültiger Next Hop sein.“

Dann wird das Redirect verworfen. Keine neue Route. Kein Update. Nur diese Meldung.

Der Klassiker: Global statt Link-Local

In der Praxis sieht man das oft in Setups, in denen Router ihre Default-Route oder interne Routen nicht sauber über Link-Local-Adressen aufbauen.

Beispiel (vereinfacht):

default via 2001:db8:1::1 dev eth0

Sieht harmlos aus. Funktioniert auch meistens. Aber:
IPv6 erwartet, dass Router auf einem Link über ihre Link-Local-Adresse angesprochen werden.

Korrekt wäre also eher:

default via fe80::1 dev eth0

Was passiert nun?

Der Router verschickt ein Redirect und trägt als „Better Next Hop“ seine globale Adresse ein (z. B. 2001:db8:1::1).
Der Host bekommt das Redirect, prüft es – und sagt:

„Moment. Dieser Next Hop ist kein gültiger direkt erreichbarer Neighbor für dieses Ziel.“

Und genau dann landet diese Meldung im Log.

Wichtig:
Das Problem ist nicht primär, dass die Adresse global ist.
Das Problem ist, dass der Kernel den vorgeschlagenen Next Hop nicht als legitimen First Hop auf diesem Link akzeptiert.

Link-Local ist der Normalfall. Alles andere muss extrem gut begründet sein – und ist es fast nie.

Ein Blick auf die Nachbartabelle hilft

Wenn man wissen will, warum der Kernel das Redirect ablehnt, lohnt sich ein Blick in die Neighbor-Daten:

ip -6 neigh show

Oder gezielter:

ip -6 route get 2001:db8:dead:beef::1

Wenn der vorgeschlagene Next Hop dort nicht als sinnvoller Neighbor auftaucht, ist die Sache im Prinzip entschieden.
Kein Neighbor → kein gültiger Next Hop → Redirect wird verworfen.

Warum das kein Bug ist

Die Meldung klingt erstmal nach kaputtem Routing. Ist es aber meistens nicht.

Im Gegenteil:
Der Kernel verhält sich exakt so, wie es das Protokoll vorsieht. Redirects sind Hinweise, keine Befehle. Und Linux nimmt diese Hinweise nur an, wenn sie sauber in das bestehende Neighbor- und Routing-Modell passen.

Das schützt unter anderem vor:

  • falschen Router-Konfigurationen
  • kaputten RA-Setups
  • Bridge-/VM-Konstrukten mit „kreativem“ IPv6
  • trivialen Redirect-Spoofing-Angriffen

Fazit

Die Meldung

rt6_redirect: source isn't a valid nexthop for redirect target

bedeutet nicht „IPv6 kaputt“.
Sie bedeutet: Ein Router hat ein Redirect geschickt, das aus Sicht des Hosts keinen gültigen Next Hop beschreibt.

In der Praxis ist das fast immer ein Hinweis auf:

  • Default- oder interne Routen ohne Link-Local-Next-Hop (siehe auch IPv6 ULA und Adresspriorisierung)
  • Router, die globale Adressen in Redirects verwenden
  • Setups, in denen Neighbor Discovery und Routing nicht sauber zusammenpassen

Oder anders gesagt:
Der Kernel ist hier nicht pingelig. Er ist vorsichtig. Und das ist gut so.

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

Der sichere GPG-Schlüssel

Absolut sicher ist nichts. Man kann nur versuchen, es Angreifern so aufwendig wie möglich zu machen. Bei GPG-Schlüsseln fängt das bei der Schlüssellänge und den Algorithmen an.

Schlüssellänge und Algorithmus

DSA-Schlüssel sind auf 512-1024 Bit begrenzt und anfällig bei schlechten Zufallsgeneratoren. ElGamal-Schlüssel können beliebig groß werden, teilen aber das Zufallsproblem. RSA mit 4096 Bit ist heute ein guter Kompromiss: rechenbar für aktuelle Hardware, nicht rechenbar für bekannte Angriffe. Quantencomputer könnten RSA in Zukunft gefährden, sind davon aber noch weit entfernt.

Unterstützte Verfahren anzeigen

gpg --version

Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
            CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2

MD5 ist gebrochen, SHA1 gilt als unsicher. SHA-256 und SHA-512 sind die sinnvolle Wahl. Bei den symmetrischen Verfahren sind AES-256 und Twofish solide. 3DES bleibt als Fallback, weil GPG es als Pflichtverfahren mitführt.

Algorithmus-Präferenzen setzen

Man kann im eigenen Schlüssel festlegen, welche Algorithmen in welcher Reihenfolge bevorzugt werden. Die kurze Key-ID (0x0F9874D8) reicht dafür, auch wenn man für andere Zwecke besser die volle Fingerprint-ID nutzt.

gpg --edit-key 0x0F9874D8

Aktuelle Einstellungen anzeigen:

gpg> showpref
[ uneing.] (1). Sebastian van de Meer (E-Mail Address) kernel-error @ kernel-error.com;
Verschlü.: TWOFISH, AES256, AES192, 3DES
Digest: RIPEMD160, SHA512, SHA256, SHA1
Komprimierung: BZIP2, ZLIB, nicht komprimiert
Eigenschaften: MDC, Keyserver no-modify

Gewünschte Algorithmen setzen:

gpg> setpref TWOFISH AES256 AES192 RIPEMD160 SHA512 SHA256 BZIP2 ZLIB
gpg> q
Änderungen speichern? (j/N) j

Der Schlüssel arbeitet ab sofort nur noch mit den festgelegten Verfahren. Kommunikationspartner, deren GPG-Installation keines dieser Verfahren unterstützt, fallen automatisch auf 3DES zurück.

Welchen Verfahren man letztlich vertraut, muss jeder für sich entscheiden.


Update 2025: Gehärtete gpg.conf für GnuPG 2.4

Die Schlüssel-Präferenzen oben sind der erste Schritt. Der zweite ist die lokale gpg.conf. Sie bestimmt, welche Algorithmen GnuPG überhaupt anbietet, wie die Passphrase gehärtet wird und wo nach Schlüsseln gesucht wird. Meine aktuelle Konfiguration für GnuPG 2.4 unter Linux:

# ~/.gnupg/gpg.conf — Hardened Config für GnuPG 2.4

# Ausgabe: lange Key-IDs und Fingerprints anzeigen
keyid-format 0xlong
with-fingerprint
utf8-strings

# Schlüssel automatisch suchen: erst WKD, dann DANE, dann Keyserver
auto-key-retrieve
auto-key-locate wkd,dane,local,keyserver
keyserver hkps://keys.openpgp.org

# Starke Defaults
cipher-algo AES256
digest-algo SHA512
cert-digest-algo SHA512

# KDF-Härtung: S2K mit 65 Mio. Iterationen
s2k-mode 3
s2k-digest-algo SHA512
s2k-cipher-algo AES256
s2k-count 65011712

# Legacy-Algorithmen komplett deaktivieren
disable-cipher-algo 3DES
disable-cipher-algo IDEA
disable-cipher-algo CAST5
disable-cipher-algo BLOWFISH
disable-cipher-algo TWOFISH

# Metadata minimieren
no-comments
no-emit-version
export-options export-minimal

# Trust-Modell: TOFU kombiniert mit Web of Trust
trust-model tofu+pgp

# Bevorzugte Algorithmen (lokal)
personal-cipher-preferences AES256 AES192 AES
personal-digest-preferences SHA512 SHA384 SHA256
weak-digest SHA1
force-ocb

# Default-Key (Ed25519)
default-key 0x5F279C362EEAB216

Was sich geändert hat

Ed25519 statt RSA. Mein aktueller Schlüssel ist ein Ed25519. Kürzere Schlüssel, schnellere Operationen, gleiche Sicherheit. RSA 4096 funktioniert weiterhin, aber für neue Schlüssel gibt es keinen Grund mehr dafür.

Legacy-Algorithmen deaktiviert. 3DES, IDEA, CAST5, Blowfish und Twofish sind per disable-cipher-algo komplett gesperrt. GnuPG bietet sie nicht mehr an und akzeptiert sie nicht. Das ist aggressiver als setpref, weil es auch eingehende Nachrichten betrifft. Wer damit Probleme bekommt, hat ein Gegenüber mit sehr veraltetem Setup.

S2K-Hardening. Die s2k-count Direktive bestimmt, wie oft die Passphrase bei symmetrischer Verschlüsselung gehasht wird. 65 Millionen Iterationen machen Brute-Force auf die Passphrase deutlich teurer. Der Wert ist der Maximalwert, den GnuPG akzeptiert.

OCB statt MDC. force-ocb erzwingt Authenticated Encryption (OCB) statt des älteren MDC (Modification Detection Code). OCB erkennt Manipulationen kryptographisch, nicht nur per Hash.

TOFU+PGP. trust-model tofu+pgp kombiniert das klassische Web of Trust mit Trust on First Use. Beim ersten Kontakt wird der Schlüssel akzeptiert, danach warnt GnuPG bei Änderungen. Pragmatischer als reines WoT, das in der Praxis kaum jemand pflegt.

WKD und DANE. auto-key-locate wkd,dane,local,keyserver sucht Schlüssel zuerst per Web Key Directory und DANE, bevor der Keyserver gefragt wird. WKD liefert den Schlüssel direkt von der Domain des Empfängers. keys.openpgp.org als Keyserver statt der alten SKS-Pools, weil dort E-Mail-Adressen nur nach Bestätigung veröffentlicht werden.

Metadata minimieren. no-comments, no-emit-version und export-minimal sorgen dafür, dass verschlüsselte Nachrichten und exportierte Schlüssel keine unnötigen Informationen enthalten. Kein Kommentarfeld, keine GnuPG-Versionsnummer, keine überflüssigen Signaturen beim Export.

Fragen? Einfach melden.

Linux LUKS: Falsche Tastatur bei der Passphrase-Abfrage

Festplattenverschlüsselung mit LUKS ist eine feine Sache. Bis man beim Booten sein Passphrase eingibt, es dreimal falsch ist und sich fragt ob man den Verstand verloren hat. Man hat sein Passphrase mit deutscher Tastatur eingerichtet, aber beim Booten lädt Linux die Keymap erst nach der LUKS-Abfrage. Also tippt man auf einer englischen Tastatur und wundert sich, warum Y und Z vertauscht sind und die Umlaute fehlen.

Ich hab mich davon auch schon verarschen lassen. Nicht nur einmal. Die Lösung ist je nach Distribution unterschiedlich, aber das Grundprinzip ist immer dasselbe: Man muss dem initramfs beibringen, die richtige Keymap zu laden bevor die Passphrase-Abfrage kommt.

Lösung: vconsole.conf + initramfs

Auf systemd-basierten Distributionen (Debian, Ubuntu, Fedora, Arch) setzt man die Keymap in /etc/vconsole.conf:

# /etc/vconsole.conf
KEYMAP=de-latin1

Danach das initramfs neu bauen, damit die Keymap beim Booten verfügbar ist:

# Debian/Ubuntu
update-initramfs -u

# Fedora/RHEL
dracut --force

# Arch
mkinitcpio -P

Nach dem nächsten Reboot wird die deutsche Keymap vor der LUKS-Abfrage geladen.

Alternative: GRUB Kernel-Parameter

Auf Gentoo-basierten Distributionen (Gentoo, Funtoo, das inzwischen eingestellte Sabayon) kann man die Keymap über Kernel-Parameter in GRUB setzen:

# /etc/default/grub
GRUB_CMDLINE_LINUX="... dokeymap keymap=de"

Nach grub-mkconfig -o /boot/grub/grub.cfg greift das beim nächsten Boot. dokeymap weist das initramfs an, die Keymap sofort zu wechseln.

Wenn es zu spät ist

Wer sein Passphrase bereits mit der falschen Keymap eingegeben hat und nicht mehr reinkommt: Das Passphrase auf einer US-Tastatur tippen. Also mental die deutschen Sonderzeichen auf ihre US-Positionen mappen. Z und Y sind vertauscht, ö ist ; und ä ist ‚, Bindestrich liegt woanders. Oder man schließt eine externe USB-Tastatur an und stellt sie auf US. Sobald man drin ist, die Keymap wie oben beschrieben fixen.

Fragen? Einfach melden.

Western Digital Scorpio Black WDC WD7500BPKT-00PK4T0

Mein Notebook bietet glücklicherweise die Möglichkeit zwei Festplatten zu betreiben. Eine Platte ist eine SSD mit knapp 120GB für das System. Die andere habe ich heute gegen eine Western Digital Scorpio Black mit 750GB ausgetauscht. Hier liegt nun mein „home“.

Ich habe mich beim anlegen der Partitionen dagegen entschieden noch Platz für die Windows Spielepartition zu lassen. Ich habe einfach in den vergangenen Monate kaum noch Zeit zum Zocken gefunden. Irgendwas hatte einfach immer eine höhere Priorität. Nun ist also meine Homedir um 200GB größer und natürlich ganz brav mit luks verschlüsselt. Festplattenverschlüssellung mit Linux wwwwwööööööööööhhhhhhhhyyyyyyy.

In diesem Sinne… Gute Nacht!

luks-crypto-home Screenshot der Passsatz eingabe.

Fragen? Einfach melden.

TRIM für SSDs und Flash-Speicher unter Linux aktivieren

Was macht TRIM?

Wenn eine Datei gelöscht wird, entfernt das Dateisystem nur den Eintrag aus seinem Inhaltsverzeichnis. Die Speicherblöcke werden als überschreibbar markiert — aber der Datenträger selbst erfährt davon nichts. Bei klassischen Festplatten ist das egal. Bei Flash-Speicher (SSDs, USB-Sticks, Speicherkarten) wird es zum Problem.

Flash-Speicher verteilt Schreibvorgänge gleichmäßig über alle Zellen — das nennt sich Wear Leveling und verlängert die Lebensdauer. Dafür muss der Controller aber wissen, welche Blöcke frei sind. Ohne diese Information kann er irgendwann nur noch den kleinen Reservebereich nutzen und wird spürbar langsam. Genau hier kommt TRIM ins Spiel: Es teilt dem Datenträger mit, welche Blöcke nicht mehr gebraucht werden.

Methode 1: fstrim (manuell oder per Cronjob)

  • Informiert den Datenträger nur zum Zeitpunkt der Ausführung
  • Funktioniert ab Kernel 2.6.33
  • Lässt sich einfach per Cronjob automatisieren

Einmalig ausführen:

fstrim -v /

Täglich per Cronjob — ein Script unter /etc/cron.daily/hdd-trim anlegen:

#!/bin/bash
echo "Gestartet am: $(date)" >> /var/log/hdd-trim.log
fstrim -v / >> /var/log/hdd-trim.log
chmod +x /etc/cron.daily/hdd-trim

Die meisten Linux-Distributionen bringen mittlerweile einen systemd-Timer fstrim.timer mit, der wöchentlich TRIM ausführt. Ob er aktiv ist: systemctl status fstrim.timer

Methode 2: discard (Echtzeit-TRIM per fstab)

  • Informiert den Datenträger in Echtzeit bei jedem Löschvorgang
  • Erzeugt minimal mehr I/O als periodisches fstrim
  • Bei modernen SSDs und Kerneln problemlos nutzbar

In der /etc/fstab die Option discard zu den Mount-Optionen hinzufügen:

/dev/sda1  /  ext4  noatime,errors=remount-ro,discard  0  1

Device, Mountpunkt und Dateisystem natürlich an das eigene Setup anpassen.

Welche Methode?

Für die meisten Setups reicht der wöchentliche fstrim.timer — das ist heute die empfohlene Methode. discard in der fstab ist sinnvoll, wenn der Datenträger permanent voll ist und sofort von freigegebenen Blöcken profitieren soll. Für ZFS gibt es eine eigene TRIM-Konfiguration — siehe TRIM im ZFS-Pool aktivieren.

Achtung: TRIM sagt dem Datenträger, dass er Blöcke überschreiben darf. Wenn hier etwas schiefgeht, sind Daten weg. Vorher prüfen, ob Kernel, Dateisystem und SSD-Firmware TRIM korrekt unterstützen — und ein Backup haben.

Siehe auch: TRIM für SSDs im ZFS-Pool

Fragen? Einfach melden.

Unix / Linux Openssl Zertifikat pem konvertieren zu Microsoft Windows pfx

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:

# openssl pkcs12 -export -out telefon.de.pfx -inkey telefon.de.key -in telefon.de.crt -certfile CACert.crt

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?

Siehe auch: Elliptic Curve Zertifikate mit OpenSSL

Fragen? Einfach melden.

IPv6 – Neighbor Discovery – Openindiana – Solaris 11 – Opensolaris

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„.

Also bis dahin…

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑