Datenhaufen zu IT und Elektronik.

Autor: kernel-error (Seite 34 von 48)

Der sichere GPG-Schlüssel

Absolut sicher ist wie immer nichts, jeder kann nur versuchen sich so weit wie möglich der Perfektion anzunähern. Nachdem nun bewiesen ist dass einige Organisationen keine Kosten und Mühen scheuen um selbst starke Verschlüsselungen zu brechen…. Ja, da kann man nur versuchen es ihnen so schwer und aufwendig wie nur irgendwie möglich zu machen. Wie? Na da schauen wir doch mal!

Es beginnt mit der Schlüssellänge, diese sollte länger 1024 sein. DSA Schlüssel müssen eine größe zwischen 512 und 1024 Bits haben. Damit sollte man schon mal keinen DSA Schlüssel nutzen, vor allem da DSA von einem ehemaligen NSA-Mitarbeiter entwickelt wurde. ElGamal-Schlüssel hingegen können unbegrenzt groß werden. DSA sowie auch ElGamal-Schlüssel haben ein großes Problem mit schlechten Zufallsgeneratoren. Wird zum Beispiel eine Signatur mit der Hilfe eines schlechten Zufallsgenerators erstellt, lässt sich unter Umständen der private Schlüssel daraus errechnen. Es gibt für RSA theoretische Angriffsszenarien. Für einen 1024 Bit-Schlüssel wäre es eine Maschine welche von Menschen zwar gebaut werden kann, für den Betrieb würde es aber im Moment mehr Energie benötigen als die USA liefen können. Die Jungs schlafen nicht und bei die Faktorisierungsalgorithmen werden immer weiter verbessert, also den Schlüssel aufbohren… Mit den heutigen Rechenleistungen sind 4096 Bit lange Schlüssel kein Problem mehr. Einigen wir uns also für heute auf einen RSA Schlüssel mit einer Länge von 4096 Bit. Für heute? Joar… Quantencomputer könnten in der Zukunft erfolgreiche Angriffe auf RSA Schlüssel fahren. Dazu müsste ein Quantencomputer aber einen Angriff auf den kompletten Schlüssel fahren. Derzeit sind wir bei ~ich glaube~ deutlich unter 10Bit. 

Nun ist der benutzte Algorithmus an der Reihe. Welche Verfahren von seiner GnuPG Version unterstützt werden, zeigt man sich am einfachsten an mit:

$ 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? War das nicht schon lange geknackt? Jappp… MD5 ist ein unsicherer Hashalgorithmus. SHA1 gilt zwar noch als sicher, wird aber auch bald gefressen werden. SHA2 wurde zwar von der NSA entwickelt, es haben aber inzwischen so viele Augen drüber geschaut dass man davon ausgehen kann; hier hat die NSA nichts versteckt! SHA3 ist aktuell noch nicht komplett fertig ~oder?~. Wie auch immer…. Glücklicherweise kann man nun in seinem Schlüssel einstellen was genutzt werden soll und in welcher Reihenfolge. Reihenfolge kann man nicht einfach den „sichersten“ als einzigen einstellen? Ja, kann man…. Jetzt müssten sich nur noch alle auf den vermeintlich sichersten einigen, das umsetzten und wenn etwas schief geht dieses schnell anpassen. Klingt nicht nur so als wenn es nicht klappen wird. Also stellt man mehrere Algorithmen ein die man selbst verwenden möchte. Angenommen ich möchte nun also den Schlüssel mit der ID 0x0F9874D8 (b.t.w.: die kurze ID ist auch nicht mehr sicher) ändern. Dann mache ich dieses mit:

gpg --edit-key 0x0F9874D8

Zuerst mal schauen was eingestellt ist:

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

Die gewünschten Algorithmen setzte ich mit:

gpg> setpref TWOFISH AES256 AES192 RIPEMD160 SHA512 SHA256 BZIP2 ZLIB
Setze die Liste der Voreinstellungen auf:
Verschlü.: TWOFISH, AES256, AES192, 3DES
Digest: RIPEMD160, SHA512, SHA256, SHA1
Komprimierung: BZIP2, ZLIB, nicht komprimiert
Eigenschaften: MDC, Keyserver no-modify
Die Voreinstellungen wirklich ändern? (j/N)

