Ciscos Switch WS-C3560 kann, sofern man die entsprechende Lizenz hat und dann das richtige Image verwendet, tatsächlich IPv6 Routing in Hardware

The IP Services license provides a richer set of enterprise-class features, including advanced hardware-based IPv6 unicast and IPv6 Multicast routing as well as policy-based routing (PBR).

Mein erster Versuch das die Geschichte mit ipv6 unicast-routing zu aktivieren verlief trotz richtigem Image allerdings überraschend:

Switch(config)#ipv6 ?
% Unrecognized command

Damit IPv6 auf dieser Plattform wirklich funktioniert muss neben dem Image auch das SDM Profil stimmen. Auf meinem Switch war dies noch auf IPv4 eingestellt:

Switch#show sdm prefer
The current template is "desktop default" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

number of unicast mac addresses: 6K
number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 8K
number of directly-connected IPv4 hosts: 6K
number of indirect IPv4 routes: 2K
number of IPv4 policy based routing aces: 0
number of IPv4/MAC qos aces: 0.5K
number of IPv4/MAC security aces: 1K

Switch#conf t
Enter configuration commands, one per line. End with CNTL/Z.

Switch(config)#sdm prefer dual-ipv4-and-ipv6 routing
Changes to the running SDM preferences have been stored, but cannot take effect
until the next reload.
Use 'show sdm prefer' to see what SDM preference is currently active.

Nach dem reboot taucht auch IPv6 auf

Switch#show sdm prefer
The current template is "desktop IPv4 and IPv6 routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

number of unicast mac addresses: 1.5K
number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 2.75K
number of directly-connected IPv4 hosts: 1.5K
number of indirect IPv4 routes: 1.25K
number of IPv6 multicast groups: 1.125k
number of directly-connected IPv6 addresses: 1.5K
number of indirect IPv6 unicast routes: 1.25K
number of IPv4 policy based routing aces: 0.25K
number of IPv4/MAC qos aces: 0.5K
number of IPv4/MAC security aces: 0.5K
number of IPv6 policy based routing aces: 0.25K
number of IPv6 qos aces: 0.625k
number of IPv6 security aces: 0.5K

Und kann konfiguriert werden:

Switch(config)#ipv6 unicast-routing
Switch(config)#

Da ich gerade die Länge von Dateinamen herausfinden musste und mir nicht eingefallen ist wie man das elegant und schnell lösen könnte hab ich mir in der Shell eben was zusammengehackt. Vielleicht weiß jemand eine bessere Lösung:


for i in `ls -1`; do echo -n "$i:" ;echo $i |wc -m ; done | awk -F':' '{print $2 ":" $1}' | sort -n

Eine Änderung von IPv6 gegenüber IP4 besteht darin, dass per Voreinstellung jeder Teilnehmer eines Netzes immer eine sogenannte Link-Local Adresse besitzt. Dieser SLAAC (Stateless Address Autoconfiguration) genannte Automatismus ersetzt und erweitert das von IPv4 bekannte Zeroconf. Während Zeroconf immer durch zusätzliche Software implementiert wird, ist SLAAC Bestandteil des IPv6 Stacks. Das heißt: ist auf einem Host IPv6 aktiviert, so hat dieser auch immer ein IP Adresse auf die zugegriffen werden kann.

Eine Besonderheit ist dabei, dass der Link-Local Adressraum aus dem die IPs vergeben werden (fe80::/10) auf jedem Interface anliegt und man daher immer das Interface angeben muss auf dem man eine solche IP erreichen will. Dem Kommando ping6 wird das Interface mit -I übergeben:

krusty ~ # ping6 -c1 fe80::20a:e4ff:fe3a:cda9
connect: Invalid argument
krusty ~ # ping6 -I eth0 -c1 fe80::20a:e4ff:fe3a:cda9
PING fe80::20a:e4ff:fe3a:cda9(fe80::20a:e4ff:fe3a:cda9) from fe80::20a:e4ff:fe3a:1dc9 eth0: 56 data bytes
64 bytes from fe80::20a:e4ff:fe3a:cda9: icmp_seq=1 ttl=64 time=0.042 ms

--- fe80::20a:e4ff:fe3a:cda9 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.042/0.042/0.042/0.000 ms




Der ssh client bietet nun leider keinen solchen (offensichtlichen) Parameter. Hier wird das Interface direkt an die Adresse, getrennt von einem Prozentzeichen angehängt:

uwe@krusty ~ $ ssh fe80::20a:e4ff:fe3a:cda9%eth0
Last login: Sun Aug 14 16:04:38 CEST 2011 from fe80::20a:e4ff:fe3a:cda9%eth0 on pts/5
uwe@krusty ~ $


Nur ein kurzer Eintrag als Gedächtnisstütze wie die Logitech Webcam C250 unter Gentoo zum funktionieren zu bewegen ist. Folgende Kernel-Einstellungen (2.6.34 in diesem Fall, bei anderen Kerneln kann der Pfad unter Umständen ein wenig anders sein) sind vonnöten:

Device Drivers  --->

  Multimedia support  --->

    Video capture adapters --->

      V4L USB devices  --->

        USB Video Class (UVC)

Sound card support  --->

  Advanced Linux Sound Architecture  --->

    USB sound devices  --->

      USB Audio/MIDI driver

Diese Optionen als Modul konfiguriert und mit make ; make modules_install gebaut und udev sollte nach dem Anschluss der Webcam alles automagisch laden. Mit media-video/guvcview sollte dann bereits alles funktionieren. Die C250 bringt zwar ein Mikrofon mit, allerdings hat die schon vorhandene Soundkarte üblicherweise eine niedrigere Device Nummer in ALSA (und damit eine höhere Priorität) und ist damit das Standardgerät. Somit müsste in jedem Programm in dem man das Mikrofon der C250 benutzen will extra konfigurieren. Es ist jedoch auch möglich in ALSA verschiedene Standardgeräte für Wiedergabe und Aufnahme zu definieren. Dies kann entweder Global in der /etc/asound.conf oder für den entsprechenden Benutzer in der ~/.asoundrc geschehen. Zunächst muss man herausfinden welches Gerät welche Nummer hat:

$ cat /proc/asound/cards

 0 [Intel          ]: HDA-Intel - HDA Intel

                      HDA Intel at 0xf3ff8000 irq 22

 1 [NVidia         ]: HDA-Intel - HDA NVidia

                      HDA NVidia at 0xf7cfc000 irq 17

 2 [U0x46d0x804    ]: USB-Audio - USB Device 0x46d:0x804

                      USB Device 0x46d:0x804 at usb-0000:00:1d.0-1.5.1, high speed

Mein Onboard Sound hat demnach Nummer 0 und die Webcam Nummer 2. Mit diesen Infos kann die ALSA Konfigurationsdatei schon korrekt angepasst werden:

pcm.!default {

         type asym

         playback.pcm {

                 type plug

                 slave.pcm "hw:0,0"

         }  

         capture.pcm {

                 type plug

                 slave.pcm "hw:2,0"

         }  

 }

Sollten die entsprechenden Geräte andere Nummern haben muss die Zahl hinter hw: natürlich angepasst werden. Es geht garantiert einfacher, eleganter und schöner mit ALSA, allerdings bin ich mit der Konfiguration nie wirklich grün geworden und das da oben "works for me" :)

Ich kenne bisher niemanden der auf die Frage "Hast du Capslock/die Feststelltaste schonmal gebraucht?" mit ja geantwortet hätte. Bei der Anschlussfrage, ob Capslock schon einmal genervt hat antworteten bisher auch alle überinstimmend mit "Ja".

Grund genug dieses Ungetüm aus der grauen Schreibmaschienenvorzeit auf den digitalen Friedhof zu verbannen. Das Projekt CAPSoff hat sich der endgültigen Lösung des Problems verschrieben, ich möchte jedoch die "softe" Variante und Linux vorstellen. Die meisten Beschreibungen zu dieser Taste im Netz schalten sie komplett ab. Dabei wird jedoch übersehen, dass man meistens durchaus einen Tastendruck beabsichtigt hatte und eine der Tasten in umittelbarer Umgebung (Tab, A und Shift) erwischen wollte. Bindet man nun auf Capslock A oder Tab, so muss man das zusätzliche Zeichen bei einem Vertipper wieder löschen/die Aktion rückgängig machen. Bindet man jedoch Shift passiert bei einem Vertipper gar nichts. Aus diesem diesem Grund habe ich mich dazu entschlossen Capslock mit Shift zu belegen. Lange Vorrede, kurze Lösung:

Zunächst muss eine Datei (bei mir $HOME/.Xmodmap) mit folgendem Inhalt erzeugt werden:

clear Lock
add shift = Caps_Lock

Diese kann dann einfach mit einem xmodmap $HOME/.xmodmap geladen werden. Um dies Automatisch bei der KDE Ameldung auzuführen habe ich die Datei $HOME/.kde/Autostart/xmodmap erstellt:

#!/bin/bash
xmodmap $HOME/.Xmodmap

Noch mit chmod 755 $HOME/.kde/Autostart/xmodmap ausführbar machen und Capslock sollte nie wieder Probleme verursachen.

Um die Uhrzeit unter Linux mit der Koordinierten Weltzeit (UTC) synchron zu halten sollte NTP als standardisierte und offenes Protokoll benutzt wurden. Hierbei stehen einige Programme zur Auswahl, welche unterschiedliche Strategien zum Abgleich verfolgen. Das einfachste in dieser Katagorie ist sicher ntpdate, welches einen Server nach der aktuellen Uhrzeit befragt und diese hart im System setzt. Dieses Vorgehensweise übergeht jedoch Daemons wie z.B. cron und so können geplante Backups schlicht "vergessen" werden. Auch wenn man gerade am Rechner arbeitet kann eine plötzliche Veränderung der Zeit den Bildschirmschoner anspringen lassen.

