[linux-l] VPN

[Steffen Dettmer]

* Stephan Uhlmann wrote on Mon, Jul 08, 2002 at 19:12 +0200:
> Der Client-PC laeuft unter Windows 2000. Sie kommt mit QDSL ins Netz, die 
> Firma ueber eine Standleitung. Das LAN ist ueber ein privates Netz hinter 
> einem NAT Gateway mit Packetfilter verbunden. Der Samba-Server steht 
> innerhalb des LAN und ist nicht von aussen erreichbar (und soll es auch 
> nicht).

Soweit keine ungewöhnliche Config.

> Kurze Frage: hat schonmal jemand mit sowas Erfahrung gemacht und koennte Tips 
> geben? Mein Wunsch waere, dass Client sich fuer den Samba-Server wie ein 
> interner PC verhaelt, also auch eine interne IP verwendet. Irgendwie muss er 
> ja auch auf den internen DNS-Server zugreifen koennen, um den Server 
> ueberhaupt zu finden.

Ja, das geht mit VPN :)

> Ich schwanke zwischen PPTP (Poptop) und IPSec (FreeS/WAN), daher wuerde sowas 
> wie "PPTP ist zu unsicher, nimm IPSec" oder "IPSec ist zu kompliziert, PPTP 
> sollte fuer dich reichen" schon helfen.

Mit PPTP hab ich mich nie eingehend beschäftigt, da für mich die
ganze Arbeit sinnlos ist, wenn es nicht mal sicher ist :)

Ich fand IPSec auch nicht so kompliziert. Natürlich sollte man IP
verstehen und Routingtabellen und sowas, wenn man damit
anfängt...

Um das mal abzukürzen: Du möchtest IPSec ESP im Tunnelmode.
Nebenbei ist's auch das sicherste, und ich finde das einfacher zu
verstehen, als Transportmode. Tunnel heißt, die orginalen IP
Packete werden in neue IP Packete ein- und später wieder
ausgepackt. Klingt logisch, oder? :)

Ich hab bisher immer FreeS/WAN verwendet (ist bei SuSE dabei).
Das erste Setup dauert immer am längsten, besonders, wenn man
Firewalls hat :) Hier muß man wissen, daß IPSec neben dem IP
Protokoll UDP auch die Protokolle 50 und 51 kennt (ESP und AH).
Wenn die QDSL Leitung ne dynamische IP hat, muß man einen
sogenannten Roadwarrior einrichten. Das heißt, das zunächst die
Firewall UDP Port 500 und IP Protokoll 50,51 von jeder (in Frage
kommenden) IP erlaubt. [Wenn der Unterschied zwischen Potr und
Protokoll nicht ganz klar ist, wie ich's erstaunlich oft erlebt
hab, gleich nachlesen :)].

Das zweite Problem heißt NAT/Masquerading. Theoretisch kriegt man
ESP Tunnel da durch; aber ich würde es lieber lassen. Es gibt da
dann jedenfalls einen Kernelpatch. Ich hab mal auf Mailinglisten
gefragt, ob IP-forwarder auch funktionieren, sollte eigentlich,
aber egal.

Wenn Du es Dir nicht unnützt schwer machen möchtest, verwendest
Du IPSec dort, wo auch NAT passiert. dann mußt Du überhaupt nicht
trixen. NAT macht sich überhaupt nicht bemerkbar, und Du bist auf
der richtigen Maschine (die mit externem Internetzugang und
gleichzeitiger am internem Netz). In diesem Fall mußt Du wirklich
nur einen Tunnel in /etc/ipsec.conf eintragen und zwei Keypaare
erzeugen. Hab bißchen was dazuauf http://sws.dett.de/.

So einem Tunnel mußt Du sagen: Was soll getunnelt werden? Das
sind meistens zwei Netzwerke. Dann natürlich die Endpunkte (also
dessen IPs). Wobei wir beim nächsten Problem wären: Vermutlich
hat Deine Kollegin kein internes Netz und kein Linuxrouter
rumstehen. Wenn Du es schmerzfrei haben möchtest, kaufst Du ihr
PGPNet. Auch darüber hab ich auf http://sws.dett.de/ - sogar mit
PGPNet Screenshoots :) (Ich geh mal davon aus, das sie Win hat,
wegen Samba). Zum testen sollte auch ne PGP Net eval reichen
(free geht nicht, weil kann kein Tunnelmode; klar, das was Spaß
macht, kostet...). Gab da mal 30 Tage Versionen. Für $100 oder
so, geht ja noch, finde ich.

Beim Debuggen mußte immer gut nachdenken, damit Du Dich nicht
verrennst. Auf Deinem gateway solltest Du extern nur ein paar UDP
500 Packete sehen, und wenn SA da ist (also der Tunnel steht),
solltest Du (fast) nur Proto 50 Packete sehen. Also mit tcpdump
nachgucken. Dann noch ein Tip: Die freeswan logs sind hilfreich,
aber schwer verständlich, wenn man IPSec nicht kennt. Die PGPNet
Log/infos kann man hingegen total vergessen. Da steht dann meist
nur ein kompliziert formuliertes "geht nicht".

Weitere wichtige Begriffe: proposal: Ein Vorschlag, mit welchen
Parametern (Crypto-Verfahren, Schlüssellängen, Expirezeiten, ...)
gearbeitet werden soll. Diese Vorschläge werden ausgehandelt. Oft
kriegt man ein "no proposal choosen". Das heißt, es gab keine
übereinstimmenden Vorschläge - man konnte sich nicht einigen. Das
heißt fast immer, daß die PGPNet Seite anders eingestellt ist,
als die Freeswanseite. Dann noch mal die ganzen Screenshoots
durchklappern. Proposals gehen auch schief, wenn sich beide
Seiten über die zu tunnelnden Netze nicht einig sind. Das muß
alles genau gleich sein - wie auch sonst!

SA: security association. Das ist das ausgewählte Proposal (inkl.
aktuellen Sessionkeys und noch so Kram). Wenn SA, hat proposal
handshake geklappt. Sobald ein SA da ist, wird der Tunnel
verwendet. Problem ist nur, daß manchmal eine Seite SA hat, die
andere nicht. Da muß man dann individuell gucken, passiert sehr
selten, sowas.

Bei PGPNet immer mit manuellem Starten anfangen, und mit TCP dump
gucken, ob's was macht. Manchmal gibt das PGP Net auf - ist
ärgerlich, wenn man gerade die richtige Möglichkeit probiert, und
wegen nicht-Versuchens-und-geht-nicht verworfen hat. Das ist dann
ärgerlich. Grundsätzlich: nicht probieren oder basteln! Alles
sorgfältig einstellen, dann klappts beim ersten Mal... Jedenfalls
kannst Du nicht alle paar Sekunden einen Versuch machen. Das
klappt nicht, wird aber erstaunlich oft probiert. Das geht dann
gründlich schief, weil beide Seiten in verschiedenen States sind.
Die eine Seite wartet auf Proposalantworten der letzten Sendung,
die andere schickt schon neue... Geht nicht. Abhilfe schafft
hier: kurz warten (eltiche Sekunden), dann ipsec stop, PGPnet
stop, warten, mit tpcdump gucken, ob Ruhe ist, dann ipsec start,
warten, PGP Net connect.

So, viel Erfolg - mit der detailierten Beschreibung ;)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.