Jetzt noch das editieren beenden:

gpg> q
Änderungen speichern? (j/N) j
random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
secmem usage: 64/32768 bytes in 1 blocks

Fertig… Schon arbeitet der Schlüssel nur noch mit den Algorithmen, welchen ich vertrauen möchte.

Welchen Verfahren kann man nun eigentlich noch wirklich vertrauen? Dieses muss natürlich jeder für sich entscheiden. 

Linux Luks keymap

Festplattenverschlüsselung ist eine tolle Sache, luks übernimmt diesen Job 1A. Nur dumm wenn sich „plötzlich“ die Keymap von latin1 / deutsch auf englisch ändern. Wie geht das? Nun ja, man richtet mit geladener deutsche Keymap seine verschlüsselte Partition oder Festplatte ein. Beim booten kommt die Abfrage des Passphrase noch vor dem laden der gewünschten Keymap. Schon kommt man in die Verlegenheit sein Kennwort auf einer englischen Tastatur zu tippen. Dieses merkt man nur leider nicht. Also gibt man sein Kennwort tausend mal ein und wundert sich warum es denn nicht korrekt sein soll.

Ich habe mich von dem Thema ebenfalls schon mal verarschen lassen. Auf einer Sabayon Kiste löst sich dieses Problem wie folgt:

Man erweitert einfach in der Kernel comand line diese Parameter: dokeymap keymap=de

dokeymap sorgt dafür das die Keymap sofort geändert wird und zwar zu keymap=de

 

Dieses giest man einfach in die passende Konfigurationszeile für grub:

$ vim /boot/grub/grub.cfg

linux /kernel-genkernel-x86_64-3.10.0-sabayon ro single init_opts=single splash quiet splash dokeymap keymap=de vga=791 quiet domdadm resume=swap:/dev/mapper/swap real_resume=/dev/mapper/swap dolvm root=/dev/mapper/root crypt_root=UUID=d8a6be16-1977-4471-bdbb-b8cea4aed177 docrypt crypt_swap=/dev/sdb3

Damit es nicht bei jedem neuen Kernel / Update neu nachgetragen werden muss legt man es am besten noch in der Standardkonfiguration ab:

$ vim /etc/default/sabayon-grub

GRUB_CMDLINE_LINUX="${GRUB_CMDLINE_LINUX} splash quiet splash dokeymap keymap=de vga=791 quiet domdadm resume=swap:/dev/mapper/swap real_resume=/dev/mapper/swap dolvm root=/dev/mapper/root crypt_root=UUID=d8a6be16-1977-4471-bdbb-b8cea4aed177 docrypt crypt_swap=/dev/sdb3"

 

Beim nächsten Reboot sollte es dann mit der deutschen Tastatur klappen!

 

 

SSL/TLS erzwungen

Sicher ist es schon aufgefallen…. Ich habe die Einstellung meiner Webseite so verändert dass nun SSL/TLS gesicherte Verbindung „erzwungen“ ist.
Nun hoffen wir mal dass ich damit keinen „abhänge“ 😀 Sollte es also Probleme geben, einfach mal melden!

DNSSEC & DANE: Mehr Sicherheit für DNS und TLS-Zertifikate

Schon einige Zeit ist meine Domain per DNSSEC geschützt und der Zugriff ist ebenfalls per SSL/TLS möglich. Mit DANE (DNS-based Authentication of Named Entities) ist es jetzt möglich die eingesetzten X.509 Zertifikate bzw. deren Checksummen mit dem DNS „abzugleichen“.

Die Idee dahinter ist, das löchrige System der CAs (certificate authority oder certification authority) etwas sicherer zu machen / zu ersetzten.

