| 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 |
root |
1.3 |
OpenVPN wäre für mich die Wahl ohne Qual, wenn es um einzelne |
| 287 |
|
|
Punkt-zu-Punkt-Tunnel geht. Es ist weit verbreitet, einfach einzurichten |
| 288 |
|
|
und solide ausgeführt. |
| 289 |
root |
1.2 |
|
| 290 |
|
|
=head2 Vorteile/Nachteile |
| 291 |
|
|
|
| 292 |
root |
1.3 |
=over 4 |
| 293 |
|
|
|
| 294 |
|
|
=item + Sehr hohe Sicherheit (TLS-Modus), hohe Sicherheit (shared secret) |
| 295 |
root |
1.2 |
|
| 296 |
|
|
OpenVPN kann TLS (I<den> Standart) für die Authentifizierung und die |
| 297 |
|
|
Schlüsselübergabe benutzen, d.h. Sicherheitsprüfungen und -fixes spiegeln |
| 298 |
|
|
sich automatisch bei OpenVPN wieder, während andere Software-Produkte |
| 299 |
|
|
eventuell erst getrennt gefixt werden müssen. |
| 300 |
|
|
|
| 301 |
|
|
Dadurch, daß man sehr einfach die Algorithmen wechseln kann, kann man |
| 302 |
|
|
bei neuentdeckten Schwächen bei einzelnen Algorithmen (z.B. MD5) schnell |
| 303 |
|
|
ausweichen. |
| 304 |
|
|
|
| 305 |
root |
1.3 |
Das Label "hohe" Sicherheit für den shared-secret-Modus vergebe ich |
| 306 |
|
|
nur, weil die Implementation qualitativ hochwertig durchgeführt |
| 307 |
|
|
wurde. Security-Produkte, die ohne Key-Scheduling arbeiten (wie OpenVPN im |
| 308 |
|
|
shared-secret-Modus) haben fast immer auch andere Schwächen. Dies scheint |
| 309 |
|
|
bei OpenVPN nicht der Fall zu sein. |
| 310 |
|
|
|
| 311 |
root |
1.2 |
=item + Hohe Portabilität |
| 312 |
|
|
|
| 313 |
|
|
OpenVPN besitzt Treiber für GNU/Linux, Solaris, OpenBSD, FreeBSD, NetBSD, |
| 314 |
|
|
Mac OS X, und Windows 2000/XP. |
| 315 |
|
|
|
| 316 |
|
|
=item + Sehr stabil |
| 317 |
|
|
|
| 318 |
|
|
OpenVPN hat mich trotz vieler widrigen Umstände (extremer Paket-Loss, |
| 319 |
|
|
häufige Wiedereinwahl, dynamische IP-Adressen, Software-Upgrades) niemals |
| 320 |
|
|
im Stich gelassen. |
| 321 |
|
|
|
| 322 |
|
|
=item + Unterstützt Bridging (Ethernet-Tunnels) |
| 323 |
|
|
|
| 324 |
|
|
=item + Einfache Konfiguration |
| 325 |
|
|
|
| 326 |
root |
1.3 |
=item - Relativ hoher Paket-Overhead |
| 327 |
|
|
|
| 328 |
|
|
Durch die Verwendung von UDP (bzw. TCP, obwohl von TCP auch hier abzuraten |
| 329 |
|
|
ist) werden die Pakete relativ groß. |
| 330 |
|
|
|
| 331 |
root |
1.2 |
=item - Nur Punkt-zu-Punkt-Tunnels |
| 332 |
|
|
|
| 333 |
|
|
=back |
| 334 |
|
|
|
| 335 |
|
|
=head2 Beispiele |
| 336 |
root |
1.1 |
|
| 337 |
root |
1.2 |
Wie man sieht, hat OpenVPN nicht sehr viele Nachteile. |
| 338 |
root |
1.1 |
|
| 339 |
root |
1.2 |
OpenVPN unterstützt im wesentlichen zwei Modi für die |
| 340 |
|
|
Verschlüsselung: I<shared secret> und I<public key>. Im ersten Modus |
| 341 |
|
|
erzeugt man einen gemeinsamem (shared) Schlüssel, den man sicher auf alle |
| 342 |
|
|
Rechner verteilen muss: |
| 343 |
root |
1.1 |
|
| 344 |
root |
1.3 |
openvpn --genkey --secret tunnel.key |
| 345 |
|
|
scp tunnel.key andererhost.internet: |
| 346 |
|
|
|
| 347 |
|
|
Dann muss openvpn auf beiden Seiten gestartet werden: |
| 348 |
|
|
|
| 349 |
|
|
# lokal |
| 350 |
|
|
openvpn --remote andererhost.internet --dev tun1 \ |
| 351 |
|
|
--ifconfig 10.8.0.1 10.9.0.1 --secret tunnel.key |
| 352 |
|
|
# andererhost |
| 353 |
|
|
openvpn --remote lokal.internet --dev tun1 \ |
| 354 |
|
|
--ifconfig 10.9.0.1 10.8.0.1 --secret tunnel.key |
| 355 |
|
|
|
| 356 |
|
|
Man kann, wie man sieht, also einen Tunnel aufbauen ohne ein einziges |
| 357 |
|
|
Konfigurationsfile zu schreiben. |
| 358 |
|
|
|
| 359 |
|
|
OpenVPN besitzt eine Unmenge an "fine-tuning"-Optionen, z.B. für dyndns |
| 360 |
|
|
(C<--resolv-retry>, C<--float>) und kann bei bestimmten Ereignissen auch |
| 361 |
|
|
Skripte ausführen. |
| 362 |
|
|
|
| 363 |
|
|
Der Nachteile des Shared-Secret-Modus ist, das der Schlüssel nicht |
| 364 |
|
|
gewechselt wird. Sollte der Schlüssel (das Keyfile) einmal in die |
| 365 |
|
|
Hände eines Angreifers fallen, ist sämtliche vergangene und zukünftige |
| 366 |
|
|
Kommunikation entschlüsselbar. |
| 367 |
|
|
|
| 368 |
|
|
Dieser Modus hat aber auch Vorteile: er benötigt keinerlei Handshaking, |
| 369 |
|
|
was nicht nur bedeutet, das der Tunnel sehr schnell aufgebaut werden kann, |
| 370 |
|
|
sondern auch, das man den Paketen dank fehlendem Kopf nicht ansehen kann, |
| 371 |
|
|
das es OpenVPN-Pakete sind. Für einen Mithörer sind es lediglich zufällig |
| 372 |
|
|
aussehende Daten. |
| 373 |
|
|
|
| 374 |
|
|
Sicherer wird es mit Zertifikaten: |
| 375 |
|
|
|
| 376 |
|
|
openvpn --ca ca.pem --cert cert1.pem --tls-server ... |
| 377 |
|
|
openvpn --ca ca.pem --cert cert2.pem --tls-client ... |
| 378 |
|
|
|
| 379 |
|
|
Das Erzeugen von TLS-Zertifikaten sprengt jedoch diese |
| 380 |
|
|
Präsentation. Der geneigte Leser dieses Dokumentes sei |
| 381 |
|
|
deshalb auf das OpenVPN beliegende "easy-rsa"-Paket |
| 382 |
|
|
verwiesen: C<http://openvpn.sourceforge.net/easyrsa.html>, bei Debian in |
| 383 |
|
|
C</usr/share/doc/openvpn/examples/easy-rsa>. |
| 384 |
|
|
|
| 385 |
root |
1.1 |
|
| 386 |
root |
1.2 |
=head1 Multipunkt-Netze |
| 387 |
root |
1.1 |
|
| 388 |
root |
1.2 |
=head1 tinc |
| 389 |
root |
1.1 |
|
| 390 |
root |
1.2 |
=head2 Vorteile/Nachteile |
| 391 |
root |
1.1 |
|
| 392 |
root |
1.3 |
=over 4 |
| 393 |
|
|
|
| 394 |
|
|
=item + Hohe Portabilität |
| 395 |
|
|
|
| 396 |
|
|
Tinc besitzt Treiber für GNU/Linux, Solaris, OpenBSD, FreeBSD, NetBSD, |
| 397 |
|
|
Mac OS X, und Windows 2000/XP. (Solaris, OpenBSD, NetBSD und Mac OS X nur |
| 398 |
|
|
IPv4). |
| 399 |
|
|
|
| 400 |
|
|
=item + Verschiedene Modi (Routing, Bridging) |
| 401 |
|
|
|
| 402 |
|
|
=item + LZO-Datenkompression |
| 403 |
|
|
|
| 404 |
|
|
=item + Hohe Sicherheit |
| 405 |
|
|
|
| 406 |
|
|
Tinc verwendet standardmäßig Public-Key-Kryptographie, vergleichbar mit |
| 407 |
|
|
OpenVPN im TLS-Modus. |
| 408 |
|
|
|
| 409 |
|
|
=item + Dynamisches Routing |
| 410 |
|
|
|
| 411 |
|
|
Tinc benötigt keinen Link von jedem Rechner zu jedem anderen, sondern |
| 412 |
|
|
kann um partielle Netzausfälle "herumrouten", indem es Pakete über andere |
| 413 |
|
|
Rechner im VPN versendet. Bei Broadcasts wird dadurch die Last auf einen |
| 414 |
|
|
einzelnen Rechner verringert. |
| 415 |
|
|
|
| 416 |
|
|
=item + Das Netzwerk kann im Betrieb vergrößert werdem |
| 417 |
|
|
|
| 418 |
|
|
Ein nahezu einmaliges Feature :) |
| 419 |
|
|
|
| 420 |
|
|
=item - Relativ hoher Paket-Overhead |
| 421 |
|
|
|
| 422 |
|
|
Durch die Verwendung von UDP (bzw. TCP, obwohl von TCP auch hier abzuraten |
| 423 |
|
|
ist) werden die Pakete relativ groß. |
| 424 |
root |
1.1 |
|
| 425 |
root |
1.3 |
=item - Dynamisches Routing |
| 426 |
root |
1.1 |
|
| 427 |
root |
1.3 |
Für den Einen hilfreich, für den Anderen ein Bug: Tinc routet gerne mal |
| 428 |
|
|
Daten über den Rechner, für den volumenabhängig bezahlt werden muss. Die |
| 429 |
|
|
Stabilität des Netzes ist unter widrigen Umständen auch nicht die beste, |
| 430 |
|
|
da das Netz häufig umkonfiguriert wird und manchmal scheinbar ohne Grund |
| 431 |
|
|
die direkte (schnellste) Route vermieden wird. |
| 432 |
root |
1.1 |
|
| 433 |
root |
1.3 |
=item - Kritik an der Sicherheit |
| 434 |
root |
1.1 |
|
| 435 |
root |
1.3 |
In letzter Zeit wurde Kritik an einigen Implementationsdetails geübt, z.B. |
| 436 |
|
|
das Fehlen eines IVs. In der Praxis ist dies nicht wirklich relevant, dennoch |
| 437 |
|
|
ist die Sicherheit nicht so hoch wie OpenVPN im TLS-Modus. |
| 438 |
root |
1.1 |
|
| 439 |
root |
1.3 |
RFC3607 (Chinese Lottery Cryptanalysis) beschreibt jedoch die Möglichkeit, |
| 440 |
|
|
das einzelne Angreifer durchaus massiv-parallele Kryptoangriffe starten |
| 441 |
|
|
könnten, so daß man sich - echte Feinde vorausgesetzt - vorsehen sollte. |
| 442 |
root |
1.1 |
|
| 443 |
root |
1.3 |
Die nächste Version soll diesen Punkten Abhilfe schaffen. |
| 444 |
root |
1.1 |
|
| 445 |
root |
1.3 |
=item - (Relativ) komplexe Konfiguration |
| 446 |
|
|
|
| 447 |
|
|
Komplexität kommt auf den Betrachter an, da Tinc jedoch pro Rechner ein |
| 448 |
|
|
Konfigurationsfile + ein weiteres für jeden Knoten benötigt, die unter |
| 449 |
|
|
bestimmten Umständen auch noch auf allen Rechnern unterschiedlich sind. |
| 450 |
|
|
|
| 451 |
|
|
Bei einfachen IP-Netzen hält sich die Konfiguration jedoch in Grenzen. |
| 452 |
|
|
|
| 453 |
|
|
=item - Benötigt TCP und UDP gleichzeitig |
| 454 |
|
|
|
| 455 |
|
|
TCP wird für die Authentifizierung und die Schlüsselübergabe benötigt, UDP |
| 456 |
|
|
für den Transport. Es gibt eine TCP-Only Option, aber die ist (da TCP) |
| 457 |
|
|
nicht zu empfehlen. |
| 458 |
|
|
|
| 459 |
|
|
In Hinsicht auf Firewall-Konfiguration kompliziert dies die Situation bisweilen. |
| 460 |
|
|
|
| 461 |
|
|
=item - Probleme in komplexen Routing-Situationen |
| 462 |
|
|
|
| 463 |
|
|
Da TCP und UDP-Sockets gleichzeitig verwendet aber nicht immer exakt |
| 464 |
|
|
synchronisiert sind (IP-Adressen beim versenden), kann es passieren, das |
| 465 |
|
|
eine Verbindung nicht zu Stande kommt. |
| 466 |
|
|
|
| 467 |
|
|
=back |
| 468 |
|
|
|
| 469 |
|
|
=head2 Beispiele |
| 470 |
|
|
|
| 471 |
|
|
B<Ein reines IP-Netzwerk> |
| 472 |
|
|
|
| 473 |
root |
1.4 |
TODO!! |
| 474 |
root |
1.3 |
|
| 475 |
root |
1.4 |
|
| 476 |
|
|
=head1 Vpe |
| 477 |
root |
1.3 |
|
| 478 |
|
|
=head2 Vorteile/Nachteile |
| 479 |
|
|
|
| 480 |
root |
1.4 |
=over 4 |
| 481 |
|
|
|
| 482 |
|
|
=item + Hohe Portabilität |
| 483 |
|
|
|
| 484 |
|
|
Vpe besitzt Treiber für GNU/Linux, Solaris, OpenBSD, FreeBSD, NetBSD, Mac |
| 485 |
|
|
OS X, und Windows 2000/XP. (Solaris, OpenBSD, NetBSD und Mac OS X nur |
| 486 |
|
|
IPv4). |
| 487 |
|
|
|
| 488 |
|
|
=item + LZF-Datenkompression |
| 489 |
|
|
|
| 490 |
|
|
=item + Sehr hohe Sicherheit |
| 491 |
|
|
|
| 492 |
|
|
Vpe verwendet standardmäßig Public-Key-Kryptographie. Ein besonderes |
| 493 |
|
|
Feature ist, das auch teilnehmende Rechner sich gegenseitig nicht |
| 494 |
|
|
abhören können oder (falsche) Daten einspeisen können (der Ursprung der |
| 495 |
|
|
Datenpakete kann mit Firwallregeln geprüft werden). |
| 496 |
|
|
|
| 497 |
|
|
=item + Große Auswahl an Transportprotokollen |
| 498 |
|
|
|
| 499 |
|
|
Neben dem Standardprotokoll UDP unterstützt Vpe auch einen |
| 500 |
|
|
RAWIP-Transport, ICMP-Tunneling, TCP und sogar HTTPS-Proxy-Tunnels. |
| 501 |
|
|
|
| 502 |
|
|
=item + Wählbarer Paket-Overhead |
| 503 |
|
|
|
| 504 |
|
|
Vpe-Pakete sind (bei entsprechender Konfiguration) 6 Byte kleiner als |
| 505 |
|
|
das entsprechende Ethernet-Paket. Beim RAWIP-Transport (und minimaler |
| 506 |
|
|
Länge der HMAC etc.) wird ein Tunnel-Paket gegenüber dem transportierten |
| 507 |
|
|
IP-Paket nur um 28 Byte größer. |
| 508 |
|
|
|
| 509 |
|
|
=item + Router/Routerloser Modus |
| 510 |
|
|
|
| 511 |
|
|
Designiert man einen (oder mehrere) Rechner als Router, so können diese |
| 512 |
|
|
als Protokollumsetzer dienen und zwischen anderen Knoten vermitteln. So |
| 513 |
|
|
können z.B. zwei Rechner hinter einem NAT eine UDP-Verbindung herstellen. |
| 514 |
|
|
|
| 515 |
|
|
=item + Einfache Konfiguration möglich. Komplexe ebenfalls. |
| 516 |
root |
1.3 |
|
| 517 |
root |
1.4 |
Es gibt nur ein Konfigurationsfile (und ein C<if-up>-Skript zur |
| 518 |
|
|
Initialisierung des Interfaces), das auf allen Rechnern identisch sein |
| 519 |
|
|
kann, plus die Public-Key-Schlüssel der teilnehmenden Rechner. |
| 520 |
|
|
|
| 521 |
|
|
Wenn man ein komplexes Netz aufbaut (viele unterschiedliche Protokolle, |
| 522 |
|
|
Dynip-Rechner, "Einwahl" per HTTPS-Proxy), so wird die Konfiguration auch |
| 523 |
|
|
komplex - aber möglich. |
| 524 |
|
|
|
| 525 |
|
|
=item - Implementiert in C++ |
| 526 |
|
|
|
| 527 |
|
|
Nicht per se ein Nachteil, aber C++ ist weniger verbreitet als C. zudem |
| 528 |
|
|
wurde Vpe bisher nur mit G++ 2.95 und 3.x getestet. |
| 529 |
|
|
|
| 530 |
|
|
=item - Interface-Konfiguration wird dem Benutzer überlassen |
| 531 |
|
|
|
| 532 |
|
|
Vpe emuliert lediglich ein Ethernet - die Konfiguration der |
| 533 |
|
|
Netzwerkinterfaces bleibt einem Skript überlassen. Dies schließt das |
| 534 |
|
|
(stark betriebssystemabhäbgige) Setzen der MAC-Adresse sowie eventuell |
| 535 |
|
|
notwendige ARP-Einträge mit ein. |
| 536 |
|
|
|
| 537 |
|
|
Dies erlaubt zwar volle Kontrolle über das Netz (ob man z.B. ARP benutzt |
| 538 |
|
|
oder nicht), kann aber bei komplexen Netzen auch umständlich sein. |
| 539 |
|
|
|
| 540 |
|
|
=item - Keine Verteilung von Broadcasts |
| 541 |
|
|
|
| 542 |
|
|
Durch die Abschottung der Rechner voneinander muss ein Knoten den |
| 543 |
|
|
Broadcast selbst an alle anderen Knoten verteilen. |
| 544 |
|
|
|
| 545 |
|
|
=item - Kein dynamisches Routing |
| 546 |
|
|
|
| 547 |
|
|
Eine Design-Entscheidung bei Vpe ist es, das alle Routing-Entscheidungen |
| 548 |
|
|
statisch getroffen werden, d.h. aus dem Konfigurationsfile (bzw. der |
| 549 |
|
|
Gesamtheit dieser) wird eine statische Entscheidung über Protokoll und |
| 550 |
|
|
Port getroffen. Ist dieser Weg nicht möglich, kommt keine Verbindung |
| 551 |
|
|
zustande. |
| 552 |
|
|
|
| 553 |
|
|
Dies verhindert zwar, das (wie bei Tinc) Routen zustande kommen, die man |
| 554 |
|
|
nicht vorhersehen kann, verringert aber die Ausfallsicherheit. |
| 555 |
root |
1.1 |
|
| 556 |
root |
1.4 |
=back |
| 557 |
root |
1.1 |
|
