Re: Immernoch das VPN-Problem

Hallo Dejan,
hallo FreeBSD-Gemeinde,

da es wohl noch kein anderer getan hat oder vielleicht mal wieder
alle im Urlaub sind, werde ich mir nun die paar Minuten Zeit nehmen
um das Thema mal nach meinen Erfahrungen zu erläutern.

Zuallerersteinmal: Tunnel != Transport -> wer hier schon
steckenbleibt sollte sich evtl. nochmal grundlegend mit IPSec
auseinandersetzen.

doch nochmal eine kurze Erläuterung:
mit IPSec ist es zum einen möglich einen Tunnel zwischen zwei
Netzwerken aufzubauen, via Internet. Dieser Tunnel ist verschlüsselt,
die Gateways authentifizieren sich gegenseitig und alles ist (richtig
konfiguriert) "sicher". Das Verfahren eignet sich prima für die
Verbindung von Hauptquartier und Aussenstelle in Assamoa oder
wasweissichwosonstnoch.

Das wovon hier doch so oft geredet wird ist die Einwahl in ein VPN
mittels IPSec und L2TP. Das ganze ähnelt dann in etwa PPTP, der
Client wählt sich per PPP im Firmennetz ein, bekommt eine IP und ist
"virtuell" im LAN. Mit Proxy-ARP funzt das auch ganz prima.

Nun, jetzt ist es wichtig die 2 Dinge die hier eine Rolle spielen zu
verstehen.

Zum einen gibt es da L2TP, oder auch Layer 2 Tunneling Protocol
(IIRC). Hierbei wird eigentlich nur eine PPP-Verbindung statt über
eine serielle Verbindung (ja Modem) über TCP/IP geleitet, also
Internet. Problem ist hierbei die Sicherheit, denn diese Art der
Verbindung ist unverschlüsselt. Wer sich vielleicht mit DSL
beschäftigt hat, kennt PPPoE (over Ethernet) und weiss das das Zeug
lediglich zur Authorisierung dient (und zum RADIUS-Accounting). Bei
Verschlüsselung wären wir aber...

...andererseits auch schon beim zweiten Teil des ganzen, nämlich
IPSECs Transport-Mode. Dabei wird eine normale Verbindung mit IPSec
signiert und verschlüsselt. Die Pakete können so weder mitgelesen,
noch verfälscht werden (wichtiger Nachteil kommt später).

Okay, was technisch nun passiert... der L2TP-Tunnel wird in einen
IPSec-Transport gesteckt und so habt ihr die Einwahl mit Winblows
oder Mäckos.

Zur Umsetzung...

Als erstes brauchen wir einen Kernel mit IPSEC (in eurer Kernel-Konfig):
<!--
options IPSEC
options IPSEC_ESP
--!>

(Vorsicht bei Multiprozessorsystemen, IPSec braucht NOCH das
Giantlock, womit ihr möglicherweise anderswo
Geschwindigkeitseinbussen in Kauf nehmen müsst. Aber Ahnung hab ich
davon auch noch nicht, mein 2ter Prozzi is noch neu)

des weiteren braucht die rc.conf einige Zusätze:
<!--
# IPSec kernel option (for use with racoon)
ipsec_enable="YES"
ipsec_file="/etc/ipsec.conf"
--!>

und die ipsec.conf:
<!--
flush;
spdflush;

spdadd 0.0.0.0/0[any] 10.1.2.3/32[1701] udp -P in ipsec
esp/transport//require;

spdadd 10.1.2.3/32[1701] 0.0.0.0/0[0] udp -P out ipsec
esp/transport//require;
--!>

Kurze Erläuterung: wir fordern jede eingehende Verbindung an UDP-Port
1701 auf, mittels IPSEC geprüft zu werden. Gleiches legen wir für
ausgehende Verbindungen fest. Hinter Port 1701 verbirgt sich bald der
L2TP daemon.

da statische Keys IPSEC fast überflüssig machen würden, brauchen wir
noch ein Proggi was Keys verwaltet und neu aushandelt. Racoon und
ISAKMPD sind die mir bekannten Implementationen. Beide finden sich in
den Ports, die Vor- bzw. Nachteile der jeweiligen Proggis möchte ich
jetzt nicht ausführen, ich habe mit racoon allerdings bis jetzt ganz
gute Erfahrungen gemacht. OpenBSDs ISAKMPD werde ich mir bei Zeiten
hoffentlich noch ansehen können.

für racoons Config schaut bitte in die mitinstallierte sample bzw.
auf http://www.ipsec-howto.org/ wo das ganze auch ausführlich
beschrieben wird.