Auch aus diesen Gründen sollte dem ntpd als Standardimplementation der Vorzug gegeben werden. Dieser gleicht Gangdifferenzen zur korrekten Uhrzeit durch Beschleunigung bzw. Verlangsamung der lokalen Systemuhr aus. Stimmt die Zeit wieder, stellt der Daemon die richtige Geschwindigkeit her. Die oben angeführten Nachteile von ntpdate sind damit schon einmal umschifft. Natürlich bringt das eine etwas aufwendigere Konfiguration mit sich, allerdings sollte dies mit den zahlreichen Tutorials im Netz kein Problem sein.

Vereinfacht wird die "richtige" Geschwindigkeit der Systemuhr normalerweise durch einen Baustein auf dem Motherboard bestimmt, wobei ein Quarzkristall x-mal pro Sekunde schwingt. Da es bei solchen Bauteilen allerdings immer auch Fertigungstoleranzen gibt, ist die Sekunde sogar auf auf zwei Motherboards des gleichen Modells unterschiedlich lang. Diese Sekunden unterscheiden sich dann auch noch einmal von der einer (extrem genauen) Atomuhr. Dieser Unterschied wird auch Drift genannt, der bei jedem Computer unterschiedlich ist. Diesen Drift speichert der ntpd standardmässig unter /var/lib/ntp/ntp.drift und kann die Uhrzeit so auch ohne Verbindung in Netz sehr genau halten.

Mit dem Kommandozeilenprogramm ntpq kann man dem ntpd bei der Arbeit zusehen und Problemen auf den Grund gehen. Die verbundenen ntp Server werden mit dem Kommando "peers" angezeigt:

uwe@krusty ~ $ ntpq -n -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
*129.70.132.33 129.70.130.70 2 u 45 64 377 65.492 4.168 0.805
+85.214.29.92 131.188.3.222 2 u 3 64 377 72.744 -0.136 0.702
+78.47.136.197 143.93.99.252 2 u 55 64 377 59.573 1.509 1.118
-92.51.130.224 85.214.71.202 3 u 60 64 377 69.906 -5.627 0.654


Hier sollte mindestens ein Server mit einem * markiert sein. Dieser ist für den ntpd am "stabilsten" zu erreichen und der eigene Referenzserver. Die mit + markierten Hosts wären die nächsten Kandidaten falls der Referenzserver nicht mehr verfügbarsein sollte. Mit "associations" kann man sich diese Beziehungen auch ansehen


uwe@krusty ~ $ ntpq -n -c associations

ind assID status conf reach auth condition last_event cnt
===========================================================
1 54760 9624 yes yes none sys.peer reachable 2
2 54761 9424 yes yes none candidat reachable 2
3 54762 9424 yes yes none candidat reachable 2
4 54763 9324 yes yes none outlyer reachable 2


Es gibt auch einen Kommandozeilenmodus von ntpq in dem man sich austoben kann:


uwe@krusty ~ $ ntpq
ntpq> ?
ntpq commands:
addvars debug lopeers passociations rl
associations delay lpassociations passwd rmvars
authenticate exit lpeers peers rv
cl help mreadlist poll showvars
clearvars host mreadvar pstatus timeout
clocklist hostnames mrl quit version
clockvar keyid mrv raw writelist
cooked keytype ntpversion readlist writevar
cv lassociations opeers readvar
ntpq>


Will man mit einem DSL Anschluss in Deutschland per IPv6 ins Internet und nicht extra dafür zu einem der wenigen Provider die IPv6 nativ anbieten wechseln, so bleibt als einzig praktikable Möglichkeit derzeit nur ein 6in4 Tunnel. Der amerikanische Konzern Hurricane Electric (oder der einfacheit halber: HE) bietet unter http://tunnelbroker.net/ einen kostenlosen IPv6 Tunnelbroker an, zu welchem man von jedem beliebigen DSL aus einen Tunnel betreiben kann. Nach der Registrierung kann unter "Create Regular Tunnel" ein neuer Tunnel beantragt werden. Dabei muss die eigene DSL IP (herauszufinden z.B. bei www.whatismyip.org) allerdings pingbar sein, sonst scheitert der Antrag. Ausserdem sollte man gleich ein "Routed /48" beantragen, damit man die Clients hinter dem eigenen Router gleich mit IPv6 versorgen kann.

Ich benutze auf meinem DSL Router WRT54GL derzeit die Linuxdistribution OpenWRT. Es exitiert zwar eine Anleitung für IPv6 auf dieser Distribution, allerdings ist diese nicht mehr wirklich aktuell. Diese Anleitung wurde erfolgreich mit der OpenWRT Version 8.09.1 (Kamikaze) entwickelt. Um IPv6 mit HE zum fliegen zu bringen sind folgende Schritte notwendig:

Zunächst müssen mit opkg install folgende Pakete installiert werden


ip6tables
kmod-ip6tables
kmod-ipv6
radvd


