| 1 |
=head1 Einfache VPN-Netzwerke |
| 2 |
|
| 3 |
|
| 4 |
=head1 Einführung |
| 5 |
|
| 6 |
=head2 Was ist ein "VPN-Netzwerk" |
| 7 |
|
| 8 |
VPN steht für Virtuelles Privates Netz und bezeichnet den Zusammenschluss |
| 9 |
mehrerer physikalischer Netze (oder Knoten) zu einem größeren. Die |
| 10 |
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 |
virtuell, indem sie sich bestehender Netze für den Transport |
| 18 |
bedienen. Sie vermitteln lediglich den Eindruck, in I<einem> |
| 19 |
abgeschlossenen Netz zu sein, daß wesentlich größer sein kann als ein |
| 20 |
echtes Netzwerk (z.B. können die Teilnehmer über den ganzen Erdball |
| 21 |
verstreut sein). |
| 22 |
|
| 23 |
=item Privat |
| 24 |
|
| 25 |
VPN-Netze sind abgeschlossen, d.h. sie lassen keine Kommunikation mit |
| 26 |
außerhalb des Netzes gelegenen Knoten zu. |
| 27 |
|
| 28 |
Dies schließt sowohl die Kommunikation von außen (Angreifer können |
| 29 |
keine Daten einschleusen), als auch die Kommunikation nach außen (Daten |
| 30 |
werden nicht nach außen gegeben bzw. können nicht "abgehört" werden) |
| 31 |
ein. Außerdem 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 |
Kommunikationsunterbrechung ein. Garantierte Kommunikation können |
| 36 |
natürlich auch VPN-Netzwerke nicht bieten. |
| 37 |
|
| 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 |
(Außerdem ist der Begriff "VPN-Netzwerk" doppelt gemoppelt, aber das |
| 46 |
hat lange Tradition, siehe IFF-Format und Microsofts ungeschlagen |
| 47 |
aussagekräftige "Neue Technologie"-Technologie). |
| 48 |
|
| 49 |
=back |
| 50 |
|
| 51 |
=begin roff |
| 52 |
|
| 53 |
.bp |
| 54 |
|
| 55 |
=end |
| 56 |
|
| 57 |
=head1 VPN-Netzwerke, eine Klassifikation |
| 58 |
|
| 59 |
=head2 Tunnel vs. Netze |
| 60 |
|
| 61 |
Die einfachste Möglichkeit, ein VPN aufzubauen, ist es, einen Tunnel |
| 62 |
zwischen zwei physikalischen Netzen aufzubauen. Die beiden Teilnetze |
| 63 |
werden durch den Tunnel verbunden und bilden das VPN. |
| 64 |
|
| 65 |
Es gibt verschiedene gebräuchliche Tunnel-Typen, die man (unter anderem) |
| 66 |
durch die Protokollebene unterscheiden kann, die sie tunneln: |
| 67 |
|
| 68 |
=over 4 |
| 69 |
|
| 70 |
=item Applikationsebene, z.B. TCP |
| 71 |
|
| 72 |
Dieser Tunnel transportiert nur ein einziges Protokoll, z.B. telnet, pop3 |
| 73 |
oder X11. Dadurch werden häufig Optimierungen möglich, z.B. besonders |
| 74 |
gute Kompression oder die Weiterleitung von Authentifizierungsdaten |
| 75 |
(ssh). Außerdem sind sie meist sehr portabel und einfach zu |
| 76 |
konfigurieren. |
| 77 |
|
| 78 |
Ein Nachteil ist, das man nur ein einziges Protokoll zur Verfügung hat und |
| 79 |
für jedes weitere auch eine weitere Tunnel-Lösung benötigt. |
| 80 |
|
| 81 |
=item Protokollebene, z.B. IP |
| 82 |
|
| 83 |
Hierbei wird eine ganze Protokoll-Suite getunnelt, z.B. das |
| 84 |
Internet-Protokoll. Da die meisten Netzwerkapplikationen heute über IP |
| 85 |
miteinander kommunizieren können, deckt dies die meisten Anwendungen ab. |
| 86 |
|
| 87 |
Diese Art Tunnel benötigen etwas mehr Planung, da sich die Teilnetze nicht |
| 88 |
einfach überschneiden können und das Routing zwischen den Teilnetzen |
| 89 |
festgelegt werden muss. |
| 90 |
|
| 91 |
Grundlage für Tunnelsoftware ist das Vorhandensein eines so genannten |
| 92 |
C<tun> oder C<tap>-Netzwerkgerätes, über das sich Pakete abgreifen bzw. |
| 93 |
einspeisen lassen. |
| 94 |
|
| 95 |
=item Netzwerkebene, z.B. Ethernet |
| 96 |
|
| 97 |
Man kann noch eine Ebene tiefer ansetzen: Statt zwischen zwei |
| 98 |
physikalischen Teilnetzen lediglich zu vermitteln, kann man sie verbinden, |
| 99 |
so daß sie sich wie ein großes physikalisches Netz verhalten. |
| 100 |
|
| 101 |
Im Falle von Ethernet kann man einen Ethernet-Tunnel an beiden Endpunkten |
| 102 |
über Bridging an die physikalischen Teilnetze anschließen. Da sich |
| 103 |
das Gesamtnetzwerk fast wie ein physikalisches Netz verhält, kann man |
| 104 |
z.B. Rechner von einem Teilnetz in ein anderes verschieben ohne etwas |
| 105 |
umkonfigurieren zu müssen. |
| 106 |
|
| 107 |
Diese Tunnels sind am ineffizientesten, was den Overhead betrifft, da |
| 108 |
sie die Verwaltingsinformation mehrerer Protokollschichten übertragen |
| 109 |
müssen. Außerdem wird häufig mit I<Broadcasts> gearbeitet (z.B. um einen |
| 110 |
Rechner zu "finden"), die gerade bei größeren Netzen schnell die meist |
| 111 |
geringere Tunnelbandbreite auffressen können. |
| 112 |
|
| 113 |
=back |
| 114 |
|
| 115 |
=begin roff |
| 116 |
|
| 117 |
.bp |
| 118 |
|
| 119 |
=end |
| 120 |
|
| 121 |
=head1 TCP-Tunnel |
| 122 |
|
| 123 |
Dieser Abschnitt zeigt ein paar Beispiele für TCP-Tunnels. Sie verdienen |
| 124 |
es kaum, "VPN-Netzwerk" genannt zu werden, aber sie lösen jeweils ein |
| 125 |
Problem, und nur das zählt. |
| 126 |
|
| 127 |
=head1 SSH-Portforwarding |
| 128 |
|
| 129 |
Das SSH-Protokoll hat die r*-Protokolle und telnet im Internet fast |
| 130 |
vollständig abgelöst. Nicht nur ist es sicherer, es hat auch weitaus mehr |
| 131 |
Features als die Protokolle, die es ersetzt. |
| 132 |
|
| 133 |
Eines der Features ist Port-Forwarding, mit dem man einen bestimmten |
| 134 |
TCP-Port von lokalen Rechner zum entfernten weiterleiten kann, oder |
| 135 |
umgekehrt. |
| 136 |
|
| 137 |
=head2 Vorteile/Nachteile |
| 138 |
|
| 139 |
=over 4 |
| 140 |
|
| 141 |
=item + Fast überall installiert, I<der> Standard schlechthin. |
| 142 |
|
| 143 |
=item + Sehr hohe Sicherheit |
| 144 |
|
| 145 |
=item + Einfache Installation und Benutzung |
| 146 |
|
| 147 |
=item - Nur TCP |
| 148 |
|
| 149 |
=back |
| 150 |
|
| 151 |
=head2 Beispiele (OpenSSH-Syntax) |
| 152 |
|
| 153 |
B<"Der POP3-Server steht in der Firma, ich will von außen Mail abholen."> |
| 154 |
|
| 155 |
Zugegebenermaßen kein Fall für ein VPN, aber mit SSH einfach zu lösen: |
| 156 |
|
| 157 |
ssh -L113:mailhost.internal:113 -N bastionhost.internet |
| 158 |
|
| 159 |
Dies erzeugt einen einfachen Tunnel vom lokalen Port 113 (pop3) zum |
| 160 |
Mailserver innerhalb des Firmennetzes. Da der Quellport (113) unter 1024 |
| 161 |
ist, kann nur Root dieses Kommando ausführen. Als User muss man einen Port |
| 162 |
über 1024 benutzen. Zur Benutzung muss man seinem Mailprogramm "lediglich" |
| 163 |
mitteilen, das der POP3-Server nun C<localhost> heißt. |
| 164 |
|
| 165 |
B<"Meine neue Applikation ist fertig, jemand soll sie sich anschauen |
| 166 |
können, ohne das ich meinen Webserver ins Internet stellen muss."> |
| 167 |
|
| 168 |
Der folgende Aufruf erlaubt es einem Benutzer auf C<andereruser.internet> |
| 169 |
auf meinen (hinter meinem Firewall befindlichen) Webserver zuzugreifen, |
| 170 |
indem er C<http://localhost:8000/> auf seinem Rechner benutzt: |
| 171 |
|
| 172 |
ssh -R8000:localhost:80 -N andereruser.internet |
| 173 |
|
| 174 |
=begin roff |
| 175 |
|
| 176 |
.bp |
| 177 |
|
| 178 |
=end |
| 179 |
|
| 180 |
=head1 IP-Tunnel |
| 181 |
|
| 182 |
Ein IP-Tunnel bietet mehr Flexibilität als ein einfacher TCP-Tunnel. Und |
| 183 |
ist auch etwas komplexer beim Einrichten. |
| 184 |
|
| 185 |
Im folgenden gehe ich auf Tunnels mit SSH, ein Paket namens C<vtund> und |
| 186 |
ein weiteres namens C<openvpn> ein, die alle einzelne Tunnels aufbauen |
| 187 |
können. |
| 188 |
|
| 189 |
=head1 PPP über SSH |
| 190 |
|
| 191 |
=head2 Vorteile/Nachteile |
| 192 |
|
| 193 |
=over 4 |
| 194 |
|
| 195 |
=item + Sehr einfach aufzusetzen |
| 196 |
|
| 197 |
=item + Die benötigten Komponenten sind einfach zu beschaffen |
| 198 |
|
| 199 |
Sowohl SSH als auch PPPD gehören zu jeder (allgemeinen) |
| 200 |
GNU/Linux-Distribution. |
| 201 |
|
| 202 |
=item + Ideal für Ad-Hoc-Tunnels |
| 203 |
|
| 204 |
z.B. für kurzzeitige Veranstaltungen, bei denen der Tunnel noch manuell |
| 205 |
überwacht werden kann. |
| 206 |
|
| 207 |
=item - Eigentlich ungeeignet für IP |
| 208 |
|
| 209 |
IP über TCP zu tunneln ist schlecht, da bei schlechter Verbindung sowohl |
| 210 |
das Tunnel-TCP als auch das getunnelte Protokoll retryen. Dadurch wird die |
| 211 |
Leitung schnell verstopft. |
| 212 |
|
| 213 |
Bei guter Verbindung gibt es aber außer einer gewissen Ineffizienz keine |
| 214 |
größeren Probleme. |
| 215 |
|
| 216 |
=item - Keine Stabilitätsrekorde |
| 217 |
|
| 218 |
Startet man C<ssh> in C<screen>, per C<nohup>? Was passiert bei |
| 219 |
Netzausfällen? Provider-Neueinwahl? Viele dieser Fragen lassen sich durch |
| 220 |
verbessertes Skripting (killen des C<pppd>, starten per C</etc/inittab> |
| 221 |
etc.) lösen aber es wird schnell kompliziert. |
| 222 |
|
| 223 |
=item - Nur Punkt-zu-Punkt-Tunnels |
| 224 |
|
| 225 |
Bei mehr als zwei Teilnetzen braucht man schnell sehr viel Tunnels, die |
| 226 |
man nicht einfach manuell verwalten kann. |
| 227 |
|
| 228 |
=item - Total Unprofessionell |
| 229 |
|
| 230 |
"Ich habe 13 Filialen damit vernetzt" klingt nicht wirklich überzeugend... |
| 231 |
|
| 232 |
=back |
| 233 |
|
| 234 |
=head2 Beispiele |
| 235 |
|
| 236 |
Es kann so einfach sein: |
| 237 |
|
| 238 |
pppd pty 'ssh -tenone andererrechner.internet pppd nodetach noauth' \ |
| 239 |
nodetach noauth passive 10.8.0.1:10.9.0.1 |
| 240 |
|
| 241 |
Diese Zeile baut einen PPP-Tunnel mit C<andererrecher.internet> |
| 242 |
auf. Der lokale Rechner erhält die IP-Adresse C<10.8.0.1>, der |
| 243 |
entfernte C<10.9.0.1>. Der obige Tunnel funktioniert auf meinen |
| 244 |
Rechner wie angegeben, in der Praxis kommen manchmal noch Optionen wie |
| 245 |
C<ipcp-accept-local> hinzu, oder der Pfad zum C<pppd> muss angegeben |
| 246 |
werden. |
| 247 |
|
| 248 |
Mit ein paar weiteren Zeilen kann man zwei Teilnetze auf C<eth0> verbinden: |
| 249 |
|
| 250 |
# lokal (ip kommt meistens aus dem iproute2-Paket) |
| 251 |
ip route add 10.9.0.0/16 via 10.9.0.1 |
| 252 |
ip addr add 10.9.0.1/16 dev eth0 |
| 253 |
# entfernt |
| 254 |
ip route add 10.8.0.0/16 via 10.8.0.1 |
| 255 |
ip addr add 10.8.0.1/16 dev eth0 |
| 256 |
|
| 257 |
Presto, ein VPN-Netzwerk! |
| 258 |
|
| 259 |
Nun kann man auf beiden Seiten Rechner innerhalb des C<10.8/9.x.x>-Netzes |
| 260 |
stellen (mit Default-Gateway C<10.8/9.0.1> oder statischer Route für das |
| 261 |
jeweilige andere Netz über C<10.8/9.0.1>, oder sogar I<Proxy Arp>). |
| 262 |
|
| 263 |
# Proxy-Arp und IP-Forwarding einschalten, auf beiden Knoten |
| 264 |
echo 1 >/proc/sys/net/ipv4/ip_forward |
| 265 |
echo 1 >/proc/sys/net/ipv4/conf/eth0/proxy_arp |
| 266 |
|
| 267 |
|
| 268 |
=head1 VTund |
| 269 |
|
| 270 |
VTund ist eine der ältesten Lösungen und inspirierte (oder |
| 271 |
implementierte) Tunnel-Treiber für viele Betriebssysteme. |
| 272 |
|
| 273 |
=head2 Vorteile/Nachteile |
| 274 |
|
| 275 |
=over 4 |
| 276 |
|
| 277 |
=item + Vielfalt an Protokollen und Einsatzmöglichkeiten |
| 278 |
|
| 279 |
=item + Datenkompression |
| 280 |
|
| 281 |
=item - Nicht abhörsicher, nicht fälschungssicher, völlig unsicher. |
| 282 |
|
| 283 |
=item - Umständliche Konfiguration |
| 284 |
|
| 285 |
=item - Nur Punkt-zu-Punkt-Tunnels |
| 286 |
|
| 287 |
=back |
| 288 |
|
| 289 |
=head2 Beispiele |
| 290 |
|
| 291 |
dpkg -r vtund |
| 292 |
rpm -r vtund |
| 293 |
... |
| 294 |
|
| 295 |
VTund ist ein Beispiel für Software, die man nicht benutzen sollte, da |
| 296 |
sie kryptographisch völlig unsicher ist. |
| 297 |
|
| 298 |
|
| 299 |
=head1 OpenVPN |
| 300 |
|
| 301 |
OpenVPN wäre für mich die Wahl ohne Qual, wenn es um einzelne |
| 302 |
Punkt-zu-Punkt-Tunnel geht. Es ist weit verbreitet, einfach einzurichten |
| 303 |
und solide ausgeführt. |
| 304 |
|
| 305 |
=head2 Vorteile/Nachteile |
| 306 |
|
| 307 |
=over 4 |
| 308 |
|
| 309 |
=item + Sehr hohe Sicherheit (TLS-Modus), hohe Sicherheit (shared secret) |
| 310 |
|
| 311 |
OpenVPN kann TLS (I<den> Standard) für die Authentifizierung und die |
| 312 |
Schlüsselübergabe benutzen, d.h. Sicherheitsprüfungen und -fixes spiegeln |
| 313 |
sich automatisch bei OpenVPN wieder, während andere Software-Produkte |
| 314 |
eventuell erst getrennt gefixt werden müssen. |
| 315 |
|
| 316 |
Dadurch, daß man sehr einfach die Algorithmen wechseln kann, kann man |
| 317 |
bei neu entdeckten Schwächen bei einzelnen Algorithmen (z.B. MD5) schnell |
| 318 |
ausweichen. |
| 319 |
|
| 320 |
Das Label "hohe" Sicherheit für den shared-secret-Modus vergebe ich |
| 321 |
nur, weil die Implementation qualitativ hochwertig durchgeführt |
| 322 |
wurde. Security-Produkte, die ohne Key-Scheduling arbeiten (wie OpenVPN im |
| 323 |
shared-secret-Modus) haben fast immer auch andere Schwächen. Dies scheint |
| 324 |
bei OpenVPN nicht der Fall zu sein. |
| 325 |
|
| 326 |
=item + Hohe Portabilität |
| 327 |
|
| 328 |
OpenVPN besitzt Treiber für GNU/Linux, Solaris, OpenBSD, FreeBSD, NetBSD, |
| 329 |
Mac OS X, und Windows 2000/XP. |
| 330 |
|
| 331 |
=item + Sehr stabil |
| 332 |
|
| 333 |
OpenVPN hat mich trotz vieler widrigen Umstände (extremer Paket-Loss, |
| 334 |
häufige Wiedereinwahl, dynamische IP-Adressen, Software-Upgrades) niemals |
| 335 |
im Stich gelassen. |
| 336 |
|
| 337 |
=item + Unterstützt Bridging (Ethernet-Tunnels) |
| 338 |
|
| 339 |
=item + Einfache Konfiguration |
| 340 |
|
| 341 |
=item - Relativ hoher Paket-Overhead |
| 342 |
|
| 343 |
Durch die Verwendung von UDP (bzw. TCP, obwohl von TCP auch hier abzuraten |
| 344 |
ist) werden die Pakete relativ groß. |
| 345 |
|
| 346 |
=item - Nur Punkt-zu-Punkt-Tunnels |
| 347 |
|
| 348 |
=back |
| 349 |
|
| 350 |
=head2 Beispiele |
| 351 |
|
| 352 |
Wie man sieht, hat OpenVPN nicht sehr viele Nachteile. |
| 353 |
|
| 354 |
OpenVPN unterstützt im wesentlichen zwei Modi für die |
| 355 |
Verschlüsselung: I<shared secret> und I<public key>. Im ersten Modus |
| 356 |
erzeugt man einen gemeinsamem (shared) Schlüssel, den man sicher auf alle |
| 357 |
Rechner verteilen muss: |
| 358 |
|
| 359 |
openvpn --genkey --secret tunnel.key |
| 360 |
scp tunnel.key andererhost.internet: |
| 361 |
|
| 362 |
Dann muss openvpn auf beiden Seiten gestartet werden: |
| 363 |
|
| 364 |
# lokal |
| 365 |
openvpn --remote andererhost.internet --dev tun1 \ |
| 366 |
--ifconfig 10.8.0.1 10.9.0.1 --secret tunnel.key |
| 367 |
# andererhost |
| 368 |
openvpn --remote lokal.internet --dev tun1 \ |
| 369 |
--ifconfig 10.9.0.1 10.8.0.1 --secret tunnel.key |
| 370 |
|
| 371 |
Man kann, wie man sieht, also einen Tunnel aufbauen ohne ein einziges |
| 372 |
Konfigurationsfile zu schreiben. |
| 373 |
|
| 374 |
OpenVPN besitzt eine Unmenge an "fine-tuning"-Optionen, z.B. für dyndns |
| 375 |
(C<--resolv-retry>, C<--float>) und kann bei bestimmten Ereignissen auch |
| 376 |
Skripte ausführen. |
| 377 |
|
| 378 |
Der Nachteile des Shared-Secret-Modus ist, das der Schlüssel nicht |
| 379 |
gewechselt wird. Sollte der Schlüssel (das Keyfile) einmal in die |
| 380 |
Hände eines Angreifers fallen, ist sämtliche vergangene und zukünftige |
| 381 |
Kommunikation entschlüsselbar. |
| 382 |
|
| 383 |
Dieser Modus hat aber auch Vorteile: er benötigt keinerlei Handshaking, |
| 384 |
was nicht nur bedeutet, das der Tunnel sehr schnell aufgebaut werden kann, |
| 385 |
sondern auch, das man den Paketen dank fehlendem Kopf nicht ansehen kann, |
| 386 |
das es OpenVPN-Pakete sind. Für einen Mithörer sind es lediglich zufällig |
| 387 |
aussehende Daten. |
| 388 |
|
| 389 |
Sicherer wird es mit Zertifikaten: |
| 390 |
|
| 391 |
openvpn --ca ca.pem --cert cert1.pem --tls-server ... |
| 392 |
openvpn --ca ca.pem --cert cert2.pem --tls-client ... |
| 393 |
|
| 394 |
Das Erzeugen von TLS-Zertifikaten sprengt jedoch diese |
| 395 |
Präsentation. Der geneigte Leser dieses Dokumentes sei |
| 396 |
deshalb auf das OpenVPN beliegende "easy-rsa"-Paket |
| 397 |
verwiesen: C<http://openvpn.sourceforge.net/easyrsa.html>, bei Debian in |
| 398 |
C</usr/share/doc/openvpn/examples/easy-rsa>. |
| 399 |
|
| 400 |
=begin roff |
| 401 |
|
| 402 |
.bp |
| 403 |
|
| 404 |
=end |
| 405 |
|
| 406 |
=head1 Multipunkt-Netze |
| 407 |
|
| 408 |
=head1 tinc |
| 409 |
|
| 410 |
=head2 Vorteile/Nachteile |
| 411 |
|
| 412 |
=over 4 |
| 413 |
|
| 414 |
=item + Hohe Portabilität |
| 415 |
|
| 416 |
Tinc besitzt Treiber für GNU/Linux, Solaris, OpenBSD, FreeBSD, NetBSD, |
| 417 |
Mac OS X, und Windows 2000/XP. (Solaris, OpenBSD, NetBSD und Mac OS X nur |
| 418 |
IPv4). |
| 419 |
|
| 420 |
=item + Verschiedene Modi (Routing, Bridging) |
| 421 |
|
| 422 |
=item + LZO-Datenkompression |
| 423 |
|
| 424 |
=item + Hohe Sicherheit |
| 425 |
|
| 426 |
Tinc verwendet standardmäßig Public-Key-Kryptographie, vergleichbar mit |
| 427 |
OpenVPN im TLS-Modus. |
| 428 |
|
| 429 |
=item + Dynamisches Routing |
| 430 |
|
| 431 |
Tinc benötigt keinen Link von jedem Rechner zu jedem anderen, sondern |
| 432 |
kann um partielle Netzausfälle "herumrouten", indem es Pakete über andere |
| 433 |
Rechner im VPN versendet. Bei Broadcasts wird dadurch die Last auf einen |
| 434 |
einzelnen Rechner verringert. |
| 435 |
|
| 436 |
=item + Das Netzwerk kann im Betrieb vergrößert werden |
| 437 |
|
| 438 |
Ein nahezu einmaliges Feature :) |
| 439 |
|
| 440 |
=item - Relativ hoher Paket-Overhead |
| 441 |
|
| 442 |
Durch die Verwendung von UDP (bzw. TCP, obwohl von TCP auch hier abzuraten |
| 443 |
ist) werden die Pakete relativ groß. |
| 444 |
|
| 445 |
=item - Dynamisches Routing |
| 446 |
|
| 447 |
Für den Einen hilfreich, für den Anderen ein Bug: Tinc routet gerne mal |
| 448 |
Daten über den Rechner, für den volumenabhängig bezahlt werden muss. Die |
| 449 |
Stabilität des Netzes ist unter widrigen Umständen auch nicht die beste, |
| 450 |
da das Netz häufig umkonfiguriert wird und manchmal scheinbar ohne Grund |
| 451 |
die direkte (schnellste) Route vermieden wird. |
| 452 |
|
| 453 |
=item - Kritik an der Sicherheit |
| 454 |
|
| 455 |
In letzter Zeit wurde Kritik an einigen Implementationsdetails geübt, z.B. |
| 456 |
das Fehlen eines IVs. In der Praxis ist dies nicht wirklich relevant, dennoch |
| 457 |
ist die Sicherheit nicht so hoch wie OpenVPN im TLS-Modus. |
| 458 |
|
| 459 |
RFC3607 (Chinese Lottery Cryptanalysis) beschreibt jedoch die Möglichkeit, |
| 460 |
das einzelne Angreifer durchaus massiv-parallele Kryptoangriffe starten |
| 461 |
könnten, so daß man sich - echte Feinde vorausgesetzt - vorsehen sollte. |
| 462 |
|
| 463 |
Die nächste Version soll diesen Punkten Abhilfe schaffen. |
| 464 |
|
| 465 |
=item - (Relativ) umständliche Konfiguration |
| 466 |
|
| 467 |
Komplexität kommt auf den Betrachter an, da Tinc jedoch pro Rechner ein |
| 468 |
Konfigurationsfile + ein weiteres für jeden Knoten benötigt, die auch noch |
| 469 |
auf allen Rechnern leicht unterschiedlich sind. Außerdem gibt es eine |
| 470 |
gewisse Duplikation von Routing-Information. |
| 471 |
|
| 472 |
Verglichen mit vielen IPSEC-Implementation (FreeS/WAN z.B.) ist Tinc |
| 473 |
allerdings noch recht übersichtlich. |
| 474 |
|
| 475 |
Bei einfachen IP-Netzen hält sich die Konfiguration jedoch in Grenzen. |
| 476 |
|
| 477 |
=item - Benötigt TCP und UDP gleichzeitig |
| 478 |
|
| 479 |
TCP wird für die Authentifizierung und die Schlüsselübergabe benötigt, UDP |
| 480 |
für den Transport. Es gibt eine TCP-Only Option, aber die ist (da TCP) |
| 481 |
nicht zu empfehlen. |
| 482 |
|
| 483 |
In Hinsicht auf Firewall-Konfiguration kompliziert dies die Situation bisweilen. |
| 484 |
|
| 485 |
=item - Probleme in komplexen Routing-Situationen |
| 486 |
|
| 487 |
Da TCP und UDP-Sockets gleichzeitig verwendet aber nicht immer exakt |
| 488 |
synchronisiert sind (IP-Adressen beim versenden), kann es passieren, das |
| 489 |
eine Verbindung nicht zu Stande kommt. |
| 490 |
|
| 491 |
=back |
| 492 |
|
| 493 |
=head2 Beispiele |
| 494 |
|
| 495 |
B<Ein reines IP-Netzwerk> |
| 496 |
|
| 497 |
Für ein reines IP-Netzwerk benötigt man ein Hauptkonfigurationsfile |
| 498 |
(meistens C</etc/tinc/vpn/tinc.conf>, wobei C<vpn> für einen frei |
| 499 |
wählbaren Netznamen steht). |
| 500 |
|
| 501 |
Für dieses Beispiel reicht folgendes (leider eine Version für jeden Rechner): |
| 502 |
|
| 503 |
# auf rechner1 |
| 504 |
Name = rechner1 |
| 505 |
ConnectTo = rechner2 |
| 506 |
ConnectTo = rechner3 |
| 507 |
PrivateKeyFile = /etc/tinc/vpn/rsa_key.priv |
| 508 |
|
| 509 |
# auf rechner2 |
| 510 |
Name = rechner2 |
| 511 |
ConnectTo = rechner1 |
| 512 |
ConnectTo = rechner3 |
| 513 |
PrivateKeyFile = /etc/tinc/vpn/rsa_key.priv |
| 514 |
|
| 515 |
# auf rechner3 |
| 516 |
Name = rechner2 |
| 517 |
ConnectTo = rechner1 |
| 518 |
ConnectTo = rechner2 |
| 519 |
PrivateKeyFile = /etc/tinc/vpn/rsa_key.priv |
| 520 |
|
| 521 |
Um das Netzwerkinterface zu initialisieren benötigt man auf jedem Rechner |
| 522 |
noch ein C</etc/tinc/vpn/if-up>-Skript: |
| 523 |
|
| 524 |
# auf rechner1 |
| 525 |
ifconfig $INTERFACE 10.7.0.1 netmask 255.0.0.0 |
| 526 |
# Annahme: ifconfig eth0 10.7.0.1 netmask 255.255.0.0 |
| 527 |
|
| 528 |
# auf rechner2 |
| 529 |
ifconfig $INTERFACE 10.8.0.1 netmask 255.0.0.0 |
| 530 |
# Annahme: ifconfig eth0 10.8.0.1 netmask 255.255.0.0 |
| 531 |
|
| 532 |
# auf rechner3 |
| 533 |
ifconfig $INTERFACE 10.9.0.1 netmask 255.0.0.0 |
| 534 |
# Annahme: ifconfig eth0 10.9.0.1 netmask 255.255.0.0 |
| 535 |
|
| 536 |
Zusätzlich benötigt man für jeden teilnehmenden Rechner ein weiteres |
| 537 |
Konfigurationsfile namens C</etc/tinc/vpn/hosts/rechner{1,2,3}>: |
| 538 |
|
| 539 |
# /etc/tinc/vpn/hosts/rechner1 |
| 540 |
Address = rechner1.internet |
| 541 |
Port = 2000 |
| 542 |
Subnet = 10.7.0.0/16 |
| 543 |
|
| 544 |
# /etc/tinc/vpn/hosts/rechner2 |
| 545 |
Address = rechner2.internet |
| 546 |
Port = 2000 |
| 547 |
Subnet = 10.8.0.0/16 |
| 548 |
|
| 549 |
# /etc/tinc/vpn/hosts/rechner3 |
| 550 |
Address = rechner3.internet |
| 551 |
Port = 2000 |
| 552 |
Subnet = 10.9.0.0/16 |
| 553 |
|
| 554 |
Nun muss man auf jedem Rechner das Schlüsselpaar erzeugen, in das |
| 555 |
rechnerspezifische Konfigurationsfile schreiben und auf die anderen |
| 556 |
Rechner kopieren: |
| 557 |
|
| 558 |
# auf rechner1, Vorgehensweise auf anderen Rechner ist ähnlich |
| 559 |
tincd -n vpn -K |
| 560 |
|
| 561 |
Dies erzeugt (interaktiv) die Datei C</etc/tinc/vpn/rsa_key.priv> |
| 562 |
die den privaten Schlüsselteil enthält und schon an der richtigen |
| 563 |
Stelle steht. Der öffentliche Teil wird ebenfalls erzeugt und steht in |
| 564 |
C</etc/tinc/vpn/rsa_key.pub>, was I<nicht> die richtige Stelle ist :). Der |
| 565 |
öffentliche Schlüssel muß dann die rechnerspezifische Konfigurationsdatei |
| 566 |
angehängt werden und an die anderen Rechner verteilt werden: |
| 567 |
|
| 568 |
cat /etc/tinc/vpn/rsa_key.pub >>/etc/tinc/vpn/hosts/rechner1 |
| 569 |
scp /etc/tinc/vpn/hosts/rechner1 rechner2.internet:/etc/tinc/vpn/hosts/ |
| 570 |
scp /etc/tinc/vpn/hosts/rechner1 rechner3.internet:/etc/tinc/vpn/hosts/ |
| 571 |
# usw. für alle anderen Rechner |
| 572 |
|
| 573 |
Das ist, was ich unter "umständliche Konfiguration" |
| 574 |
verstehe. Nichtsdestotrotz ist die Konfiguration getan, man muss lediglich |
| 575 |
auf allen Rechnern C<tincd> starten: |
| 576 |
|
| 577 |
tincd -n vpn |
| 578 |
|
| 579 |
Und kann sich am VPN erfreuen. |
| 580 |
|
| 581 |
Dieses VPN benutzt den C<router>-Modus. Tinc unterstützt noch den |
| 582 |
C<switch>-Modus, bei dem kein IP-Netz sondern ein Ethernet emuliert |
| 583 |
wird. Dann kann man das Routing dem Kernel überlassen und muss die |
| 584 |
IP-(Sub-)Netze nicht in das Konfigurationsfile eintragen. |
| 585 |
|
| 586 |
=begin roff |
| 587 |
|
| 588 |
.bp |
| 589 |
|
| 590 |
=end |
| 591 |
|
| 592 |
=head1 Vpe |
| 593 |
|
| 594 |
=head2 Vorteile/Nachteile |
| 595 |
|
| 596 |
=over 4 |
| 597 |
|
| 598 |
=item + Hohe Portabilität |
| 599 |
|
| 600 |
Vpe besitzt Treiber für GNU/Linux, Solaris, OpenBSD, FreeBSD, NetBSD, Mac |
| 601 |
OS X, und Windows 2000/XP. (Solaris, OpenBSD, NetBSD und Mac OS X nur |
| 602 |
IPv4). |
| 603 |
|
| 604 |
=item + LZF-Datenkompression |
| 605 |
|
| 606 |
LZF (C<http://liblzf.plan9.de>) bietet ähnliche Kompressionsraten und |
| 607 |
-geschwindigkeiten wie LZO. |
| 608 |
|
| 609 |
=item + Sehr hohe Sicherheit |
| 610 |
|
| 611 |
Vpe verwendet standardmäßig Public-Key-Kryptographie. Ein besonderes |
| 612 |
Feature ist, das auch teilnehmende Rechner sich gegenseitig nicht |
| 613 |
abhören können oder (falsche) Daten einspeisen können (der Ursprung der |
| 614 |
Datenpakete kann mit Firewallregeln geprüft werden). |
| 615 |
|
| 616 |
=item + Große Auswahl an Transportprotokollen |
| 617 |
|
| 618 |
Neben dem Standardprotokoll UDP unterstützt Vpe auch einen |
| 619 |
RAWIP-Transport, ICMP-Tunneling, TCP und sogar HTTPS-Proxy-Tunnels. |
| 620 |
|
| 621 |
=item + Wählbarer Paket-Overhead |
| 622 |
|
| 623 |
Vpe-Pakete sind (bei entsprechender Konfiguration) 6 Byte kleiner als |
| 624 |
das entsprechende Ethernet-Paket. Beim RAWIP-Transport (und minimaler |
| 625 |
Länge der HMAC etc.) wird ein Tunnel-Paket gegenüber dem transportierten |
| 626 |
IP-Paket nur um 28 Byte größer. |
| 627 |
|
| 628 |
=item + Router/Routerloser Modus |
| 629 |
|
| 630 |
Designiert man einen (oder mehrere) Rechner als Router, so können diese |
| 631 |
als Protokollumsetzer dienen und zwischen anderen Knoten vermitteln. So |
| 632 |
können z.B. zwei Rechner hinter einem NAT eine UDP-Verbindung herstellen. |
| 633 |
|
| 634 |
=item + Einfache Konfiguration möglich. Komplexe ebenfalls. |
| 635 |
|
| 636 |
Es gibt nur ein Konfigurationsfile (und ein C<if-up>-Skript zur |
| 637 |
Initialisierung des Interfaces), das auf allen Rechnern identisch sein |
| 638 |
kann, plus die Public-Key-Schlüssel der teilnehmenden Rechner. |
| 639 |
|
| 640 |
Wenn man ein komplexes Netz aufbaut (viele unterschiedliche Protokolle, |
| 641 |
Dynip-Rechner, "Einwahl" per HTTPS-Proxy), so wird die Konfiguration auch |
| 642 |
komplex - aber möglich. |
| 643 |
|
| 644 |
=item - Kein echtes Bridging |
| 645 |
|
| 646 |
Vpe emuliert zwar ein virtuelles Ethernet, die MAC-Adressen sind aber |
| 647 |
nicht frei wählbar. Das liegt daran, das Vpe anhand der MAC-Adressen |
| 648 |
routet. Das hat den Vorteil, das Routing-Information nur dem Kernel |
| 649 |
mitgeteilt werden muss (und beliebige Protokolle geroutet werden |
| 650 |
können). Aber auch den Nachteil, das keine Ethernet-Pakete direkt |
| 651 |
gebridged werden können. |
| 652 |
|
| 653 |
=item - Implementiert in C++ |
| 654 |
|
| 655 |
Nicht per se ein Nachteil, aber C++ ist weniger verbreitet als C. Zudem |
| 656 |
wurde Vpe bisher nur mit G++ 2.95 und 3.x getestet. |
| 657 |
|
| 658 |
=item - Interface-Konfiguration wird dem Benutzer überlassen |
| 659 |
|
| 660 |
Vpe emuliert lediglich ein Ethernet - die Konfiguration der |
| 661 |
Netzwerkinterfaces bleibt einem Skript überlassen. Dies schließt das |
| 662 |
(stark betriebssystemabhäbgige) Setzen der MAC-Adresse sowie eventuell |
| 663 |
notwendige ARP-Einträge mit ein. |
| 664 |
|
| 665 |
Dies erlaubt zwar volle Kontrolle über das Netz (ob man z.B. ARP benutzt |
| 666 |
oder nicht), kann aber bei komplexen Netzen auch umständlich sein. |
| 667 |
|
| 668 |
=item - Keine Verteilung von Broadcasts |
| 669 |
|
| 670 |
Durch die Abschottung der Rechner voneinander muss ein Knoten den |
| 671 |
Broadcast selbst an alle anderen Knoten verteilen. |
| 672 |
|
| 673 |
=item - Kein dynamisches Routing |
| 674 |
|
| 675 |
Eine Design-Entscheidung bei Vpe ist es, das alle Routing-Entscheidungen |
| 676 |
statisch getroffen werden, d.h. aus dem Konfigurationsfile (bzw. der |
| 677 |
Gesamtheit dieser) wird eine statische Entscheidung über Protokoll und |
| 678 |
Port getroffen. Ist dieser Weg nicht möglich, kommt keine Verbindung |
| 679 |
zustande. |
| 680 |
|
| 681 |
Dies verhindert zwar, das (wie bei Tinc) Routen zustande kommen, die man |
| 682 |
nicht vorhersehen kann, verringert aber die Ausfallsicherheit. |
| 683 |
|
| 684 |
=back |
| 685 |
|
| 686 |
=head2 Beispiele |
| 687 |
|
| 688 |
C<Ein einfaches IP-Netzwerk> |
| 689 |
|
| 690 |
Dazu benötigt man zwei Dateien, zuerst einmal die Konfigurationsdatei |
| 691 |
C</etc/vpe/vped.conf>: |
| 692 |
|
| 693 |
mtu = 1492 # Der dial-up-rechner benutzt tdsl mit MTU 1492 |
| 694 |
|
| 695 |
node = rechner1 |
| 696 |
address = rechner1.internet |
| 697 |
|
| 698 |
node = rechner2 |
| 699 |
|
| 700 |
node = rechner3 |
| 701 |
address = rechner3.internet |
| 702 |
|
| 703 |
C<rechner1> und C<rechner3> haben (hier) eine feste Adresse, C<rechner2> |
| 704 |
ist ein Dialup-Rechner. |
| 705 |
|
| 706 |
Die zweite Datei ist ein Skript (C</etc/vpe/if-up>), das die |
| 707 |
Netzwerkinterfaces einrichtet (es muss ausführbar sein!): |
| 708 |
|
| 709 |
#!/bin/sh |
| 710 |
ip link set $IFNAME address $MAC mtu $MTU up |
| 711 |
ifconfig $IFNAME 10.$NODEID.0.1/8 |
| 712 |
# Annahme: ifconfig eth0 10.$NODEID.0.1/16 |
| 713 |
|
| 714 |
Hier habe ich etwas getrickst: Vpe setzt eine Menge Environment-Variablen, |
| 715 |
eine davon, C<$NODEID>, ist eine numerische ID des aktuellen Rechners, |
| 716 |
die von der Reihenfolge im Konfigurationsfile bestimmt wird: C<rechner1> |
| 717 |
erhält die ID 1 und die IP# C<10.1.0.1>, C<rechner2> die ID 2 und die IP# |
| 718 |
<10.2.0.1> etc. |
| 719 |
|
| 720 |
Jetzt müssen die RSA-Schlüssel erzeugt werden: |
| 721 |
|
| 722 |
vpectrl -g |
| 723 |
|
| 724 |
Das erzeugt für jeden Knoten eine Datei C</etc/vpe/pubkey/rechner{1,2,3}> |
| 725 |
mit dem öffentlichen und eine Datei C</etc/vpe/hostkeys/rechner{1,2,3}>. |
| 726 |
|
| 727 |
Nun können die beiden Konfigurationsdateien C<vped.conf> und C<if-up>, |
| 728 |
sowie die öffentlichen Schlüssel in C</etc/vpe/pubkey/> auf alle Knoten |
| 729 |
verteilt werden: |
| 730 |
|
| 731 |
scp -pr /etc/vpe/{vped.conf,if-up,pubkey} rechner2.internet:/etc/vpe/. |
| 732 |
scp -pr /etc/vpe/{vped.conf,if-up,pubkey} rechner3.internet:/etc/vpe/. |
| 733 |
|
| 734 |
Vpe erwartet (per Default) I<den> (nicht I<die>!) privaten Schlüssel in |
| 735 |
der Datei C</etc/vpe/hostkey>. Der Grund ist, das die privaten Schlüssel |
| 736 |
den einzelnen Rechner abhörsicher machen. Ist das egal (wenn man allen |
| 737 |
beteiligten Rechnern vertraut), kann man das Verzeichnis auch direkt |
| 738 |
kopieren und im Konfigurationsfile C<hostkey = hostkeys/%s> angeben. |
| 739 |
|
| 740 |
Wir wollen aber ein neurotisch-paranoides sicheres Netzwerk, und verteilen |
| 741 |
die Schlüssel einzeln von C<rechner1> auf die anderen: |
| 742 |
|
| 743 |
cd /etc/vpe |
| 744 |
cp hostkeys/rechner1 hostkey |
| 745 |
scp hostkeys/rechner2 rechner2.internet:/etc/vpe/hostkey |
| 746 |
scp hostkeys/rechner3 rechner3.internet:/etc/vpe/hostkey |
| 747 |
|
| 748 |
Nun ist es geschafft und man kann C<vped> starten: |
| 749 |
|
| 750 |
vped -l info rechner1 |
| 751 |
|
| 752 |
C<vped> benötigt den Knotennamen als einziges Argument um den aktuellen |
| 753 |
Rechner zu identifizieren. Das C<-l info> setzt den Logging-Level auf |
| 754 |
C<info>, bei dem Vpe Verbindungsaufbauten mitprotokolliert. |
| 755 |
|
| 756 |
C<vped> geht in den Hintergrund und hält automatisch die Verbindungen |
| 757 |
aufrecht. Der Dial-Up-Rechner im Beispiel sollte bei IP-Adressänderungen |
| 758 |
ein C<HUP>-Signal an den C<vped> schicken, sonst können andere Rechner ihn |
| 759 |
nicht erreichen. |
| 760 |
|
| 761 |
Eine andere Möglichkeit (die ich gerne praktiziere) um VPN (und andere) |
| 762 |
Dämonen automatisch zu starten ist, sie in die C<inittab> einzutragen: |
| 763 |
|
| 764 |
t1:2345:respawn:/opt/vpe/sbin/vped -D -L mobil >/dev/null 2>&1 |
| 765 |
|
| 766 |
Der Schalter C<-D> sorgt dafür, das der C<vped> nicht in den Hintergrund |
| 767 |
geht. C<init> selbst sorgt dafür, das C<vped> immer läuft, es sei denn, er |
| 768 |
startet zu schnell neu (bei Konfigurationsfehlern z.B.). Dann legt C<init> |
| 769 |
ihn für eine Weile auf Eis. |
| 770 |
|
| 771 |
B<Ein Netzwerk auf Steroiden> |
| 772 |
|
| 773 |
Als zweites Beispiel möchte ich ein Subset meines Produktionsnetzwerkes |
| 774 |
vorstellen. Es enthält einige Router (stellvertretend benutze ich hier den |
| 775 |
Rechner C<router>), einige Dial-Up-Rechner (C<dialup>) und mein Notebook |
| 776 |
(C<mobil>), mit dem ich auf Reisen bin. Außerdem wird der RAWIP-Transport |
| 777 |
benutzt (mit IPSEC-Protokollnummer, da dies häufig freigeschaltet ist): |
| 778 |
|
| 779 |
# vped.conf: |
| 780 |
mtu = 1492 # the mtu (minimum mtu of attached host) |
| 781 |
keepalive = 300 |
| 782 |
ifname = vpn0 # the tunnel interface name to use |
| 783 |
compress = yes |
| 784 |
connect = ondemand # connect to this host always/never or ondemand |
| 785 |
|
| 786 |
loglevel = notice |
| 787 |
udp-port = 407 |
| 788 |
tcp-port = 443 # https |
| 789 |
ip-proto = 50 # ipsec-esp |
| 790 |
|
| 791 |
enable-rawip = yes # RAWIP ist default für die Rechner |
| 792 |
|
| 793 |
node = router |
| 794 |
address = 130.4.88.20 |
| 795 |
router-priority = 10 |
| 796 |
enable-tcp = yes # also talks https |
| 797 |
|
| 798 |
node = dialup |
| 799 |
|
| 800 |
node = mobil |
| 801 |
|
| 802 |
Das C<if-up>-Skript ist etwas komplexer (der Distribution liegt ein |
| 803 |
Beispiel-C<if-ip>-Skript bei, das ARP-loses IP-Routing implementiert und |
| 804 |
nebenher auch gleich C<iptables>-Firewallregeln erzeugt): |
| 805 |
|
| 806 |
#!/bin/sh |
| 807 |
|
| 808 |
ip link set $IFNAME address $MAC mtu $MTU up |
| 809 |
|
| 810 |
[ $NODENAME = router ] && ip addr add 10.0.0.5 dev $IFNAME |
| 811 |
[ $NODENAME = dialup ] && ip addr add 10.9.0.31 dev $IFNAME |
| 812 |
[ $NODENAME = mobil ] && ip addr add 10.0.0.20 dev $IFNAME |
| 813 |
|
| 814 |
ip route add 10.0.0.0/8 dev $IFNAME |
| 815 |
|
| 816 |
# Festes verdrahten der Gateway-MAC-Adressen verhindert ARPs |
| 817 |
ip neighbour add 10.0.0.5 lladdr fe:fd:80:00:00:01 nud permanent dev $IFNAME |
| 818 |
ip neighbour add 10.9.0.20 lladdr fe:fd:80:00:00:02 nud permanent dev $IFNAME |
| 819 |
ip neighbour add 10.0.0.20 lladdr fe:fd:80:00:00:03 nud permanent dev $IFNAME |
| 820 |
|
| 821 |
# Routen eintragen |
| 822 |
[ $NODENAME != router ] && ip route add 10.0.0.0/28 via 10.0.0.5 dev $IFNAME |
| 823 |
[ $NODENAME != dialup ] && ip route add 10.9.0.0/16 via 10.9.0.31 dev $IFNAME |
| 824 |
|
| 825 |
Sieht kompliziert aus, verhindert aber ARP-Requests (Die gebroadcasted |
| 826 |
werden müssen und dabei Verbindungen zu allen anderen Rechner aufbauen |
| 827 |
müssen). |
| 828 |
|
| 829 |
C<mobil> benutzt übrigens manchmal (Reisen! Veranstaltungen mit Netzzugang |
| 830 |
nur über Proxy etc!) leichte Veränderungen an der Konfigurationsdatei: |
| 831 |
|
| 832 |
node = mobil |
| 833 |
http-proxy-host = webproxy.domain |
| 834 |
http-proxy-port = 3128 |
| 835 |
# http-proxy-auth = user:password |
| 836 |
enable-tcp = yes |
| 837 |
enable-udp = no |
| 838 |
enable-rawip = no |
| 839 |
|
| 840 |
C<mobil> benutzt dann TCP-über-HTTP-Proxy, was (fast) überall |
| 841 |
funktioniert. Wenn C<dialup> den Rechner C<mobil> erreichen will, fragt er |
| 842 |
bei C<router> nach und bekommt mitgeteilt, das C<mobil> kein gemeinsames |
| 843 |
Protokoll spricht. C<dialup> versucht dann, über den C<router> mit |
| 844 |
C<mobil> zu kommunizieren (was auch klappt). |
| 845 |
|
| 846 |
|
| 847 |
|
| 848 |
|
| 849 |
|
