cvsroot/docs/vpn.pod

=head1 Einfache VPN-Netzwerke


=head1 Einführung

=head2 Was ist ein "VPN-Netzwerk"

VPN steht für Virtuelles Privates Netz und bezeichnet den Zusammenschluss
mehrerer physikalischer Netze (oder Knoten) zu einem größeren. Die
einzelnen Teile des Begriffes bedeuten:

=over 4

=item Virtuell

VPN-Netze sind keine physikalischen Netze, sondern existieren nur
virtuell, indem sie sich bestehender Netze für den Transport
bedienen. Sie vermitteln lediglich den Eindruck, in I<einem>
abgeschlossenen Netz zu sein, daß wesentlich größer sein kann als ein
echtes Netzwerk (z.B. können die Teilnehmer über dne ganzen Erdball
verstreut sein).

=item Privat

VPN-Netze sind abgeschlossen, d.h. sie lassen keine Kommunikation mit
ausserhalb des Netzes gelegenen Knoten zu.

Dies schließt sowohl die Kommunikation von aussen (Angreifer können
keine Daten einschleusen), als auch die Kommunikation nach aussen (Daten
werden nicht nach aussen gegeben bzw. können nicht "abgehört" werden)
ein. Ausserdem muss ein VPN-Netz gegen Veränderung von Daten resistent
sein, d.h. es darf nicht möglich sein, Daten zu verfälschen.

Dies schließt nicht notwendigerweise die Resistenz gegen
Kommunikationsunterbrechnung ein. Garantierte Kommunikation können
natürlich auch VPN-Netzwerke nicht bieten.

=item Netzwerk

Unter einem Netzwerk verstehe zumindest ich einen Zusammenschluss mehrerer
bis vieler Rechner. Am einfachsten kann man dies mit einem einfachen
Tunnel erreichen, der zwei physikalische Netze miteinander verbindet und
von einem Teilnetz in ein anderes vermittelt.

(Ausserdem ist der Begriff "VPN-Netzwerk" doppelt gemoppelt, aber das
hat lange Tradition, siehe IFF-Format und Microsofts ungeschlagen
aussagekräftige "Neue Technologie"-Technologie).

=back


=head1 VPN-Netzwerke, eine Klassifikation

=head2 Tunnel vs. Netze

Die einfachste Möglichkeit, ein VPN aufzubauen, ist es, einen Tunnel
zwischen zwei physikalischen Netzen aufzubauen. Die beiden Teilnetze
werden durch den Tunnel verbunden und bilden das VPN.

Es gibt verschiedene gebräuchliche Tunnel-Typen, die man (unter anderem)
durch die Protokollebene unterscheiden kann, die sie tunneln:

=over 4

=item Applikationsebene, z.B. TCP

Dieser Tunnel transportiert nur ein einziges Protokoll, z.B. telnet, pop3
oder X11. Dadurch werden häufig Optimierungen möglich, z.B. besonders
gute Kompression oder die Weiterleitung von Authentifizierungsdaten
(ssh). Ausserdem sind sie meist sehr portabel und einfach zu
konfigurieren.

Ein Nachteil ist, das man nur ein eiziges Protokoll zur Verfügung hat und
für jedes weitere auch eine weitere Tunnel-Lösung benötigt.

=item Protokollebene, z.B. IP

Hierbei wird eine ganze Protokoll-Suite getunnelt, z.B. das
Internet-Protokoll. Da die meisten Netzwerkapplikationen heute über IP
miteinander kommunizieren können, deckt dies die meisten Anwedungen ab.

Diese Art Tunnel benötigen etwas mehr Planung, da sich die Teilnetze nicht
einfach überschneiden können und das Routing zwischen den Teilnetzen
festgelegt werden muss.

Grundlage für Tunnelsoftware ist das Vorhandensein eines sogenannten
C<tun> oder C<tap>-Netzwerkgerätes, über das sich Pakete abgreifen bzw.
einspeisen lassen.

=item Netzwerkebene, z.B. Ethernet

Man kann noch eine Ebene tiefer ansetzen: Statt zwischen zwei
physikalischen Teilnetzen lediglich zu vermitteln, kann man sie verbinden,
so daß sie sich wie ein großes physikalisches Netz verhalten.