Der Tunnelbroker geht von einer statischen IP aus, bei DSL ändert sich diese jedoch üblicherweise mit jeder Neueinwahl. Um den Tunnelendpunkt bei jeder Änderung wieder aufzusetzen habe ich ein Shellskript erstellt. Es wird immer aufgerufen wenn sich ein Interfacestatus ändert. Zunächst wird die Benutzernummer gebraucht, welche auf der Hurricane Electric Tunelbroker Homepage direkt neben "UserID" steht. Ebenfalls auf der HE Seite unter "Tunnel Details" ist die "Global Tunnel ID" zu finden. Der letzte notwendige Wert ist das mit MD5 gehashte Passwort. Dies lässt sich am einfachsten an der Shell erstellen:


$ echo -n 'XXX' | md5sum
bc9189406be84ec297464a514221406d -


Die MD5 Summe das Passworts XXX ist in diesem Beispiel also bc9189406be84ec297464a514221406d. Der letzte Wert der benötigt wird ist die "Client IPv6 address", welche sich ebenfalls bei den "Tunnel Details" befindet.

Diese Werte müssen in das Skript unten eingetragen und in der Datei /etc/hotplug.d/iface/10-ipv6 gespeichert werden:


#!/bin/sh

USER="XXX"
PASS="XXX"
ID="XXX"
CLIENT="XXX/64"
REMOTEV4="216.66.80.30"
ROUTEDNET="XXX::/48"

EXT="wan"
INT="lan"
TUNNEL="he-ipv6"

. /etc/functions.sh # common functions
include /lib/network # include /lib/network/*.sh
scan_interfaces # read and parse the network config


if [ "$ACTION" = "ifup" -a "$INTERFACE" = "$EXT" ]
then
config_get IPV4 "$EXT" ipaddr
logger "updating ipv4 tunnel endpoint to $IPV4"
wget -O - "http://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=$IPV4&pass=$PASS&user_id=$USER&tunnel_id=$ID" > /dev/null 2>&1
ip tunnel add $TUNNEL mode sit remote $REMOTEV4 local $IPV4 ttl 255
ip link set $TUNNEL up
ip addr add $CLIENT dev $TUNNEL
ip route add ::/0 dev $TUNNEL
config_get LANIF "$INT" ifname
ip route add $ROUTEDNET dev $LANIF
fi

if [ "$ACTION" = "ifdown" -a "$INTERFACE" = "wan" ]
then
ip tunnel del $TUNNEL
config_get LANIF "$INT" ifname
ip route del $ROUTEDNET dev $LANIF
fi



Um die Kommunikation mit dem Tunnelbroker zu erlauben muss dieser in der OpenWRT IPv4 Firewall (/etc/config/firewall) freigeschaltet werden:


config rule
option src_ip 216.66.80.30
option proto 41
option target ACCEPT


Um den Router auch gegenüber dem Internet zu schützen sollten in die Datei /etc/firewall.user folgende Zeilen hinzugefügt werden:


### ipv6 stuff
ip6tables -F INPUT
ip6tables -P INPUT DROP
ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT
ip6tables -A INPUT -p icmpv6 -j ACCEPT
ip6tables -F FORWARD
ip6tables -A FORWARD -j ACCEPT


Diese Firewall schützt nur den Router und nicht die Clients im Netz dahinter. Entweder man erweitert die Regeln oben entsprechend oder man spendiert jedem Client eine IPv6 Firewall. Die oben gemachten Änderungen werden nach einem "/etc/init.d/firewall restart" aktiv.

Die Einstellungen sind gemacht und nach einem "ifdown wan; ifup wan" sollte der Tunnel stehen. Dies kann gleich mit ping6 geprüft werden:


root@OpenWrt:~# ping6 -c3 www.kame.net
PING www.kame.net (2001:200:0:8002:203:47ff:fea5:3085): 56 data bytes
64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: seq=0 ttl=51 time=294.092 ms
64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: seq=1 ttl=51 time=292.718 ms
64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: seq=2 ttl=51 time=293.255 ms

--- www.kame.net ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 292.718/293.355/294.092 ms
root@OpenWrt:~# ping6 -c3 ipv6.google.com
PING ipv6.google.com (2001:4860:a003::68): 56 data bytes
64 bytes from 2001:4860:a003::68: seq=0 ttl=59 time=19.912 ms
64 bytes from 2001:4860:a003::68: seq=1 ttl=59 time=15.248 ms
64 bytes from 2001:4860:a003::68: seq=2 ttl=59 time=15.082 ms

--- ipv6.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 15.082/16.747/19.912 ms


Um nun die Clients im eigenen Heimnetz per Autokonfiguration mit IPv6 zu versorgen muss der Linux Router Advertisement Daemon konfiguriert werden. Dazu wird das oben beantragte Routed /48 benötigt. Die Konfiguration sieht bei mir folgendermassen aus:

/etc/config/radvd