Unterstützt ein Client, wie zum Beispiel ein Browser, DANE so kann er beim verschlüsselten Verbindungsaufbau mit einem Server (z.B.: Webserver). Prüfen ob die Checksumme des TLS Zertifikates mit der in der DNS Zone hinterlegten übereinstimmt. So kann man diesem Zertifikat „trauen“, selbst wenn es sich um ein selbst signiertes Zertifikat handelt oder das Root-Zertifikat der CA nicht in seinem Client enthalten ist.

Selbstverständlich wird damit nicht sichergestellt das die angegebene Person oder Organisation wirklich hinter dem Zertifikat steht. Hier hängt es dann wieder an der CA, der muss man zum einen selbst vertrauen und zum anderen sollte sie dafür sorgen dass niemand an ihre Zertifikate kommt. Nichts ist 100%tig sicher! Man kann nur versuchen dem absoluten Vertrauen so nahe wie möglich zu kommen. Daher ist es sehr angenehem wenn verschiedene Mechanismen ineinandergreifen und sich nach Möglichkeit auch gegenseitig prüfen.

Dabei sollte der Benutzer aber mit so wenig technischen Dingen gequält werden wie nur möglich. DNSSEC, DANE und TLS ist aus meiner Sicht im Moment eine recht gute Kombination. Wenn alles sauber im Client implementiert ist und die Admins ihre Arbeit gemacht haben, bekommt der Benutzer nur die Information: „Was du da gerade machst ist möglicherweise nicht der Server mit dem du sprechen wolltest. Lass es lieber!“

Klar steht und fällt am Ende alles mit dem Benutzer. Hier müssen die Benutzer geschult und aufgeklährt werden. Den technischen Hintergrund muss aber kein Anwender verstehen. 

Ich stehe ja auf so etwas. Daher habe ich es direkt bei mir implementiert.

Bind kann ab der Version 9.8.3 mit TLSA RECORDS umgehen:

#### SCHNIPP ####
Feature Changes