für die Authentifizierung sei noch gesagt, dass ihr zwischen einem
Pre-Shared-Key/PSK oder SSL-Zertifikaten wählen könnt. Letztere
bieten die höhere Sicherheit, bedürfen aber auch wesentlich
aufwendigerem Handling. Für den Anfänger empfehle ich umbedingt PSKs,
die auch nicht zwingend auf eine IP gebunden werden müssen (Hostnamen
oder Emailadresen tuns auch), was bei dynamischen Adressen sicher
interessiert.

okay, racoon läuft soweit, jetzt braucht es noch den L2TP-daemon.
Dort habt ihr die Wahl zwischen L2TPD und sl2tps.

Ersterer ist an den pppd gebunden und unterstützt so zumindest unter
FBSD MSCHAPv2-Authentifizierung nicht. Klar das MS für Micro... steht
und meist zwingend bei Winblows erforderlich ist. MacOSX Client
verwendet es glaub ich auch und umstellen kann mans wieder mal nicht.

sl2tps ist da einiges besser, denn es verwendet wie MPD (bei PPTP zu
empfehlen) netgraph fürs PPP, was wiederum problemlos mit MSsowieso
umgehen kann. Die Konfig besteht auch nur aus einer simplen XML-
Datei, weshalb es mein favorisierter Daemon für L2TP ist. Vielleicht
kommt bald ja auch noch RADIUS-Auth, dann bin ich glücklich.

den sl2tps konfiguriert ihr in /usr/local/etc/sl2tps/config.xml.
Ändert bind_ip, inside_ip, dns_servers, wahlweise nbns_servers sowie
ip_pool_start und ip_pool_size und der Server ist weitestgehend
eingerichtet. im Key <users> am Ende der Datei findet ihr dann auch
die Benutzerangaben.

Abschliessend, das Testing:
ich habe zu oben geschriebenem Zeug glaub ich ein Jahr gebraucht und
das mit Abstand wichtigste beim ganzen war das debuggen. Setzt racoon
im Daemonmode so das er an eurer Console bleibt und ihr lesen könnt
was er zu sagen hat. Gleiches gilt für sl2tps. Bei beiden sind
Fehlermeldungen eigentlich "relativ" aufschlussreich.

Letztes Wort zu NAT...
IPSec-Pakete lassen sich wie gesagt nicht verändern (Checksumme wird
bestimmt und geprüft). Das ist eine gute Sache, verhindert aber das
ein NAT-Router die Ziel-IP eines Paketes umschreiben kann. Manch ein
NAT-Router leitet nach Einstellung Pakete deshalb unbearbeitet
weiter. Die Alternative heisst NAT-Traversal und beschreibt eine Art
wie Pakete durch einen NAT geschleust werden. Die aktuelle Lösung
verfährt in dem die IPSec-Pakete in UDP-Pakete verpackt werden und
der UDP-Strom wandert ganz normal durchs NAT. M$ und Cisco haben
AFAIK soetwas nach eigenen Vorgaben implementiert, Apple hats mit
deren racoon-Version auch gemacht, alle waren aber bis jetzt nicht
genormt, drafts gibts dazu aber inzwischen.

OpenBSD isakmpd hat in OpenBSD 3.6 NAT-T erfahren. Linux racoon-
basierte IPSEC-Tools können selbiges inzwischen auch. Beide
Implementationen können aber (!!!) nur IPSEC-Tunnel (Tunnel nicht
Transport!!!!!) durch NAT-T schleusen. Für unser Dialup ist also auch
irrelevant, das im FreeBSD entsprechende Kernel-Anpassungen noch
fehlen (siehe doch mal einer NetBSD).

Wo also nun das Problem? Sobald ein NAT mit im Spiel ist und dieser
entweder IPSEC (Link-Protokoll auf Ebene wie IP zB) nicht unterstützt
oder nicht korrekt durchschleust gibts auch kein Dialup ins VPN. Da
hilft bis jetzt nur ein Fallback auf PPTP aka den MPD. Damit solltet
ihr euch seperat auch noch mit beschäftigen evtl, gerade die
bekannten Exploits sollten euch bei der Entscheidung gegenwärtig sein.

es war ein langer anstrengender Tag und hoffentlich wird das hier
jetzt irgendwo archiviert, zumindest bis ich dazu gekommen bin meine
Website entsprechend auf Vordermann zu bringen. Achso, http://
www.ipsec-howto.org/ möchte ich hier nochmal als geballte Quelle zum
Thema nennen, auch wenns Linux-orientiert ist. Gibt noch weitere
Howtos, gerade zum Swan, aber für Verständniss von IPSec allgemein
hilfts echt weiter.

noch Fragen?

Philon

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 28 Jul 2005 - 21:24:38 CEST