=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 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 oder C-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 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 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 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 auf meinen (hinter meinem Firewall befindlichen) Webserver zuzugreifen, indem er C 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 und ein weiteres namens C 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 in C, per C? Was passiert bei Netzausfällen? Provider-Neueinwahl? Viele dieser Fragen lassen sich durch verbessertes Skripting (killen des C, starten per C 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 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 hinzu, oder der Pfad zum C muss angegebn werden. Mit ein paar weiteren Zeilen kann man zwei Teilnetze auf C 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). # 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 Wahl ohne Qual, wenn es um einzelne Punkt-zu-Punkt-Tunnel geht. Es ist weit verbreitet, einfach einzurichten und solide ausgeführt. =head2 Vorteile/Nachteile =over 4 =item + Sehr hohe Sicherheit (TLS-Modus), hohe Sicherheit (shared secret) OpenVPN kann TLS (I 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. Das Label "hohe" Sicherheit für den shared-secret-Modus vergebe ich nur, weil die Implementation qualitativ hochwertig durchgeführt wurde. Security-Produkte, die ohne Key-Scheduling arbeiten (wie OpenVPN im shared-secret-Modus) haben fast immer auch andere Schwächen. Dies scheint bei OpenVPN nicht der Fall zu sein. =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 - Relativ hoher Paket-Overhead Durch die Verwendung von UDP (bzw. TCP, obwohl von TCP auch hier abzuraten ist) werden die Pakete relativ groß. =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 und I. Im ersten Modus erzeugt man einen gemeinsamem (shared) Schlüssel, den man sicher auf alle Rechner verteilen muss: openvpn --genkey --secret tunnel.key scp tunnel.key andererhost.internet: Dann muss openvpn auf beiden Seiten gestartet werden: # lokal openvpn --remote andererhost.internet --dev tun1 \ --ifconfig 10.8.0.1 10.9.0.1 --secret tunnel.key # andererhost openvpn --remote lokal.internet --dev tun1 \ --ifconfig 10.9.0.1 10.8.0.1 --secret tunnel.key Man kann, wie man sieht, also einen Tunnel aufbauen ohne ein einziges Konfigurationsfile zu schreiben. OpenVPN besitzt eine Unmenge an "fine-tuning"-Optionen, z.B. für dyndns (C<--resolv-retry>, C<--float>) und kann bei bestimmten Ereignissen auch Skripte ausführen. Der Nachteile des Shared-Secret-Modus ist, das der Schlüssel nicht gewechselt wird. Sollte der Schlüssel (das Keyfile) einmal in die Hände eines Angreifers fallen, ist sämtliche vergangene und zukünftige Kommunikation entschlüsselbar. Dieser Modus hat aber auch Vorteile: er benötigt keinerlei Handshaking, was nicht nur bedeutet, das der Tunnel sehr schnell aufgebaut werden kann, sondern auch, das man den Paketen dank fehlendem Kopf nicht ansehen kann, das es OpenVPN-Pakete sind. Für einen Mithörer sind es lediglich zufällig aussehende Daten. Sicherer wird es mit Zertifikaten: openvpn --ca ca.pem --cert cert1.pem --tls-server ... openvpn --ca ca.pem --cert cert2.pem --tls-client ... Das Erzeugen von TLS-Zertifikaten sprengt jedoch diese Präsentation. Der geneigte Leser dieses Dokumentes sei deshalb auf das OpenVPN beliegende "easy-rsa"-Paket verwiesen: C, bei Debian in C. =head1 Multipunkt-Netze =head1 tinc =head2 Vorteile/Nachteile =over 4 =item + Hohe Portabilität Tinc besitzt Treiber für GNU/Linux, Solaris, OpenBSD, FreeBSD, NetBSD, Mac OS X, und Windows 2000/XP. (Solaris, OpenBSD, NetBSD und Mac OS X nur IPv4). =item + Verschiedene Modi (Routing, Bridging) =item + LZO-Datenkompression =item + Hohe Sicherheit Tinc verwendet standardmäßig Public-Key-Kryptographie, vergleichbar mit OpenVPN im TLS-Modus. =item + Dynamisches Routing Tinc benötigt keinen Link von jedem Rechner zu jedem anderen, sondern kann um partielle Netzausfälle "herumrouten", indem es Pakete über andere Rechner im VPN versendet. Bei Broadcasts wird dadurch die Last auf einen einzelnen Rechner verringert. =item + Das Netzwerk kann im Betrieb vergrößert werdem Ein nahezu einmaliges Feature :) =item - Relativ hoher Paket-Overhead Durch die Verwendung von UDP (bzw. TCP, obwohl von TCP auch hier abzuraten ist) werden die Pakete relativ groß. =item - Dynamisches Routing Für den Einen hilfreich, für den Anderen ein Bug: Tinc routet gerne mal Daten über den Rechner, für den volumenabhängig bezahlt werden muss. Die Stabilität des Netzes ist unter widrigen Umständen auch nicht die beste, da das Netz häufig umkonfiguriert wird und manchmal scheinbar ohne Grund die direkte (schnellste) Route vermieden wird. =item - Kritik an der Sicherheit In letzter Zeit wurde Kritik an einigen Implementationsdetails geübt, z.B. das Fehlen eines IVs. In der Praxis ist dies nicht wirklich relevant, dennoch ist die Sicherheit nicht so hoch wie OpenVPN im TLS-Modus. RFC3607 (Chinese Lottery Cryptanalysis) beschreibt jedoch die Möglichkeit, das einzelne Angreifer durchaus massiv-parallele Kryptoangriffe starten könnten, so daß man sich - echte Feinde vorausgesetzt - vorsehen sollte. Die nächste Version soll diesen Punkten Abhilfe schaffen. =item - (Relativ) komplexe Konfiguration Komplexität kommt auf den Betrachter an, da Tinc jedoch pro Rechner ein Konfigurationsfile + ein weiteres für jeden Knoten benötigt, die unter bestimmten Umständen auch noch auf allen Rechnern unterschiedlich sind. Bei einfachen IP-Netzen hält sich die Konfiguration jedoch in Grenzen. =item - Benötigt TCP und UDP gleichzeitig TCP wird für die Authentifizierung und die Schlüsselübergabe benötigt, UDP für den Transport. Es gibt eine TCP-Only Option, aber die ist (da TCP) nicht zu empfehlen. In Hinsicht auf Firewall-Konfiguration kompliziert dies die Situation bisweilen. =item - Probleme in komplexen Routing-Situationen Da TCP und UDP-Sockets gleichzeitig verwendet aber nicht immer exakt synchronisiert sind (IP-Adressen beim versenden), kann es passieren, das eine Verbindung nicht zu Stande kommt. =back =head2 Beispiele B =head1 vpe =head2 Vorteile/Nachteile =head1 IPSEC =head2 Vorteile/Nachteile