config interface

        option interface        'lan'

        option AdvSendAdvert    1

        option AdvManagedFlag   0

        option AdvOtherConfigFlag 0

        option ignore           0



config prefix

        option interface        'lan'

        # If not specified, a non-link-local prefix of the interface is used

        option prefix           '2001:470:9888::/64'

        option AdvOnLink        1

        option AdvAutonomous    1

        option AdvRouterAddr    0

        option AdvPreferredLifetime     600

        option AdvValidLifetime 1200

        option ignore           0



config rdnss

        option interface        'br-lan'

        # If not specified, the link-local address of the interface is used

        option addr             ''

        option ignore           1

Für die option "prefix" muss das eigene bei HE beantragte /48 eingetragen werden. Achtung: als Netzmaske für radvd ist /64 zwingend notwendig, denn nur so können sich die Clients mit Hilfe von EUI-64 selbst eine Adresse würfeln. Trägt man hier /48 bleiben 16 Bits übrig, von denen der Client nicht weiss, wie er sie füllen soll. Nachdem man den Daemon aktiviert und gestartet ist sollten alle Clients im dahinterliegenden Netz automatisch mit IPv6 versorgt werden, sofern das Betriebssystem dies unterstützt.


root@OpenWrt:~# /etc/init.d/radvd enable
root@OpenWrt:~# /etc/init.d/radvd start


Da ich eben doch eine Weile gebastelt möchte ich folgendes für die Nachwelt aufbewahren. Die Konvertierung einer Subnetmaske (übliches Format) in die (von Cisco benutzte) Wildcard Notation in python:


uwe@barney ~ $ python
Python 2.6.2 (r262:71600, Sep 3 2009, 02:12:03)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket, struct
>>> a=struct.unpack('!L',socket.inet_aton("255.255.255.0"))[0]
>>> socket.inet_ntoa(struct.pack('!L',~a & 0xFFFFFFFF))
'0.0.0.255'


Ein paar Anmerkungen zum besseren Verständnis

• !L wird gebraucht da Network byte order Big Endian(!L) ist, die normalen PC Architekturen aber Litte Endian(L) verwenden.


• Das bitweise AND mit 0xFFFFFFFF ist notwendig, da das NOT vor a einen negativen Wert erzeugt, welcher nicht mehr in den Long passt. Das wiederrum erzeugt eine unschöne Warnung. Dieses Vorzeichenbit wird mit der Verknüpfung positiv womit das ganze wieder passt.

Nachtrag:

Um CIDR nach Netzmaske zu Konvertieren nimmt man das hier:


>>> socket.inet_ntoa(struct.pack('!L',8589934591L<<(32-24)))
'255.255.255.0'
>>> socket.inet_ntoa(struct.pack('!L',8589934591L<<(32-25)))
'255.255.255.128'
>>> socket.inet_ntoa(struct.pack('!L',8589934591L<<(32-26)))
'255.255.255.192'
>>> socket.inet_ntoa(struct.pack('!L',8589934591L<<(32-27)))
'255.255.255.224'


2. Nachtrag

Oder einfacher zu lesen (und zu verstehen):


>>> socket.inet_ntoa(struct.pack('!L',0xFFFFFFFF<<(32-24)))
'255.255.255.0'
>>> socket.inet_ntoa(struct.pack('!L',0xFFFFFFFF<<(32-25)))
'255.255.255.128'
>>> socket.inet_ntoa(struct.pack('!L',0xFFFFFFFF<<(32-26)))
'255.255.255.192'
>>> socket.inet_ntoa(struct.pack('!L',0xFFFFFFFF<<(32-27)))
'255.255.255.224'


Konfigurationsdateien unter *nix Systemen werden üblicherweise in /etc abgelegt. Da es sich dabei meist um reine Textdateien handelt bietet sich eine Versionierung mit einem der bekannten Systeme an. Ich habe mich aus reiner Faulheit (meine Diplomarbeit enstand bereits damit) für Subversion entschieden. Die Einführung in SVN, so die Abkürzung für Subversion, und in Versionsverwaltung allgemein spare ich mir an dieser Stelle da es dazu schon viele hervorragende Quellen im Web gibt.

Ich habe diverse Rechner, deren /etc ich auf diese Weise sichern und will und einen Rootserver welchen ich als zentrales Repository zur Speicherung benutzen möchte.

Als erstes wird das dazu das SVN Repository angelegt:

uwe@maninthemiddle ~ $ svnadmin create /home/uwe/repos