Im Falle von Ethernet kann man einen Ethernet-Tunnel an beiden Endpunkten
über Bridging an die physikalischen Teilnetze anschliessen. Da sich
das Gesamtnetzwerk fast wie ein physikalisches Netz verhät, kann man
z.B.  Rechner von einem Teilnetz in ein anderes verschieben ohne etwas
umkonfigurieren zu müssen.

Diese Tunnels sind am ineffizientesten, was den Overhead betrifft, da
sie die Verwaltingsinformation mehrerer Protokollschichten übertragen
müssen. Ausserdem wird häufig mit I<Broadcasts> gearbeitet (z.B. um einen
Rechner zu "finden"), die gerade bei größeren Netzen schnell die meist
geringere Tunnelbandbreite auffressen können.

=back


=head1 TCP-Tunnel

Dieser Abschnitt zeigt ein paar Beispiele für TCP-Tunnels. Sie verdienen
es kaum, "VPN-Netzwerk" genannt zu werden, aber sie lösen jeweils ein
Problem, und nur das zählt.

=head1 SSH-Portforwarding

Das SSH-Protokoll hat die r*-Protokolle und telnet im Internet fast
vollständig abgelöst. Nicht nur ist es sicherer, es hat auch weitaus mehr
Features als die Protokolle, die es ersetzt.

Eines der Features ist Port-Forwarding, mit dem man einen bestimmten
TCP-Port von lokalen Rechner zum entfernten weiterleiten kann, oder
umgekehrt.

=head2 Vorteile/Nachteile

=over 4

=item + Fast überall installiert, I<der> Standard schlechthin.

=item + Sehr hohe Sicherheit

=item + Einfache Installation und Benutzung

=item - Nur TCP

=back

=head2 Beispiele (OpenSSH-Syntax)

B<"Der POP3-Server steht in der Firma, ich will von aussen Mail abholen.">

Zugegebermaßen kein Fall für ein VPN, aber mit SSH einfach zu lösen:

  ssh -L113:mailhost.internal:113 -N bastionhost.internet

Dies erzeugt einen einfachen Tunnel vom lokalen port 113 (pop3) zum
Mailserver innerhalb des Firmennetzes. Da der Quellport (113) unter 1024
ist, kann nur Root dieses Kommando ausführen. Als User muss man einen Port
über 1024 benutzen. Zur Benutzung muss man seinem Mailprogramm "lediglich"
mitteilen, das der POP3-Server nun C<localhost> heißt.

B<"Meine neue Applikation ist fertig, jemand soll sie sich anschauen
können, ohne das ich meinen Webserver ins Internet stellen muss.">

Der folgende Aufruf erlaubt es einem Benutzer auf C<andereruser.internet>
auf meinen (hinter meinem Firewall befindlichen) Webserver zuzugreifen,
indem er C<http://localhost:8000/> auf seinem Rechner benutzt:

  ssh -R8000:localhost:80 -N andereruser.internet


=head1 IP-Tunnel

Ein IP-Tunnel bietet mehr Flexibilität als ein einfacher TCP-Tunnel. Und
ist auch etwas komplexer beim Einrichten.

Im folgenden gehe ich auf Tunnels mit SSH, ein Paket namens C<vtund> und
ein weiteres namens C<openvpn> ein, die alle einzelne Tunnels aufbauen
können.

=head1 PPP über SSH

=head2 Vorteile/Nachteile

=over 4

=item + Sehr einfach aufzusetzen

=item + Die benötigten Komponenten sind einfach zu beschaffen

Sowohl SSH als auch PPPD gehören zu jeder (allgemeinen)
GNU/Linux-Distribution.

=item + Ideal für Ad-Hoc-Tunnels

z.B. für kurzzeitige Veranstaltungen, bei denen der Tunnel noch manuell
überwacht werden kann.

=item - Eigentlich ungeeignet für IP

IP über TCP zu tunneln ist schlecht, da bei schlechter Verbindung sowohl
das Tunnel-TCP als auch das getunnelte Protokoll retryen. Dadurch wird die
Leitung schnell verstopft.

Bei guter Verbindung gibt es aber ausser einer gewissen Ineffizienz keine
größeren Probleme.

=item - Keine Stabilitätsrekorde

Startet man C<ssh> in C<screen>, per C<nohup>? Was passiert bei
Netzausfällen? Provider-Neueinwahl? Viele dieser Fragen lassen sich durch
verbessertes Skripting (killen des C<pppd>, starten per C</etc/inittab>
etc.) lösen aber es wird schnell kompliziert.

