[linux-l] VPN

[Steffen Dettmer]

* Stephan Uhlmann wrote on Fri, Jul 12, 2002 at 15:37 +0200:
> On Friday 12 July 2002 08:58, Steffen Dettmer wrote:
> > Beim Transportmode werden die IPs im Prinzip nicht geändert. Das
> > nützt Dir nix, weil ein Packet an den SambaServer dann ja ne
> > 192.168.x.x ZielIP kriegen würde (also ein IPSec Packet), was im
> > Internet nicht geroutet werden würde. Weiterhin müßte der
> > Sambaserver das IPSec machen, nicht der Router. Das geht nicht
> > mit Masqurarding, klar.
> 
> Stimmt. Zuerst dachte ich ich koennte das machen indem mein
> Gateway erst die IP Pakete verschluesselt und dann NATtet (wie
> ist da das Verb? oder masqueradet?). 

maskiert? Masqueriert?

> Oder andersrum. Kommt aufs gleiche drauf raus.

Dabei (==NAT) werden aber die IP Header verändert. Veränderte IP
Header werden i.d.R. von IPSec erkannt und als Verfälschungen
verworfen (weil Header-hash ist falsch, also Paket verfälscht
oder nicht authentisch). Das ist aber bei ESP-Tunnel-Mode
nicht so, weil die signierten IP Header in den ESP Frames
eingepackt sind, und daher nicht durch NAT verändert werden. Aber
wenn man eh ESP Tunneling macht, möchte man meistens kein NAT,
weil ja dadurch der Kram so umständlich wird. Und so ohne
weiteres kriegt man nur eine gleichzeitige Verbindung durch NAT
(Linux) durch, weiß nicht, ob überhaupt, weil beim Handshaking
schon Probleme auftreten können. Jedenfalls alles ohne den
komischen Patch ganz komisch, und mit dem komischen Patch immer
noch nicht ideal - finde ich jedenfalls. Aber egal. Eigentlich
war genau das, was ich abkürzen wollte :)

> Aber denn muesste ich Portforwarding oder so einrichten um den Sambaserver 
> von aussen erreichbar zu machen

Das ist nun ganz falsch. Portforwarding (also PORTforwarding)
geht so eh nicht, höchstens was ähnliches, weiß nicht, ob Linux
chains/tables oder masqadm sowas überhaupt können. Jedenfalls
würde man dann die Protocol 50 Packete und UDP 500 forwarden,
damit kann Samba aber überhaupt nix anfangen. Also müßte man die
dann zum VPN GW forwarden (was natürlich auf der selben Hardware
wie Samba laufen könnte). Jedenfalls "öffnet" man damit nix, denn
nur gültige, authentische IPSec Packete würden letzlich den Weg
zum Sambaservice machen. Aber das ist komplizierter, wenn man das
bauen muß. 

Jedenfalls ist ESP Tunnel auf den NAT Maschine einfacher,
sauberer, stablier und übersichtlicher. Also möchtest Du bestimmt
genau das :)

> und den internen DNS-Server am besten auch

Wieso?
 
> und den Exchange-Server (Nicht schlagen! Ich bin nicht Schuld!)
> und ... und .. und. Nicht so elegant wie tunneln, ja.

Nein, das haut so nicht hin. Wenn Du ESP transport irgentwie da
rein kriegen würdest, wäre es sicher. Aber das wäre
routingtechnisch kompliziert. Tunnel ist hier einfach: einfach ne
Route eintragen, die wird dann vom VPN GW (hier ist's ganz
einfach, weil das auf der Maschine läuft, die eh schon default-GW
ist) eingepackt und auf der anderen Seite (vom PGPNet) wieder
ausgepackt. Der Tunnel selbst ist für die Server transparent, daß
heißt, ein traceroute "sieht" nur das VPN GW und dahinter sofort
den Clienten - diesen "troz" NAT mit seiner "internen" IP. Also
genau das, was Du möchtest. Es sieht so aus, als ob der Client
direkt hinter dem VPN GW wäre. Fetzt, was?

> > Um das mal abzukürzen: Du möchtest IPSec ESP im Tunnelmode.
> 
> Ok ;-)

Gut. Haben wir das abgekürzt :)

> > Hier ist mit Protocol kein OSI level 5+ Protocol gemeint, sondern
> > ein OSI-Level 4 Protocol, eines, das "neben" TCP und UDP liegt und
> > ESP oder AH heißt. Beide kennen keine Ports (aber innen liegende
> > weitere Header, z.B. wenn TCP, kennen dann Ports). TCP ist
> > numerisch 6, ESP 50, AH 51 IIRC. Diese Protocolnumber steht dann
> > im IP Header drin. Bei ner 6 oder ner 17 (UDP) gibt's dann z.B.
> > Ports.
> 
> Ok. Wenn das dein "Protokoll" ist, dann ist das was anderes als mein 
> "Protokoll". Verwirrende Namensgebung. Vielleicht sollte man zwischen 
> "Protokoll" (HTTP, FTP, Telnet usw.) und "Protocol" (das was so huebsch in 
> /etc/protocols aufgelistet ist) unterscheiden.

"Protokoll" heißt ja "nur", daß beide Seiten über etwas
vorgeschriebenes reden. Für Informatiker ist ein Protokoll nur ein
Algorithmus mit zwei oder mehr Akteuren :)

In beiden Fällen hat man eigentlich das gleiche: Daten werden in
einem bestimmten Format ausgetauscht. Einmal im ESP "Format",
anderes Mal im "Telnetformat". Dabei ist hier zufällig ein
Telnet-Format-Datenteil in ein ESP Format-Datenteil eingepackt,
also kann man davon sprechen, daß Telnet "über" ESP liegt.
Umgekehrt ist damit das ESP für Telnet nicht zu sehen, aber ESP
sieht telnet (aber versteht es natürlich nicht, es sind einfach
nur Daten). Das geht nach unten so weiter: ESP liegt über IP. IP
liegt über Ethernet, PPP. PPP liegt dann vielleicht über ISDN.
ISDN heißt dann aber sowas wie: synchrones PPP, welches wiederum
auf z.B. HDLC aufsetzt. Also Protokolle ohne Ende. Auch nach oben
hin muß bei dem TCP-Nutzprotokoll nicht Schluß sein; kann ja
sein, daß jemand eine HTTP-Verbindung hat, auf der XML läuft,
über das SOAP Messages übertragen werden. Da hat man schnell mal
5 oder mehr verschiedene Protokollschichten. Da aber die "unten"
immer transparent und die nach "oben" immer egal sind, kann man
tatsächlich damit arbeiten. Aber ist schon unheimlich spannend,
finde ich!

> Naja... jedenfalls danke nochmal. Ich hoffe ich finde bald mal Zeit das hier 
> dann auch aufzusetzen.

Mach das. Ich persönlich fand das nicht so schlimm. Hat aber beim
erstenmal gedauert, weil ich drei Firewalls dazwischen hatte, die
immer abwechselnd was geblockt haben. Aber das ist ein anderes
Thema :)

oki,

Steffen

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