Mehr muss auf dem Server auch nicht mehr gemacht werden. Der Rest wird vom Clientrechner (in meinem Fall mit dem Namen "Krusty" über SSH erledigt. Dazu bietet es sich an Key-basierende Authentifizierung für SSH zu benutzen. Auch hier sei auf die vielen guten Tutorials im Web verwiesen. Da ich SSH normalerweise als unprivilegierter Anwender benutze /etc aber nur als root vollständig gelesen werden kann, sollte das SSH profil von root dementsprechend angepasst werden. Dies beinhaltet den richtigen Benutzernamen, sowie eine identity Datei welche den private key enthält. Die entsprechende Konfigurationsdatei /root/.ssh/config sieht bei mir dementsprechend so aus:

Host maninthemiddle.de
User uwe
IdentityFile /home/uwe/.ssh/id_rsa

Nun muss im Repository ein Verzeichnis angelegt werden in dem die Dateien später landen sollen:

krusty etc # svn mkdir svn+ssh://maninthemiddle.de/home/uwe/repos/etc-krusty

Dieses wird im Verzeichnis /etc auf dem lokalen Rechner ausgecheckt und ist damit mit diesem verbunden:

krusty etc # svn co svn+ssh://maninthemiddle.de/home/uwe/repos/etc-krusty /etc

Mit svn add können nun Dateien hinzugefügt und mit svn commit ins Repository hochgeladen werden. Unschön ist dabei allerdings, dass nicht hinzugefügte Dateien bei svn status mit einem Fragezeichen auftauchen und die Übersichtlichkeit stark leidet:

krusty etc # svn status
M .
? xinetd.conf
? opera6rc.fixed
? nanorc
? racoon
? java-config-2
...

Bei der Softwareentwicklung sorgt dieser Mechanismus dafür, dass keine Datei vergessen wird. Hier tauchen in diesem Fall jedoch in der Mehrzahl Dateien auf die gar nicht ins Repository kommen sollen. Um den Überblick zu behalten habe ich deshalb SVN angewiesen alle Dateien zu ignorieren, die nicht eingecheckt sind.

krusty etc # svn propset svn:ignore '*' /etc

Für alle anderen Rechner einfach die gleichen Schritte durchführen, womit Probleme mit gelöschten/verschlimmbesserten Konfigurationsdateien der Vergangenheit angehören sollten.

Nachtrag:
Gerade unter gentoo sollte auch die aktuelle Kernelkonfiguration gesichert werden. Ich setze dazu einfach einen Symlink nach /etc und füge diese Datei zum Repository hinzu.

barney etc # ln -s /usr/src/linux/.config kernelconfig
barney etc # svn add kernelconfig
A kernelconfig

Nachtrag 2:
Die alten Versionen einzelner Dateien kann man mittels svn export -r REVISION holen:

uwe@barney ~/tmp $ svn log svn+ssh://maninthemiddle.de/home/uwe/repos/etc-barney/lilo.conf
------------------------------------------------------------------------
r18 | uwe | 2009-11-26 21:49:23 +0100 (Do, 26. Nov 2009) | 1 Zeile


------------------------------------------------------------------------
r17 | uwe | 2009-11-26 21:43:01 +0100 (Do, 26. Nov 2009) | 1 Zeile


------------------------------------------------------------------------
uwe@barney ~/tmp $ svn export -r 17 svn+ssh://maninthemiddle.de/home/uwe/repos/etc-barney/lilo.conf
A lilo.conf
Export abgeschlossen.

Nachtrag 3:
Um z.B. die /etc/X11/xorg.conf ins Repository hinzufügen zu können muss auch das Verzeichnis /etc/X11/ im Repository vorhanden sein. Subversion fügt mit svn add /etx/X11 allerdings auch alle Dateien unterhalb dieses Verzeichnisses ein. Stattdessen möchste man die Option --non-recursive benutzen:

barney etc # svn add --non-recursive X11/
A X11

Versehentlich ins Repository aufgenomme Dateien kann man mit svn delete wieder aus diesem entfernen, allerdings löscht svn dann auch die lokale Kopie. Hier sollte man --keep-local als Option mitgeben:

barney portage # svn delete --keep-local savedconfig/
D savedconfig/sys-apps/busybox-1.13.2
D savedconfig/sys-apps
D savedconfig

Wer kennt das nicht. Nach dem Urlaub werden Fotos am Bildschirm bestaunt und es dauert nicht lange bis das kollektive Kopfkippen nach rechts oder links beginnt. Glücklicherweise haben inzwischen sogar Handykameras Neigungssensoren eingebaut, womit die Elektronik die Ausrichtung in den EXIF Daten eines Bildes speichern kann. Somit ist es für ein Ausgabegerät möglich das Foto anhand dieser Daten wieder richtig herum auf den Bildschirm zu bringen. Der Bildbetrachter beispielsweise gqview kann die Fotos so schon vor der Anzeige drehen. Allerdings wirkt sich dies nur auf die Darstellung aus und die gespeicherten Fotos behalten ihre Ausrichtung. Da nicht alle Bildbetrachter so eine Funktion enthalten will man natürlich das gespeicherte Material zurecht rücken. Dabei ist zu bedenken, dass JPEG ein verlustbehaftetes Format ist und das Laden, Drehen und erneute Speichern zur Qualitätsminderung führen würde. Glücklicherweise wurden solche Fälle von der Joint Photographic Experts Group bei der Entwicklung des Formats bedacht. Aus diesem Grund wurden einige spezielle verlustfreie JPEG Operationen definiert wie z.B. drehen um vielfache von 90° und das Beschneiden eines Bildes um vielfache von 16 Pixeln. Das Verarbeitende Programm muss diese JPEG Operationen allerdings explizit unterstützen, sonst werden in der Regel verlustbehaftete Operationen durchgeführt. Genug der Theorie, hier die Linux Praxis:

Unter Gentoo befinden sich alle hier genannten Tools im Paket media-libs/jpeg. Das Programm jpegtran unterstützt besagte JPEG Operationen und kann die Bilder wie gewünscht drehen. Es empfiehlt sich außerdem immer den Parameter -copy all zu verwenden, damit die EXIF Daten erhalten bleiben. Allerdings stimmt nun die in den EXIF Daten gespeicherte Ausrichtung nicht mehr. Diese kann man dann mit dem Tool jpegexiforient und dem Parameter -1 auf Normalausrichtung setzen. Das ganze ist natürlich automatisierbar und mit dem Skript exifautotran umgesetzt. Zunächst wird die Ausrichtung gelesen, dann richtig gedreht und zum Schluss wird im EXIF Teil wieder die Normalausrichtung gesetzt. Ein exifautotran *.jpg entlastet also die Nackenmuskulatur während des Fotoabends.

Update: unter Ubuntu heißt das entsprechende Paket libjpeg-progs

Cisco bietet auf einer Menge Devices IPSec zur verschlüsselten Remote Anbindung entfernter Standorte. Ich habe das ganze letzte Woche anhand einiger Laboraufbauten getestet. Mit von der Partie waren ein Router der Serie 2600er mit IOS, ein VPN Concentrator (3000er Serie) und eine PIX. Das ganze sah in etwa folgendermassen aus:

PC1 --(192.168.55.0/24)-- Cisco Device 1 --(192.168.66.0/24)-- Cisco Device 2 --(192.168.77.0/24)-- PC2

Zwischen beiden Cisco Devices sollte ein IPSec Tunnel aufgebaut werden und die Netze 192.168.55.0/24 und 192.168.77.0/24 über diesen verschlüsselt übertragen werden. Ziel war es also, dass PC1 PC2 pingen kann.

Die Konfiguration ist zwar recht einfach, wenn man die Tutorials auf der Cisco-Homepage befolgt, wenn es danach allerdings nicht so tut wie es soll, wird es mühsam. Deshalb hier meine gesammelten Erkenntnisse:

• Beide Cisco Devices sollten sich nicht im selben Subnet befinden (der Aufbau von oben bringt also Probleme). Es kommt zu sehr seltsamen Effekten, wenn es kein Default Gateway bzw. keine Default Route gibt. Das Default Gateway sollte dabei natürlich auf dem äußeren Interface liegen.


• Die PIX nimmt beim Hashing der Identity standardmäßig den FQDN, was ohne DNS-Namen im Laboraufbau natürlich sinnfrei ist. Mit folgendem Kommando kann man auf IP Adressen umschalten: isakmp identity address

Ich schreib das jetzt so einfach runter, aber besonders der erste Punkt hat doch einiges an Zeit verschlungen. Ich hoffe ich erspare jemand anderem damit die Sucherei nach dem Fehler.

Scapy ist ein ziemlich cooler Packetgenerator/Analyzer/vielesmehr. Die Projektseite gibt mit der "Quick Demo" schon eine kleine Einführung in die Fähigkeiten dieses Tools.

Leider ist die Dokumentation im im Gegensatz zum Programm noch weitgehend unbrauchbar und deshalb will ich versuchen hier immer mal wieder nützliche Scapy Skripte/Einzeiler vorzustellen.

Wilde DHCP Server finden

Problem: irgendwo im Netz schwirrt ein nicht genemigter DHCP Server herum und vergibt IP Adressen. Die umständliche Methode wäre das eigene Interface umzukonfigurieren und einen DHCP Request zu machen. Scapy schafft das ohne diesen lästigen Mehraufwand.

>>> dhcp_request(iface="eth1")
WARNING: conf.checkIPaddr is not 0, I may not be able to match the answer
Begin emission:
Finished to send 1 packets.
.......................................
Received 39 packets, got 0 answers, remaining 1 packets

Ein gleichzeitiger tcpdump offenbart ide MAC-Adresse des Übeltäters:

# tcpdump -e -i eth1 port 67 or port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes

21:43:17.938745 00:11:11:11:11:11 (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 286: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:11:11:11:11:11 (oui Unknown), length 244

21:43:17.952684 00:22:22:22:22:22 (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: ..bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300

Mit einem managbaren Switch lässt sich die Adresse 00:22:22:22:22:22 nun schnell einem Port zuordnen. Unter IOS z.B. mit show mac-address-table oder unter CatOS mit show cam dynamic. Dann muss man nur noch das Kabel verfolgen und dem User auf die Finger klopfen ;).

Ich hab die Schnauze gestrichen voll. Trotz der Tatsache, dass Trackbacks auf moderieren stehen, erhalten ich ständig Müll von irgendwelchen asozialen Spammern. Aus diesem Grund sind sie jetzt global deaktiviert. Wer einen Trackback setzen will, möge mich per Mail kontaktieren.

Einen Artikel habe ich dem Internet Explorer ja bereits gewidmet. Auch wenn ich dieses Stück Software niemals freiwillig benutzen würde und es so viel Aufmerksamkeit eigentlich nicht verdient, so muss ich doch ab und an damit arbeiten. Und heute hat mir der IE wieder zehn Minuten meiner kostbaren Zeit gestohlen. Ein Webserver, den ich testen wollte lief nicht auf dem Standardport. Also text.example.com:20000 in die Adressleiste des IE. Der Browser meint dazu "Die Seite kann nicht angezeigt werden - Fehler: Server oder DNS kann nicht gefunden werden". Um die Geschichte abzukürzen: im Netz stimmte natürlich alles, der Internet Explorer will jedoch ein Protokoll sobald ein Port angegeben wird. http://test.example.com:20000 funktionierte dann auch. Einen technischen Grund für dieses Verhalten gibt es nicht, denn ein Domainname kann sowieso keinen Doppelpunkt enthalten. Folgerichtig frisst der Firefox text.example.com:20000 auch problemlos. Vielleicht hat sich das inzwischen im IE7 gebessert, aber ich muss Microsoft trotzdem ein Kompliment für dieses tolle Verhalten des IE6 aussprechen.

Heutzutage ist es sinnvoll und nur vernüftig TCP Verbindungen abzusichern. Dies geschieht bei HTTP (aber auch einigen anderen Protokollen) über TLS/SSL. Falls allerdings Probleme auftreten ist die Möglichkeit durch Mitsniffen Hinweise auf Fehler zu erhalten verbaut. Auch die beliebte Methode eine Serveranwendung mit telnet oder netcat zu testen ist nicht mehr ohne weiteres durchführbar. Die bekannteste SSL Implementation OpenSSL bietet allerdings ein Dienstprogramm, welches dies wieder ermöglicht. Zur besseren Übersicht sind die getippten Kommandos grün hinterlegt:

$ openssl s_client -host www.gmx.de -port 443
CONNECTED(00000003)
depth=0 /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDUzCCArygAwIBAgIQSrsfqH7F4QWACHs9HWpPkzANBgkqhkiG9w0BAQQFADCB
zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh
d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl
cnZlckB0aGF3dGUuY29tMB4XDTA2MDIxMDA5NTUxNloXDTA3MDIxNzA4NTcwMVow
WDELMAkGA1UEBhMCREUxDzANBgNVBAgTBkJheWVybjEPMA0GA1UEBxMGTXVuaWNo
MREwDwYDVQQKEwhHTVggR21iSDEUMBIGA1UEAxMLd3d3LmdteC5uZXQwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBALv4J7mPoIhpMzqWmGEJKIxLlkD/Y4bKhXGP
EN11bdPPL1xcaCB95+r1lW4yvrC+NOQRre/Zt1vvXUtw+CKjzWL17xk5ORxejx5d
WCaZ+AtjKL3j7PrZkErx7X7ZqNcRgmPn2bfPfYnYR3gjp7AJitslmb+5Cp2a7dfo
pjYGOEnbAgMBAAGjgaYwgaMwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC
MEAGA1UdHwQ5MDcwNaAzoDGGL2h0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQ
cmVtaXVtU2VydmVyQ0EuY3JsMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYW
aHR0cDovL29jc3AudGhhd3RlLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB
BAUAA4GBABrINqdDTKfUd7BTpZLl4i0zHzWCff851588VxUL8+3OUqIHgTzdvWmx
9JeM8RoiCXfX84dt5y3pdeYi9FWJM5rBRxbijzw3f5zSyJloz7xSpV08F/Ii+svs
MKUhTkNSbMwa9vnWIogK4prbUj0yHfCrdsZLmHI4zAliK0e8lHfF
-----END CERTIFICATE-----
subject=/C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=www.gmx.net
issuer=/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
---
No client certificate CA names sent
---
SSL handshake has read 1419 bytes and written 322 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 67DE63728E1EF1E860BFE2B8E54A65EA52DA8AFA8F5D3A202746A36D2BCC5558
Session-ID-ctx:
Master-Key: E6C37C6E7C56A8C95366C26102A41BE8233E079A4371AA20996EFF7DC539BDCE424F326A3F494F81C3CA03712D91F08E
Key-Arg : None
Start Time: 1165442910
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
GET / HTTP/1.0
HOST: www.gmx.de

HTTP/1.1 302 Found
Date: Wed, 06 Dec 2006 22:08:42 GMT
Server: Apache
Location: https://www.gmx.net/de/
Vary: Accept-Encoding
Content-Length: 207
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://www.gmx.net/de/">here</a>.</p>
</body></html>
closed