=item - Nur Punkt-zu-Punkt-Tunnels

Bei mehr als zwei Teilnetzen braucht man schnell serh viel Tunnels, die
man nicht einfach manuell verwalten kann.

=item - Total Unprofessionell

"Ich habe 13 Filialen damit vernetzt" klingt nicht wirklich überzeugend...

=back

=head2 Beispiele

Es kann so einfach sein:

   pppd pty 'ssh -t andererrechner.internet pppd nodetach' \
        nodetach passive 10.8.0.1:10.9.0.1

Diese Zeile baut einen PPP-Tunnel mit C<andererrecher.internet>
auf. Der lokale Rechner erhält die IP-Adresse C<10.8.0.1>, der
entfernte C<10.9.0.1>. Der obige Tunnel funktioniert auf meinen
Rechner wie angegeben, in der Praxis kommen manchmal noch Optionen wie
C<ipcp-accept-local> hinzu, oder der Pfad zum C<pppd> muss angegebn
werden.

Mit ein paar weiteren Zeilen kann man zwei Teilnetze auf C<eth0> verbinden:

   # lokal (ip kommt meistens aus dem iproute2-Paket)
   ip route add 10.9.0.0/16 via 10.9.0.1
   ip addr add 10.9.0.1/16 dev eth0
   # entfernt
   ip route add 10.8.0.0/16 via 10.8.0.1
   ip addr add 10.8.0.1/16 dev eth0

Presto, ein VPN-Netzwerk!

Nun kann man auf beiden Seiten Rechner innerhalb des C<10.8/9.x.x>-Netzes
stellen (mit Default-Gateway C<10.8/9.0.1> oder statischer Route für das
jeweilige andere Netz über C<10.8/9.0.1>, oder sogar I<proxa arp>).

   # proxy-arp und IP-Forwarding einschalten, auf beiden Knoten
   echo 1 >/proc/sys/net/ipv4/ip_forward
   echo 1 >/proc/sys/net/ipv4/conf/eth0/proxy_arp


=head1 VTund

VTund ist eine der ältesten Lösungen und inspirierte (oder
implementierte) Tunnel-Treiber für viele Betriebssysteme.

=head2 Vorteile/Nachteile

=over 4

=item + Vielfalt an Protokollen und Einsatzmöglichkeiten

=item + Datenkompression

=item - Nicht abhörsicher, nicht Fälschungssicher, völlig unsicher.

=item - Umständliche Konfiguration

=item - Nur Punkt-zu-Punkt-Tunnels

=back

=head2 Beispiele

   dpkg -r vtund
   rpm -r vtund
   ...

VTund ist ein Beispiel für Software, die man nicht benutzen sollte, da
sie kryptographisch völlig unsicher ist.


=head1 OpenVPN

OpenVPN wäre für mich die 

=head2 Vorteile/Nachteile

=item + Sehr hohe Sicherheit

OpenVPN kann TLS (I<den> Standart) für die Authentifizierung und die
Schlüsselübergabe benutzen, d.h. Sicherheitsprüfungen und -fixes spiegeln
sich automatisch bei OpenVPN wieder, während andere Software-Produkte
eventuell erst getrennt gefixt werden müssen.

Dadurch, daß man sehr einfach die Algorithmen wechseln kann, kann man
bei neuentdeckten Schwächen bei einzelnen Algorithmen (z.B. MD5) schnell
ausweichen.

=item + Hohe Portabilität

OpenVPN besitzt Treiber für GNU/Linux, Solaris, OpenBSD, FreeBSD, NetBSD,
Mac OS X, und Windows 2000/XP.

=item + Sehr stabil

OpenVPN hat mich trotz vieler widrigen Umstände (extremer Paket-Loss,
häufige Wiedereinwahl, dynamische IP-Adressen, Software-Upgrades) niemals
im Stich gelassen.

=item + Unterstützt Bridging (Ethernet-Tunnels)

=item + Einfache Konfiguration

=item - Nur Punkt-zu-Punkt-Tunnels

=back

=head2 Beispiele

Wie man sieht, hat OpenVPN nicht sehr viele Nachteile.

OpenVPN unterstützt im wesentlichen zwei Modi für die
Verschlüsselung: I<shared secret> und I<public key>. Im ersten Modus
erzeugt man einen gemeinsamem (shared) Schlüssel, den man sicher auf alle
Rechner verteilen muss:


