Re: Freeswan/IPSec
Torsten Puls schrieb:
> Auf einem Rechner läuft Debian Woody mit Kernel
> 2.4.18 und auf Laptop Debian Sid Kernel 2.4.20.
> Freeswan ist gepatcht und Kernel sind neu kompiliert.
Mit welchen Patch? Patch und Userland sollten zueinander passen. D.h.
immer den Patch der Distribution nehmen. Debian hat eine Reihe
Erweiterungen (so in etwa a la SuperFreeswan) drin.
> Mit ifconfig sehe ich das ipsec0 Interface. Auf beiden PC's.
Das heisst nur, dass das ipsec-Kernelmodul vorhanden ist.
> hort:# iptraf -i ipsec0
> hort:# Specified interface not supported
> Da ist doch schon irgendwas faul.?
Ja, iptraf ist etwas störrisch mit den Schnittstellen. Nimm tcpdump, das
reicht um zu sehen, ob das Richige passiert.
> ein tail -f /var/log/syslog bringt folgendes währen eines
> /etc/init.d/ipsec restart:
> Jun 16 10:43:12 laptop ipsec_setup: KLIPS debug `none'
Das sagt nicht viel, wenn kein Debugging eingeschaltet ist. Ausser, dass
mir die Auflistung der Connections fehlt.
> klipsdebug=none
> plutodebug=none
Hier mal Lesestoff aktivieren: =all
> conn roadwarrior
> left=192.168.1.250
> leftsubnet=xxx.yyy.zzz.16/255.255.255.128
Das sieht falsch aus. Wäre jetzt zuerst ein Schaltbild der Verbindung
sinnvoll. Inklusive IPs und Firewalls. Da wirst Du noch ein ziemliches
konzeptionelles Kuddelmuddel haben, das zuerst strukturiert werden
muss: IPSec geht nicht über NAT-Firewalls. Dazu braucht es den NAT-T
Patch, der ist nicht in Woody, usw.
> auto=add
Kannst Du auf dem Roadwarrior auch direkt starten
> pfs=yes
Kannst Du weglassen, da sowieso Standardverhalten von Freeswan. Ist nur
interessant, wenn man es explizit auf "no" haben muss.
> meine ipsec.secrets:
> : RSA /etc/ipsec.d/private/hort.domain.de.key "passwort"
> HIER ist doch auf jeden Fall etwas verkehrt. Ich schreibe doch nicht
> das Passwort da rein oder was?
Doch das ist richtig.
Es kommt das Passwort rein, dass Du beim Generieren der Zertifikate
gewählt hast. ipsec.secrets sollte daher nur für root lesbar sein.
> Wie mache ich die Zertifakate?
> vi /etc/ssl/openssl.cnf
> vi /usr/lib/ssl/misc/CA.sh
Sieht bei kurzem Überfliegen auch gut aus. Wenn man mehr als zwei
Zertifikate hat, lohnt es sich openssl.cnf noch etwas ausführlicher zu
bearbeiten (Defaultwerte) und die Pfade der CA auf eigene Werte zu
setzen.
--
rainer@ellinger.de
Reply to: