05. 10

Ja, manchmal Frage ich mich doch, was haben Leute geschluckt die sich sowas ausdenken wie das LAN an der Technischen Universität Darmstadt. Eigentlich dachte ich im ersten Moment, das sieht aus wie in Heidelberg oder Mannheim, man verbindet sich per WLAN, bekommt eine IP per DHCP und landet erstmal in einem "Toten Netz", welcher als Tor zur Außenwelt einen VPN-Server anbietet. Traditionellerweise einen von Cisco, sprich man kann sich seinen Netzwerkstack mit dem Originalclient total durcheinanderbringen, oder aber den vpnc verwenden und (fast) glücklich werden. Denn er unterstützt leider immernoch kein rekeying, so dass man im Normalfall nach 8h Connection rausfliegt.

So, der vpnc war Dank einer Infoseite der TUD problemlos einzurichten, aber dann war immer nach 5Minuten Ende der Verbindung. Aufgrund der Leasetime von 300s begann ich, den Fehler im DHCP-Umfeld zu suchen. Die Aktion war sehr amüsant, in ein paar Minuten sich möglichst viele Ausgaben übers IRC schicken lassen, nachdenken, und wenn die Verbindung das nächste mal steht Lösungsvorschläge unterbreiten, bis das ganze tat. Denn das Problem hatte nicht ich, sondern meine Freundin - und während der Vorlesung konnten wir schlecht telefonieren. Ausschlaggebend für die erste Verwunderung waren IP des DHCP-Servers sowie die Routen:

# dhclient ath0
[...]
DHCPACK from 130.83.156.7
[...]
# ip r l
130.83.84.0/23 dev ath0 proto kernel scope link src 130.83.84.164
default via 130.83.85.254 dev ath0

Dem technisch versierten Leser mag hier auffallen, dass der DHCP-Server nur über das Default-Gateway erreichbar ist. Diese Konstruktion läuft so schonmal nicht ohne Spezialkonstruktionen wie dhcp-relay, da der DHCPREQUEST immer an 255.255.255.255 geht, und somit nicht über das lokale Netz hinauskommt. Aber es läuft soweit noch - bis der vpnc gestartet wird. Denn dann sehen die Routen auf einmal folgendermaßen aus:
# ip r l
130.83.253.21 via 130.83.85.254 dev ath0 src 130.83.84.183 mtu 1500 advmss 1460 hoplimit 64
130.83.84.0/23 dev ath0 proto kernel scope link src 130.83.84.183
default dev tun0 scope link

Schön, die Default-Route geht nun durch das VPN. Eigentlich ist das so auch erwünscht, denn ohne VPN gibt es kein Internet. Allerdings ist nun auf einmal auch der DHCP-Server nicht mehr erreichbar. Und somit wird braverweise die IP nach Ablauf des Leases nicht mehr verwendet.

Die Lösung für den Moment war, eine direkte Hostroute zum DHCP-Server zu erzeugen, welche über ath0 direkt geht: # ip r a 130.83.156.7/32 dev ath0, aber das ist auf Dauer bei jedem neuen Connectversuch auch nicht das gelbe von Ei. Also habe ich flott auf einer Bahnfahrt ein kleines Hook-Skript für den dhclient3 geschrieben, welches in /etc/dhcp3/dhclient-enter-hooks.d/ abgelegt auf eine IP aus dem TUD-Netz prüft und wenn nötig, die Route selbst setzt bzw. auch wieder löscht:

$ cat /etc/dhcp3/dhclient-enter-hooks.d/tudvpn 
#!/bin/sh

# This set will set a static hostroute to the DHCP-Server, because these
# fscking admins made the DHCP-Server only recheable via the default-gw,
# which will be changed by the vpn-client. So without this ugly construction,
# you will loose your IP and connectivity after 300s (the lease-time).
# Just put it into /etc/dhcp3/dhclient-enter-hooks.d

# possible optimization: check for domain-name or other tud-specific values
setroute(){
        # check for university-ips
        if [ -n "$(echo $new_fixed_address | grep -e '130\.83\..*')" ]; then
                /sbin/ip r a $new_dhcp_server_identifier/32 via $new_routers dev $interface
                echo "/sbin/ip r a $new_dhcp_server_identifier/32 via $new_routers dev $interface"
        fi
}

delroute(){
        # delete old route, if existing and university
        if [ -n "$(echo $old_fixed_address | grep -e '130\.83\..*')" ]; then
                /sbin/ip r d $old_dhcp_server_identifier/32 dev $interface
                echo "/sbin/ip r d $old_dhcp_server_identifier/32 dev $interface"
        fi
}

case "$reason" in
        BOUND|REBOOT)
                # set route if needed (checked in function setroute)
                setroute
        ;;
        RENEW|REBIND)
                # sth could have changed, recheck everything!
                if  [ $new_fixed_address != $old_fixed_address ] || \
                        [ $new_dhcp_server_identifier != $old_dhcp_server_identifier ] || \
                        [ $new_routers != $old_routers ]; then
                        delroute
                        setroute
                fi
        ;;
        EXPIRE|FAIL|TIMEOUT)
                # routes no more valid!
                delroute
        ;;
esac

Seltsamerweise konnte ich aber trotz längerer Suche keine Beschreibung dieses Problems finden, sondern nur andere Leute, die sich über die Instabilität der Verbindungen aufregen.

Tags für diesen Artikel: ,

Trackbacks


Keine Trackbacks

Kommentare

Ansicht der Kommentare: (Linear | Verschachtelt)

Full ack! Das hrznetz ist sehr instabil.

Ich habe allerdings gute Erfahrungen mit der WPA-EAP-Authentifizierung über die essid TUD gemacht. Die Verbindung dort ist deutlich stabiler. Jeder Accesspoint hat zwei MAC-Adressen. Auf der niedrigeren liegt das TUD-Netz. Eine Anleitung findet man hier:

http://www.tu-darmstadt.de/hrz/netz/wlan/wireless.shtml
#1 chaotika (Homepage) am 01.11.2006 12:52
Komisch ... das mit der instabilen Verbindung kenn ich auch .. allerdings nicht bei mir....

ich hab mit dem hrz netz noch nie probleme gehabt - weder unter windows noch unter linux mit vpnc

insofern ist das prob. evtl. nicht nur beim hrz zu suchen.
#2 SmilingJ (Homepage) am 15.11.2006 20:29

Kommentar schreiben


Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

Pavatar, Gravatar, MyBlogLog, Monster ID, Pavatar Autoren-Bilder werden unterstützt.
HTML-Tags werden in ihre Entities umgewandelt.
BBCode-Formatierung erlaubt