=head1 Multipunkt-Netze

=head1 tinc

=head2 Vorteile/Nachteile

   + Sehr portabel, ist auf vielen Platformen (inkl. Windows 2000) verfügbar

   + 

   + various modes (routing, bridging)
   + compression
   + dynamic routing (can work around partial loss of connectivity)
   + expansion without restarting the network
   + relatively large packet overhead
   - dynamic routing (can cost a lot of money when it goes wild)
   - (relatively!) weak security, still strong enough in practise
   - relatively complex setup (almost as complex as ipsec)
   - needs tcp and udp at the same time, combining disadvantages of both with respect to firewalls
   - does not work under complex routing conditions

rfc3607, Chinese Lottery Cryptanalysis

=head2 vpe

=head3 Vorteile/Nachteile

=head2 IPSEC

=head3 Vorteile/Nachteile


Revision:	1.2
Committed:	Tue Oct 14 23:40:10 2003 UTC (23 years ago) by root
Branch:	MAIN
Changes since 1.1:	+292 -39 lines
Log Message:	* empty log message *
#	User	Rev	Content
1	root	1.1	=head1 Einfache VPN-Netzwerke
2
3
4	root	1.2	=head1 Einführung
5	root	1.1
6			=head2 Was ist ein "VPN-Netzwerk"
7
8	root	1.2	VPN steht für Virtuelles Privates Netz und bezeichnet den Zusammenschluss
9			mehrerer physikalischer Netze (oder Knoten) zu einem größeren. Die
10	root	1.1	einzelnen Teile des Begriffes bedeuten:
11
12			=over 4
13
14			=item Virtuell
15
16			VPN-Netze sind keine physikalischen Netze, sondern existieren nur
17	root	1.2	virtuell, indem sie sich bestehender Netze für den Transport
18	root	1.1	bedienen. Sie vermitteln lediglich den Eindruck, in I<einem>
19	root	1.2	abgeschlossenen Netz zu sein, daß wesentlich größer sein kann als ein
20			echtes Netzwerk (z.B. können die Teilnehmer über dne ganzen Erdball
21	root	1.1	verstreut sein).
22
23			=item Privat
24
25			VPN-Netze sind abgeschlossen, d.h. sie lassen keine Kommunikation mit
26			ausserhalb des Netzes gelegenen Knoten zu.
27
28	root	1.2	Dies schließt sowohl die Kommunikation von aussen (Angreifer können
29	root	1.1	keine Daten einschleusen), als auch die Kommunikation nach aussen (Daten
30	root	1.2	werden nicht nach aussen gegeben bzw. können nicht "abgehört" werden)
31			ein. Ausserdem muss ein VPN-Netz gegen Veränderung von Daten resistent
32			sein, d.h. es darf nicht möglich sein, Daten zu verfälschen.
33
34			Dies schließt nicht notwendigerweise die Resistenz gegen
35			Kommunikationsunterbrechnung ein. Garantierte Kommunikation können
36			natürlich auch VPN-Netzwerke nicht bieten.
37	root	1.1
38			=item Netzwerk
39
40			Unter einem Netzwerk verstehe zumindest ich einen Zusammenschluss mehrerer
41			bis vieler Rechner. Am einfachsten kann man dies mit einem einfachen
42			Tunnel erreichen, der zwei physikalische Netze miteinander verbindet und
43			von einem Teilnetz in ein anderes vermittelt.
44
45			(Ausserdem ist der Begriff "VPN-Netzwerk" doppelt gemoppelt, aber das
46			hat lange Tradition, siehe IFF-Format und Microsofts ungeschlagen
47	root	1.2	aussagekräftige "Neue Technologie"-Technologie).
48	root	1.1
49			=back
50
51
52			=head1 VPN-Netzwerke, eine Klassifikation
53
54			=head2 Tunnel vs. Netze
55
56	root	1.2	Die einfachste Möglichkeit, ein VPN aufzubauen, ist es, einen Tunnel
57			zwischen zwei physikalischen Netzen aufzubauen. Die beiden Teilnetze
58			werden durch den Tunnel verbunden und bilden das VPN.
59
60			Es gibt verschiedene gebräuchliche Tunnel-Typen, die man (unter anderem)
61			durch die Protokollebene unterscheiden kann, die sie tunneln:
62
63			=over 4
64
65			=item Applikationsebene, z.B. TCP
66
67			Dieser Tunnel transportiert nur ein einziges Protokoll, z.B. telnet, pop3
68			oder X11. Dadurch werden häufig Optimierungen möglich, z.B. besonders
69			gute Kompression oder die Weiterleitung von Authentifizierungsdaten
70			(ssh). Ausserdem sind sie meist sehr portabel und einfach zu
71			konfigurieren.
72
73			Ein Nachteil ist, das man nur ein eiziges Protokoll zur Verfügung hat und
74			für jedes weitere auch eine weitere Tunnel-Lösung benötigt.
75
76			=item Protokollebene, z.B. IP
77
78			Hierbei wird eine ganze Protokoll-Suite getunnelt, z.B. das
79			Internet-Protokoll. Da die meisten Netzwerkapplikationen heute über IP
80			miteinander kommunizieren können, deckt dies die meisten Anwedungen ab.
81
82			Diese Art Tunnel benötigen etwas mehr Planung, da sich die Teilnetze nicht
83			einfach überschneiden können und das Routing zwischen den Teilnetzen
84			festgelegt werden muss.
85
86			Grundlage für Tunnelsoftware ist das Vorhandensein eines sogenannten
87			C<tun> oder C<tap>-Netzwerkgerätes, über das sich Pakete abgreifen bzw.
88			einspeisen lassen.
89
90			=item Netzwerkebene, z.B. Ethernet
91
92			Man kann noch eine Ebene tiefer ansetzen: Statt zwischen zwei
93			physikalischen Teilnetzen lediglich zu vermitteln, kann man sie verbinden,
94			so daß sie sich wie ein großes physikalisches Netz verhalten.
95
96			Im Falle von Ethernet kann man einen Ethernet-Tunnel an beiden Endpunkten
97			über Bridging an die physikalischen Teilnetze anschliessen. Da sich
98			das Gesamtnetzwerk fast wie ein physikalisches Netz verhät, kann man
99			z.B. Rechner von einem Teilnetz in ein anderes verschieben ohne etwas
100			umkonfigurieren zu müssen.
101
102			Diese Tunnels sind am ineffizientesten, was den Overhead betrifft, da
103			sie die Verwaltingsinformation mehrerer Protokollschichten übertragen
104			müssen. Ausserdem wird häufig mit I<Broadcasts> gearbeitet (z.B. um einen
105			Rechner zu "finden"), die gerade bei größeren Netzen schnell die meist
106			geringere Tunnelbandbreite auffressen können.
107
108			=back
109	root	1.1
110
111			=head1 TCP-Tunnel
112
113	root	1.2	Dieser Abschnitt zeigt ein paar Beispiele für TCP-Tunnels. Sie verdienen
114			es kaum, "VPN-Netzwerk" genannt zu werden, aber sie lösen jeweils ein
115			Problem, und nur das zählt.
116
117			=head1 SSH-Portforwarding
118
119			Das SSH-Protokoll hat die r*-Protokolle und telnet im Internet fast
120			vollständig abgelöst. Nicht nur ist es sicherer, es hat auch weitaus mehr
121			Features als die Protokolle, die es ersetzt.
122
123			Eines der Features ist Port-Forwarding, mit dem man einen bestimmten
124			TCP-Port von lokalen Rechner zum entfernten weiterleiten kann, oder
125			umgekehrt.
126
127			=head2 Vorteile/Nachteile
128
129			=over 4
130
131			=item + Fast überall installiert, I<der> Standard schlechthin.
132
133			=item + Sehr hohe Sicherheit
134
135			=item + Einfache Installation und Benutzung
136
137			=item - Nur TCP
138
139			=back
140
141			=head2 Beispiele (OpenSSH-Syntax)
142
143			B<"Der POP3-Server steht in der Firma, ich will von aussen Mail abholen.">
144
145			Zugegebermaßen kein Fall für ein VPN, aber mit SSH einfach zu lösen:
146
147			ssh -L113:mailhost.internal:113 -N bastionhost.internet
148	root	1.1
149	root	1.2	Dies erzeugt einen einfachen Tunnel vom lokalen port 113 (pop3) zum
150			Mailserver innerhalb des Firmennetzes. Da der Quellport (113) unter 1024
151			ist, kann nur Root dieses Kommando ausführen. Als User muss man einen Port
152			über 1024 benutzen. Zur Benutzung muss man seinem Mailprogramm "lediglich"
153			mitteilen, das der POP3-Server nun C<localhost> heißt.
154
155			B<"Meine neue Applikation ist fertig, jemand soll sie sich anschauen
156			können, ohne das ich meinen Webserver ins Internet stellen muss.">
157
158			Der folgende Aufruf erlaubt es einem Benutzer auf C<andereruser.internet>
159			auf meinen (hinter meinem Firewall befindlichen) Webserver zuzugreifen,
160			indem er C<http://localhost:8000/> auf seinem Rechner benutzt:
161
162			ssh -R8000:localhost:80 -N andereruser.internet
163	root	1.1
164
165			=head1 IP-Tunnel
166
167	root	1.2	Ein IP-Tunnel bietet mehr Flexibilität als ein einfacher TCP-Tunnel. Und
168			ist auch etwas komplexer beim Einrichten.
169
170			Im folgenden gehe ich auf Tunnels mit SSH, ein Paket namens C<vtund> und
171			ein weiteres namens C<openvpn> ein, die alle einzelne Tunnels aufbauen
172			können.
173
174			=head1 PPP über SSH
175
176			=head2 Vorteile/Nachteile
177
178			=over 4
179
180			=item + Sehr einfach aufzusetzen
181
182			=item + Die benötigten Komponenten sind einfach zu beschaffen
183
184			Sowohl SSH als auch PPPD gehören zu jeder (allgemeinen)
185			GNU/Linux-Distribution.
186
187			=item + Ideal für Ad-Hoc-Tunnels
188
189			z.B. für kurzzeitige Veranstaltungen, bei denen der Tunnel noch manuell
190			überwacht werden kann.
191
192			=item - Eigentlich ungeeignet für IP
193
194			IP über TCP zu tunneln ist schlecht, da bei schlechter Verbindung sowohl
195			das Tunnel-TCP als auch das getunnelte Protokoll retryen. Dadurch wird die
196			Leitung schnell verstopft.
197
198			Bei guter Verbindung gibt es aber ausser einer gewissen Ineffizienz keine
199			größeren Probleme.
200
201			=item - Keine Stabilitätsrekorde
202
203			Startet man C<ssh> in C<screen>, per C<nohup>? Was passiert bei
204			Netzausfällen? Provider-Neueinwahl? Viele dieser Fragen lassen sich durch
205			verbessertes Skripting (killen des C<pppd>, starten per C</etc/inittab>
206			etc.) lösen aber es wird schnell kompliziert.
207
208			=item - Nur Punkt-zu-Punkt-Tunnels
209
210			Bei mehr als zwei Teilnetzen braucht man schnell serh viel Tunnels, die
211			man nicht einfach manuell verwalten kann.
212
213			=item - Total Unprofessionell
214
215			"Ich habe 13 Filialen damit vernetzt" klingt nicht wirklich überzeugend...
216
217			=back
218
219			=head2 Beispiele
220
221			Es kann so einfach sein:
222
223			pppd pty 'ssh -t andererrechner.internet pppd nodetach' \
224			nodetach passive 10.8.0.1:10.9.0.1
225
226			Diese Zeile baut einen PPP-Tunnel mit C<andererrecher.internet>
227			auf. Der lokale Rechner erhält die IP-Adresse C<10.8.0.1>, der
228			entfernte C<10.9.0.1>. Der obige Tunnel funktioniert auf meinen
229			Rechner wie angegeben, in der Praxis kommen manchmal noch Optionen wie
230			C<ipcp-accept-local> hinzu, oder der Pfad zum C<pppd> muss angegebn
231			werden.
232
233			Mit ein paar weiteren Zeilen kann man zwei Teilnetze auf C<eth0> verbinden:
234
235			# lokal (ip kommt meistens aus dem iproute2-Paket)
236			ip route add 10.9.0.0/16 via 10.9.0.1
237			ip addr add 10.9.0.1/16 dev eth0
238			# entfernt
239			ip route add 10.8.0.0/16 via 10.8.0.1
240			ip addr add 10.8.0.1/16 dev eth0
241
242			Presto, ein VPN-Netzwerk!
243
244			Nun kann man auf beiden Seiten Rechner innerhalb des C<10.8/9.x.x>-Netzes
245			stellen (mit Default-Gateway C<10.8/9.0.1> oder statischer Route für das
246			jeweilige andere Netz über C<10.8/9.0.1>, oder sogar I<proxa arp>).
247
248			# proxy-arp und IP-Forwarding einschalten, auf beiden Knoten
249			echo 1 >/proc/sys/net/ipv4/ip_forward
250			echo 1 >/proc/sys/net/ipv4/conf/eth0/proxy_arp
251
252
253			=head1 VTund
254
255			VTund ist eine der ältesten Lösungen und inspirierte (oder
256			implementierte) Tunnel-Treiber für viele Betriebssysteme.
257
258			=head2 Vorteile/Nachteile
259
260			=over 4
261
262			=item + Vielfalt an Protokollen und Einsatzmöglichkeiten
263
264			=item + Datenkompression
265
266			=item - Nicht abhörsicher, nicht Fälschungssicher, völlig unsicher.
267
268			=item - Umständliche Konfiguration
269
270			=item - Nur Punkt-zu-Punkt-Tunnels
271
272			=back
273
274			=head2 Beispiele
275
276			dpkg -r vtund
277			rpm -r vtund
278			...
279
280			VTund ist ein Beispiel für Software, die man nicht benutzen sollte, da
281			sie kryptographisch völlig unsicher ist.
282
283
284			=head1 OpenVPN
285
286			OpenVPN wäre für mich die
287
288			=head2 Vorteile/Nachteile
289
290			=item + Sehr hohe Sicherheit
291
292			OpenVPN kann TLS (I<den> Standart) für die Authentifizierung und die
293			Schlüsselübergabe benutzen, d.h. Sicherheitsprüfungen und -fixes spiegeln
294			sich automatisch bei OpenVPN wieder, während andere Software-Produkte
295			eventuell erst getrennt gefixt werden müssen.
296
297			Dadurch, daß man sehr einfach die Algorithmen wechseln kann, kann man
298			bei neuentdeckten Schwächen bei einzelnen Algorithmen (z.B. MD5) schnell
299			ausweichen.
300
301			=item + Hohe Portabilität
302
303			OpenVPN besitzt Treiber für GNU/Linux, Solaris, OpenBSD, FreeBSD, NetBSD,
304			Mac OS X, und Windows 2000/XP.
305
306			=item + Sehr stabil
307
308			OpenVPN hat mich trotz vieler widrigen Umstände (extremer Paket-Loss,
309			häufige Wiedereinwahl, dynamische IP-Adressen, Software-Upgrades) niemals
310			im Stich gelassen.
311
312			=item + Unterstützt Bridging (Ethernet-Tunnels)
313
314			=item + Einfache Konfiguration
315
316			=item - Nur Punkt-zu-Punkt-Tunnels
317
318			=back
319
320			=head2 Beispiele
321	root	1.1
322	root	1.2	Wie man sieht, hat OpenVPN nicht sehr viele Nachteile.
323	root	1.1
324	root	1.2	OpenVPN unterstützt im wesentlichen zwei Modi für die
325			Verschlüsselung: I<shared secret> und I<public key>. Im ersten Modus
326			erzeugt man einen gemeinsamem (shared) Schlüssel, den man sicher auf alle
327			Rechner verteilen muss:
328	root	1.1
329
330	root	1.2	=head1 Multipunkt-Netze
331	root	1.1
332	root	1.2	=head1 tinc
333	root	1.1
334	root	1.2	=head2 Vorteile/Nachteile
335	root	1.1
336	root	1.2	+ Sehr portabel, ist auf vielen Platformen (inkl. Windows 2000) verfügbar
337	root	1.1
338	root	1.2	+
339	root	1.1
340	root	1.2	+ various modes (routing, bridging)
341			+ compression
342			+ dynamic routing (can work around partial loss of connectivity)
343			+ expansion without restarting the network
344			+ relatively large packet overhead
345			- dynamic routing (can cost a lot of money when it goes wild)
346			- (relatively!) weak security, still strong enough in practise
347			- relatively complex setup (almost as complex as ipsec)
348			- needs tcp and udp at the same time, combining disadvantages of both with respect to firewalls
349			- does not work under complex routing conditions
350	root	1.1
351	root	1.2	rfc3607, Chinese Lottery Cryptanalysis
352	root	1.1
353			=head2 vpe
354
355			=head3 Vorteile/Nachteile
356
357			=head2 IPSEC
358
359			=head3 Vorteile/Nachteile
360
361