|
Broken stuff
|
 Geschrieben von Beat Rubischon (Link) am
Sonntag, 4. Juni 2006, 17:30
aus dem patch-patch-patch dept.
Eigentlich wollte ich "rasch" für meinen neuen $BROETCHENGEBER eine Firewall mit VPN-Zugang bauen. Doch dann wurde ziemlich viel Arbeit daraus...
Nach dem berüchtigten hackme, dem dreistufigen Firewallkonzept mit den Vulkannamen, der vivian, dem funny und zuletzt der schilt fühlte ich mich fit genug, eine Box zu bauen. Dual Uplink, eine DMZ, ein LAN, IPSec/L2TP.
Das Routing kriegte ich problemlos hin, das Firewalling gab zu kauen, war aber auch machbar. Doch dann kam IPSec. Wir haben ja zwei Implementationen unter Linux - NETKEY aus dem KAME Projekt, welches direkt mit dem 2.6er Kernel ausgeliefert wird und KLIPS aus dem OpenSWAN Projekt. Ich entschied mich erst für NETKEY, da ich dieses bereits kannte und es auf mich den bedeutend besseren Eindruck macht als KLIPS.
Tja, unter NETKEY funktioniert IPSEC im Transport Mode nicht. Die ausgehenden Pakete verlassen die Box unverschlüsselt...
KLIPS bietet teilweise ziemlichen Aerger im Routing. Ich wollte im Tunnel zu mir nach Hause die DMZ nicht verschlüsseln - da sie aber über denselben Gateway geht, wurden auch diese Pakete an ipsec0 gesandt und da verworfen. Nichts einfacher als das - man macht eine transparent Policy. Sobald das erste Paket diese Policy traversiert gibt es einen Kernel Panic...
Ich habe mir jetzt mit einer alternativen Routing Tabelle beholfen, in der der Traffic aus der DMZ nicht durch ipsec0 geschickt wird. Ich hoffe, dass ich das in zwei, drei Jahren noch begreife:
ip route flush table 1
ip route show table main | grep -v "dev ipsec" \
| while read route; do
ip route add table 1 $route;
done
ip rule add from 192.0.2.0/24 table 1 priority 200
ip route flush cache
Was mich erstaunt sind die vielen vagen Beschreibungen dieser Fehler in den Mailinglisten. Niemand ist wirklich in der Lage, die Probleme zu tracken und die Entwickler scheinen sich nicht sonderlich darum zu scheren. Macht niemand mehr IPSec unter Linux? Benutzen alle die steinalten Distributionskernel und sehen daher die Probleme nicht?
Freundlicherweise fand ich nicht nur unter Linux Probleme. Auch meine melone unter MacOS X macht Müll - sobald der pppd per L2TP das Passwort Challange mit dem Server ausgetauscht hat, wird die IPSec Session beendet und die Pakete verlassen das System fortan unverschlüsselt. Keine Ahnung, ob das nur auf meinem System der Fall ist oder ein generelles Problem mit Tiger darstellt - auf alle Fälle ist es ein ärgerlicher Bug, dem man stundenlang nachrennen kann.
Die einzige Seite, die problemlos mitspielt, ist Windows. On Board Client starten, shared Secret eingeben, Login + Passwort eintippen und die Verbindung steht. Warum zum Geier schaffen wir das in der Open Source Welt nicht mehr?
Permalink
|
TrackBack Pings:
- Aepfel und Wasser: Erster Kontakt
Submittet auf
Studiblog
am 2006/06/05 13:54:02.172 GMT+2
Beats Artikel, in dem er einen kleinen Bug in MacOS X beschreibt, hat mich spontan dazu veranlasst, \über meine Erfahrung der letzten Woche mit ebendiesem MacOS X zu berichten.
Eine nette Kollegin hatte nämlich ein kleines Problem: Wenn sie ihren mp3...
|
|
|