* BIND now recognizes the TLSA resource record type, created to
support IETF DANE (DNS-based Authentication of Named Entities)
[RT #28989]
#### SCHNAPP ####

Damit es einfacher wird bietet die Internet Society (http://www.internetsociety.org/deploy360/resources/hashslinger-a-tool-for-creating-tlsa-records-for-dane/) ein Tool mit dem Namen Hash-slinger an. Dieses Tool unterstützt beim erstellen der TLSA-RECORDS und natürlich bei der Prüfung der DNS-RECORDS.

Für meine Hauptdomain findet sich folgender RECORD in der Zone:

_443._tcp.www.kernel-error.de. IN TLSA 3 0 1 a3218154fbaa792afba91075ea36b5ea6623d46766a10ff1d06e7de461f933f7

Geprüft wird dieser korrekt wie folgt, einmal für die IPv4 und einmal für die IPv6 Adresse:

$ ./tlsa -d -v www.kernel-error.de
Received the following record for name _443._tcp.www.kernel-error.de.:
Usage: 3 (End-Entity)
Selector: 0 (Certificate)
Matching Type: 1 (SHA-256)
Certificate for Association: a3218154fbaa792afba91075ea36b5ea6623d46766a10ff1d06e7de461f933f7
This record is valid (well-formed).
Attempting to verify the record with the TLS service...
Got the following IP: 212.23.142.146
SUCCESS (usage 3): The certificate offered by the server matches the TLSA record
The matched certificate has Subject: /description=3G0bqBiLJsg0y2nv/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=www.kernel-error.de/emailAddress=postmaster@kernel-error.de
Got the following IP: 2001:7d8:8001:100::dead:beef
SUCCESS (usage 3): The certificate offered by the server matches the TLSA record
The matched certificate has Subject: /description=3G0bqBiLJsg0y2nv/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=www.kernel-error.de/emailAddress=postmaster@kernel-error.de

Die gängigen Browser lassen sich bereits mit Plugins nachrüsten.

Spannende Infos zum Thema DANE gibt es hier:
http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec

Wer nur schnell und einfach die TLSA Records testen möchte, kann dieses hier tun: http://check.sidnlabs.nl/dane/


U-P-D-A-T-E 28.01.2014

Wie sich das Thema zusammen mit Postfix nutzen lässt um auch etwas gegen dieses hässliche EmiG (E-Mail made in Germany) zu tun ist hier zu finden: https://www.kernel-error.de/kernel-error-blog/260-postfix-ssl-tls-gesichert-mit-tlsa-dane-und-dnssec


U-P-D-A-T-E 09.08.2014

Ich habe den Mailgraph erweitert ( mailgraph Graphen um DANE erweitern ), damit er mir den unten stehenden Graphen erzeugt.

FrOSCon 8

Ich habe gerade die Bestätigung meines FrOSCon Tickets bekommen 🙂 Die FrOSCon ist dieses Jahr vom 24.08-25.08.2013 in Sankt Augustin. Ich schaffe es nicht immer zur FrOSCon denn meine Kinder haben immer um diesen Dreh Geburtstag. Das geht dann vor! In diesem Jahr klappt es genau und dieses freut mich natürlich umso mehr! Wir sehen uns also auf der FrOSCon….

http://www.froscon.de/

 

 

Kabelbruch am Fujitsu Siemens Notebook

Irgendwo hat mein Notebook einen „Wackler oder Kabelbruch“ auf dem Weg zum Display. Fujitsu Siemens NH751… Ich habe das Thema einfach eine Zeit lang ignoriert. Löst natürlich nicht das Problem, ist mir klar 🙂
Wie zu erwarten wurde es nicht besser sondern schlimmer. In der Zwischenzeit war es nicht mal mehr damit erledigt eine „funktionierende“ Kippstellung des Monitors zu finden. Also aufschrauben und nachschauen!

Es scheint wirklich ein Kabelbruch zu sein, irgendwo in der Nähe des rechten Scharniers. Gott ist das Notebook schlecht zu zerlegen. Da hat wohl jemand bei der Konstruktion nicht an Techniker gedacht 🙁

Ich habe 1 Stunde herum gefummelt, bevor ich den Kabelbruch gelötet hatte. Wie auch immer. Inzwischen ist es verlötet und es klappt wieder alles korrekt.

Es ärgert mich denn noch dass bei so vielen Geräten nicht darauf geachtet wird es am Ende reparieren zu können. Sollen wir denn wirklich alles wegwerfen?

 

 

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.

TRIM für SSD-Festplatten und Flash-Speicher: So optimierst du die Leistung

Was ist TRIM oder besser; Warum ist meine SSD so langsam?

Da unterhalte ich mich heute mit einem Bekannten über das neue Android 4.3 und welche Neuerungen es beinhaltet. Da stolpert mein Bekannter über TRIM. Nachdem ich es ihm erklärt habe, meint er: „Warum hat so eine geile Sache denn bisher noch keiner ersonnen? Das wäre doch auch für seinen PC wichtig!“. Wir sprechen kurz darüber das TRIM nicht wirklich eine Erfindung von Android/Google ist sondern um 2007 schon klar war.

Scheinbar ist das Thema im Zusammenhang mit Flash-Speichern wie SSD Festplatten, USB-Sticks oder Speicherkarten doch nicht so klar wie ich zuerst dachte….. Ja Felix, ich schreib es ja schon hier auf 🙂

Also was macht dieses komische TRIM? Nichts besonders, im Groben sagt es der Festplatte nur, welche Blöcke noch in Verwendung sind und welche nicht! Dieses hat natürlich einen Grund. Jeder der schon einmal „aus Versehen“ Dateien gelöscht hat und diese mit einem kleinen Programm wiederherstellen konnte, der weiß dass Dateien meist nicht gelöscht werden, sondern sie werden nur aus dem „Inhaltsverzeichnis“ des Datenträgers gelöscht und ihre Speicherblöcke werden im Dateisystem wieder zum Überschreiben gekennzeichnet. Welche Blöcke belegt und welche Böcke frei (also überschreibbar) sind davon hat der eigentliche Datenträger in der Regel keine Ahnung. Klassische Speichermedien müssen dieses auch nicht wissen. Für sie macht es keinen Unterschied ob der Block nun frei ist oder belegt. Im Gegenteil, es würde eher ein Problem sein, dieses dem Datenträger bei jedem Vorgang mit zu teilen. Warum? Nun ja, wenn ich eine Datei löscht, dann weiß das Dateisystem davon, dieses entfernt den Eintrag aus seinem „Inhaltsverzeichnis“ und macht noch ein bisschen „wuwu“ drumherum. Dieses bedeutet IOPS auf dem Datenträger. Wenn man nun zusätzlich noch den Datenträger darüber Informiert, dann bedeutet dieses noch mehr IOPS. Dieses setzt alle Komponenten unnötig unter Last und macht alles langsam.

Flash-Speicher kann nun IOPS deutlich besser verkraften als zum Beispiel eine einfache Festplatte. Denn beim Flash-Speicher sind die Informationen, egal wie verteilt sie auf dem Speicher liegen mögen, immer direkt verfügbar. Bei einer Festplatte muss erst der Schreib-/Lesekopf zur richtigen Spur gefahren werden und dann wartet alles darauf, dass die Information vorbei gedreht wird. Sind die Informationen auf einer Festplatte weit verteilt dauert es lange alle Informationen einzusammeln. Der Schreib-/Lesekopf muss halt immer erst zur richtigen Spur und dort auf die Informationen warten… Daher defragmentieren wir Festplatten, damit die Informationen möglichst schön zusammen liegen und optimalerweise in einer Spur direkt hintereinander eingelesen werden können. SSDs / Flash-Speicher defragmentieren wir nicht, denn es bringt nichts und macht nur den Speicher kaputt!!

Kaputt? Japp…. Denn hier wird in Speicherzellen geschrieben welche nach einer gewissen Anzahl Speichervorgängen unwiederbringlich kaputt gehen. Flash-Speicher sind daher mit etwas Intelligenz ausgestattet. So wird das Speichern auf einem Flash-Speicher immer über alle Speicherzellen verteilt. Damit ist die „Abnutzung“ am geringsten und der Speicher lebt am längsten. Zusätzlich gibt es immer etwas mehr Speicher als man wirklich benutzen kann. Dieser Speicher wird dann benutzt, wenn der Flash-Speicher voll oder besser fast voll beschrieben ist. Jetzt kann dieses verteilte und gleichmäßige Beschreiben der Speicherzellen natürlich nur mit freien und frei werdenden Blöcken passieren. Sonst würde wir ja Nutzdaten überschreiben. Genau jetzt wird es spannend. Denn wenn der Datenträger nicht weiß welche Blöcke wieder frei geworden sind, dann wird er irgendwann die Speichervorgänge nur noch auf dem Reservebereich verteilen und noch etwas später dann überhaupt nicht mehr, da für den Datenträger irgendwann alle Blöcke belegt sind. Dieses merkt der Benutzer dann meist daran, dass seine SSD ganz plötzlich sehr langsam arbeitet. Denn ab jetzt werden nur die Blöcke überschrieben, welche vom Filesystem explizit angegeben werden. Damit „verschleißt“ man also nicht nur seinen Flash-Speicher, sondern es wird zusätzlich langsam.

Teilt man also seinem Flash-Speicher mit welche Blöcke wieder frei geworden sind, kann dieser die Schreibvorgänge überhaupt und vor allem so gleichmäßig wie möglich verteilen. Das macht also TRIM 😀

Android kann es nun also ab Version 4.3, Linux macht es ab Kernel 2.6.33 (glaube ich zumindest) Windows 7 und die auf Windows 7 basierende Serverversion von Microsoft, Windows Server 2008 R2, kann es genau so wie: Solaris, FreeBSD oder Mac OS X.

Mac OS X im übrigen erst recht spät, bevor die Jungs angefangen haben in ihre MacBooks SSDs einzubauen war es wohl aus ihrer Sicht nicht nötig. Apple halt… Wie auch immer… Aktiviert werden muss es bei den meisten Betriebssystemen/Dateisystemen noch immer von Hand. Nur Microsoft ist da wie so oft etwas benutzerfreundlicher. Denn wenn der NTFS-Treiber erkennt dass der Datenträger TRIM unterstützt, schaltet er dieses voll automatisch mit an 🙂

Wer jetzt noch Windows XP oder *grusel* Window Vista einsetzt: Verkackt 🙂 ihr macht eure SSD kaputt!

Ein Linux Beispiel gefällig? Kein Problem…

So gesehen gibt es zwei mögliche Lösungen TRIM zu aktivieren:

1. Von Hand, wenn man es für nötig hält oder halt per cron-job.
+ Klasse Sache, geht ab Kernel 2.6.3irgendwas.
+ Per cron-job so einfach wie nem Baby den Schnuller zu klauen.
– Informiert den Datenträger natürlich nur in dem Moment in welchem es gestartet wird über den aktuellen Zustand.

2. Automatisch beim einbinden/mounten des Dateisystems per fstab.
+ Informiert den Datenträger in Echtzeit.
– Erst ab Kernel 3.0 wirklich mit den gängigen Filesystemen nutzbar.
– Man munkelt über kaputte Daten/Datenträger mit sehr alten SSDs.

Beispiel für Version 1:

fstrim -v /

Ach ja, fstrim ist das Programm welches mit Root-Rechten ausgeführt werden muss. „-v“ sorgt für die nötigen Informationen und „/“ ist das gewünschte Filesystem.

Möchte man alles per cron täglich ausgeführt haben erstellt man am besten unter: /etc/cron.daily/ ein neues Script: hdd-trim

Als Beispielinhalt:

#!/bin/bash
echo „Gestartet am: $(date)“ >> /var/log/hdd-trim.log
fstrim -v / >> /var/log/hdd-trim.log

Datei noch ausführbar machen:

chmod +x /etc/cron.daily/hdd-trim

Fertig…. Nun kann man sich täglich sein wachsendes Logfile anschauen 🙂

Beispiel für Version 2:

Einfach beim Konfigurationseintrag seines Wunschfilesystems discard zu den Mountoptions hinzufügen:

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

„/dev/sda1 / UUID“ natürlich genau so anpassen wie Mountpunkt oder Filesystem.

B.t.w.: Wir nehmen hier ein Programm, welches dem Datenträger sagt welche Blöcke frei sind und er doch bitte überschreiben darf/soll. Wenn hier etwas schief geht, werden unserer Daten überschrieben 🙂 Also, erst schauen ob die Versionen stimmen, ob die Firmware der Platte alles mit macht und dann nach einem Backup, testen 🙂

Prefix Delegation in IPv6: Einrichtung und Konfiguration

Prefix delegation per DHCPv6 ist ja nichts neues. Das eine FritzBox dieses bietet war mir aber neu. Vielleicht „unterschätze“ ich das Teil? Nein… 😛

Ich bekomme ein /48 zugeteilt, die FirtzBox bietet die (nicht weiter konfigurierbare) Möglichkeit ein /62 per Prefix delegation an einen weiteren Router im Netzwerk weiter zu geben.

Ich habe also mal meinen Mikrotik über den DHCPv6 Client mit einem Prefix füttern lassen. Der Mikrotik arbeitet als Hotspot und Trenner fürs Wlan usw.. Nun schiebt dieser das per Prefix delegation zugewiesene IPv6 /64 auch ins Wlan durch 🙂

Damit ist im Wlan nun über die FritzBox und über den Mikrotik auch IPv6 angekommen. Leider lässt sich an der FirtzBox kaum etwas hinsichtlich Netzwerk konfigurieren. Ist halt alles Zielgruppengerecht. Ich muss zugeben, hier hat mich die Kiste von AVM überrascht. Vielleicht schreibe ich sogar noch ein kleines HowTo zusammen… Vielleicht… 😛

« Ältere Beiträge Neuere Beiträge »

© 2025 -=Kernel-Error=-

Theme von Anders NorénHoch ↑