Wireguard wird zunehmend zum Aufbau von VPN verwendet. Im Netz kursieren etliche Anleitungen zum Aufbau einen VPN.
Bei diese Anleitungen oder Software Komponenten wird fast immer der Einsatz von “iptable”, also eine NAT-Lösung, vorgesehen. In den meisten Fälle dürfte es unnötig sein und dürfte eher von ein mangel an Wissen über den Aufbau von Netzwerke deuten.
NAT ist eigentlich nur dann von Nöte wenn ein FULL-VPN aufgebaut wird. In dem Fall sollen alle Zugriffe auf das Internet über das VPN Tunnel geleitet werden. Vorteil ist, dass, unabhängig vom Standort, Dienste über den eigenen Anschluss erfolgen und damit es unerheblich ist ob man seine Lieblingsserie aus Tokio oder zu Hause betrachtet (Zugriffsverweigerung aufgrund der Geolokation). Mit solch ein VPN kann auch das Verkehr über öffentliche Hotspots von fremden Augen gesichert werden.
Oft dürfte aber der Zugriff auf System im Heimbereich, beispielsweise auf ein NAS oder der IP-Telefonie) maßgebend sein. In dem Fall ist NAT unnötig, einfache Routings Angaben reichen aus.
Die Heim-Routern (CPE) haben mehr oder weniger schlechte Unterstürzung des Netzwerkkonfiguration. Für der Einsatz einer “Client to Site” VPN wird ein anderen Subnetz verwendet, es bedeutet, dass es gut wäre statische Routen setzen zu können. Router von AVM erlauben es. Dagegen bieten Router wie die Speedport (Telekom) nicht das Setzen von statische Routen. Manche Internet Anbieter liefern auch gerne Router von Sagemcom, diese bieten nicht eine saubere Konfiguration.
Wenn ein CPE die Möglichkeit ein VPN aufzubauen anbietet, ist es nicht immer optimal, jedoch kann ein Zugriff (per IPv4) auf die Systeme im LAN erfolgen. In dem Fall wird man nicht wirklich Spaß mit der Zugriff auf die Geräte des Heimnetzwerk haben und ein externe Gerät muss so eingerichtet und betrieben werden.
Die Konfiguration des VPN hängt sehr stark von der verwendete CPE ab und Einschränkungen müssen, unter Umständen, im Kauf genommen werden. Unter Umständen ist die Verwendung von NAT notwendig.
In der Ursprungszeiten des Internet wurden Adressen verwenden, die es nur erlauben relativ wenig Systeme mir eine eigene Adresse zu versehen. Mit der Vernetzung immer weitere Anwender kam es schnell zu einen Mangel an Adressen und “Network Address Translation” (NAT) wurde eingeführt. Dies bedeutet, dass die Kunden eine von Außen erreichbare Adresse erhalten (Router) und intern werden ganz andere Adressen verwendet. Die Interne Adressen dürfen nicht außen erscheinen, es würde zu Kollisionen kommen und das Internet würde versagen.
Die Knappheit der IPv4 Adressen rief die Festlegung neue Normen, nämlich IPv6. Die IPv6 Normen wurde in Dezember 1998 publiziert, und sind damit schon recht alt.
Ein Nachteil von IPv6 ist, dass sie weniger gut lesbar und bemerkbar sind. Dies führte in der Anfangszeiten offenbar zur Ablehnung durch vielen Internet Anwender.
Hauptvorteil von IPv6 ist jedoch, dass jede Rechner über eine öffentlich erreichbare Adresse verfügen kann. Auch das Routen, es bedeutet die Weiterleitung der Internet Nachrichten vereinfacht sich immens, umfangreiche Routingtabellen, die durch der Segmentierung der IPv4 Adressenbereiche bedingt waren, entfallen.
Viele Verlage, Firmen und Behörde verfügen immer noch ausschließlich über IPv4 Adressen bzw, Adressenbereiche. Dies zeugt nicht für Weitsichtigkeit und ist vor allem bei technikaffinen Verlage bzw. Zeitschriften unverständlich. Bund und Länder verfügen ausschließlich über IPv4 Adressen, dies zeugt nicht unbedingt von Interesse an eine Zeitgemäße Kommunikation.
Da viele Anbieter nur über IPv4 erreichbar sind müssen Provider immer noch dafür sorgen, dass Internetpräsenzen weiterhin über IPv4 Adressen erreichbar sind.
Manche Provider können keine öffentliche IPv4 Adressen anbieten, dadurch muss ein IPv4 mehrfach “genattet” werden, das Verfahren, der eingesetzt wird ist CGN (Carrier Grade NAT). In dem Fall sind 2 NAT Instance involviert, die CPE (Kunden Router) übersetzt die lokale IPv4 Adresse (beispielsweise 192.168.1.23) nach der Adresse im “Shared Transition Space” zugewiesene Adresse (beispielsweise 100.64.31.231). Beim Provider wird diese Adresse in eine öffentlich Adresse übersetzt.
Das doppelte NAT ist mit Sicherheit nicht optimal und wenn zu viele Verbindungen vorhanden sind, könnte der Aufruf von Internet Dienste problematisch werden.
Grundsätzlich können Tunnel auf verschiedene Ebene des Netzwerk System aufgebaut werden. Am flexiblen dürfte ein “Layer 2” Tunnel sein. Layer 2 bedeutet dass die physikalische Ebene des Transportmedium (MAC-Adresse), simuliert wird. Bei ein “Layer 3” Tunnel, wie beispielsweise von Wireguard implementiert, werden multicast Nachrichten nicht verarbeitet. Damit ist eine automatische Adressvergabe oder das Empfangen von mDNS, Bonjour oder Link Local Multicast Name Resolution (LLMNR) nicht möglich.
VPN Tunnel übertragen die Daten verschlüsselt, die Verschlüsselung kann durch die CPU oder unter mit Hardware Unterstützung erfolgen. Rechner mit X86 CPU (Intel, Amd) sind im Regelfall mit eine AES Verschlüsselungs Hardware ausgestattet, damit kann eine Verschlüsselung der Daten wesentlich effektiver stattfinden als bei den Einsatz der CPU.
Bei Arm Prozessoren ist AES-NI selten vorhanden, damit ist die CPU stärker belastet und die Verschlüsselung kann mehr Zeit im Anspruch nehmen.
Die von Wireguard verwendete Verschlüsselung wird ausschließlich auf der CPU durchgeführt, glücklicherweise ist das Verfahren schnell, auch wenn dass erreichbaren nicht die einer Hardware Unterstürzung heran reicht.
Die meisten VPN Software Komponente werden im User Space realisiert, daher sind Kontextwechseln notwendig und die Performance sinkt (Daten müssen kopiert werden, es kostet Zeit). Eine Unterstüzung durch Hardware kann sowohl bei User Space wie Kernel Lösungen stattfinden. Die eingesetzten Bibliotheken sorgen dafür, dass beispielsweise eine Verschlüsselung oder Entschlüsselung über der Hardware erfolgt. Es kostet zwar Contextwechseln, ist dennoch effizienter als eine reine Software Lösung.
Das Effekt der Verarbeitung im Kernel oder User Space kann mit Wireguard im Prinzip untersucht werden. Neben der Implementierung als Kernel Komponente, existiert auch eine User Space Variante, Diese erlaubt es Wireguard auf nicht Linux Systeme oder solchen die keine Kernel Unterstürzung bieten. Wenn die Prozessoren ausreichend leistungsfähig sind, ist einer Unterschied möglicherweise nicht zu erkennen.
Die Tests wurden mit das Kommando openssl speed -evp <typ> durchgeführt.
| type | 16 bytes | 64 bytes | 256 bytes | 1024 bytes | 8192 bytes | 16384 bytes |
|---|---|---|---|---|---|---|
| NoteBook | ||||||
| chacha20-poly1305 | 317663.43k | 614716.15k | 1242548.48k | 2253644.46k | 2385948.77k | 2391255.72k |
| aes-256-cbc | 914937.53k | 1049373.67k | 1080097.31k | 1077927.81k | 1087122.09k | 1089525.04k |
| NAS X86_64 | ||||||
| chacha20-poly1305 | 84222.57k | 179889.94k | 235623.00k | 252167.51k | 259445.30k | 258785.28k |
| aes-256-cbc | 150112.83k | 239186.66k | 291841.96k | 310281.56k | 316126.27k | 315686.91k |
| Raspberry P4B | ||||||
| chacha20-poly1305 | 87298.67k | 144548.22k | 269774.51k | 309764.78k | 318633.30k | 319346.01k |
| aes-256-cbc | 32786.02k | 35254.02k | 36008.53k | 36201.47k | 36257.79k | 36252.33k |
| NAS ARM | ||||||
| chacha20-poly1305 | 53756.93k | 107481.69k | 234703.23k | 260372.13k | 271116.32k | 271053.86k |
| aes-256-cbc | 48078.68k | 53964.50k | 56427.99k | 57680.72k | 58061.15k | 57684.84k |
Sieger ist, in alle Diszipline das Notebook, der eine Leistungsstarke CPU besitzt.
Der Arm basierten NAS ist bei der chacha20-poly1305 am schwächten, Der Raspberry P4B schlägt sich im Vergleich zu den NAS Geräte durch.
Bei dem aes-256-cbc sind die X86_64 Systemen im Vorteil, sie nutzen auch eine Hardware-Beschleunigung.
Der Router Fritz!Box 7590 AX wird mit verschiedene VPN in der nächste Version herauskommen. Darunter befindet sich ein zur Cisco kompatibel VPN Dienst der IPSec nutzt. Die Verschlüsselung wird von der Hardware vorgenommen.
7590 AX IPSec: 266 Mbit/s, 191 Mbit/s (mit HW Beschleunigung)
7590 AX Wireguard: 183 Mbit/s, 95 Mbit/s
7590 IPSec: 20 Mbit/s (Ohne HW Beschleunigung)Werte aus https://www.youtube.com/watch?v=ayfHDpw8GwY entnommen.
Auf der RasperryPi wurde RaspbianLite 64bit installiert. Das NAS System unterstüzt nicht wireguard. Dementsprechend wurde wireguard-go (User Space ) verwendet. Die Messung mit iperf3 ergab eine Übertagungsrate von 430 Mbits/sec.
Die Notebook sind mit ein i7-8750H CPU @ 2.20GHz bzw. i5-4210U CPU @ 1.70GHz ausgerüstet. Sie wurden per Kabel verbunden.
Direct 944 Mbits/sec
Ipip 931 Mbits/sec
Wireguard 902 Mbits/sec
Wireguard-go 803 Mbits/secDirect 941 Mbits/sec
Wireguard 901 Mbits/secDie erreichbare Übertragungsrate beträgt unter Wireguard 902 Mbists/sec es ist nicht wesentlich langsamer als die direkte Verbindung. Ein Faktor der die Übertragungsrate limitiert ist die Einkapselung der Daten im Wireguard Header.
Innerhalb ein Nachricht können bei der direkte Verbindung (IPv4) mit eine MTU von 1500 werden der IP Header (20 Bytes), das TCP Header (TCP Header) und 1460 Datenbytes gesendet. Die MTU bei Wireguard beträgt dagegen 1420 Bytes und den Anzahl an Datenbytes 1380. Es bedeutet, dass mehr einzelne Nachrichten den Weg zur Gegenstelle nehmen müssen.
Dadurch sinkt, in dem Fall die Übertragungsrate um den Faktor 1380/1460 ≈ 0,95. Die gemessene Übertragungsraten (Direkt, über Wireguard) entsprechen, bis auf der Messungenauigkeit) diese Verhältnis.
Der Raspberry PI 4B erreicht gegen der Notebook, praktisch die gleiche Werte wie bei den Tests Notebook zu Notebook uns stellt dadurch kein Engpass,
Mit Wireguard-go, die User Space Implementation sinkt die Übertragungsrate weiter und erreicht 803 MBits/sec, dies ist vorwiegend durch Contextwechsel begründet.
Die für den Kontextwechsel nötige Zeit kann leicht anhand der RTT (Ping-Zeit) ersehen werden, die von Befehl “ping” gesendete Daten sind klein, damit spielt die Verschlüsselung ein relativ geringere Rolle
Ipip ist ein virtuelle Verbindung ohne Verschlüsselung, welcher mit ein ipip Tunnel aufgebaut wurde. Die MTU beträgt 1480 Bytes. Die Verwaltung erfolgt im Kernel. Bedingt durch die kleinere MTU sollte die maximale Übertragungsrate auf ca. 98,6% der Wert im direktem Modus sinken. Die Messwerten spiegeln es ziemlich genau.
Direct 0,2ms
Ipip 0,4ms
Wireguard 0,5ms
wireguard-go 0,7msUm das Effekt der Verschlüsselung bzw. der Kontextwechseln kann hier beurteilt werden. Die Verschlüsselung im Kernel kostet ca. 0,1 ms (Wireguard - Ipip) Kontextwechsel ca. 0,2ms (wireguard-go - Wireguard).
Das Kernel interne Routing kostet beim Testszenario insgesamt ca. 0,2ms.
Um der Einfluss des RTT auf das Zugriff auf Netzwerk Dateisysteme zu überprüfen, wurde mit sshfs¹ ein Netzwerk Dateisystem eingebunden und ein Kopie Vorgang initiiert (dd if=/dev/zero of=/
Mit das Kommando tc add dev enp4s0 root netmen delay = 5ms wurde eine größere RTT eingestellt und bei weitergehende Tests die Einstellung mit tc change dev enp4s0 root netmen delay = 10ms … geändert.
Kein Delay 109 MByte/sec.
5 ms 84 MByte/sec.
10 ms 76 MByte/sec.
30 ms 35 MByte/sec.
60 ms 20 MByte/sec.Es ist ersichtlich, dass die erreichbare Übertragungsrate stark von der RTT abhängt. Es ist auch möglich die maximale Übertragungsrate an der Ethernet Schnittstelle zu begrenzen, zb. tc add dev enp4s0 root rate 524288kbit latency 0.001ms burst 154000 In dem Fall können maximal 512 MBits/sec. über das Interface gesendet werden und die RTT beträgt 10ms. Als Übertragungsrate wird knapp 61 MByte/sec. erreicht. Bei Dieser Test war der lediglich der Empfang begrenzt, das Versenden der Quittung mit den entsprechenden Delay sorgt schon für eine geringere Übertragungsrate.
¹) sshfs benötigt als Host Angabe immer eine IP Adresse
Die erreichbare Ausnützung der Ethernet Schnittstelle hängt sehr Stark von der Leistungsfähigkeit der Hardware (CPU und Unterstützung einer Hardware Verschlüsselung). Was für ein VPN System eingesetzt wird und die Erwartungen an Leistungsfähigkeit, leichte Handhabung, vorhandene Hardware, Stromkosten, … muss jeder für sich bestimmen. Wireguard bietet gute Performance, Voraussetzung, ist allerdings, dass es auf ein ausreichender performante Hardware läuft. Der Raspberry PI 4B erfüllt die Anforderungen NAS Geräte sind zu schwach.
Da VPN für ein Fernzugriff zur Anwendung kommen, sind die Performance sehr stark von der jeweiligen Internet Anbindungen und Leistungsfähigkeit der beteiligten Systeme abhängig.
Auch wenn die Tests nicht unbedingt nach alle Regeln der Kunst durchgeführt. Als VPN Komponente wurde nur Wireguard verwendet. Die Test mit der Verschlüsselungsgeschwindigkeit (openssl) berücksichtigt jedoch AES. Damit sollten sie gute Anhaltspunkten über den Betrieb einen VPN.
Die lokale Adresse des VPN Tunnel sollte idealerweise im Bereich:
Einige Adressenbereiche scheiden aus, nämlich diejenigen die vom Router im Heimnetz verteilt werden.
Einige Anbieter von VPN Lösungen nutzen den Bereich 100.64.0.0/10, dies kann zur Adressenkollision führen, wenn man ein DS-Lite Verbindung hat.
Diese Adressenbereiche sind die reservierte Adressenbereiche für Testzwecke und sind ebenfalls lokale Adressen die nicht im Internet weitergeleitet werden.
NAT verbirgt Nachteile und ist nur notwendig, wenn ein FULL-VPN Betrieb angestrebt ist (Alle Zugriffe auf externe Dienst laufen über das Heimanschluss).
Bei eine “Client to Site” Verbindung ist NAT nicht notwendig. Mit eine Fritz!box ist es möglich ein Smartphone als VOIP-Endgerät zu registrieren und über das VPN zurückzugreifen. Würden NAT Regeln vorgesehen sein, müsste ein speziellen Programm wie siproxd verwendet werden und das VOIP-Client mit weitere SIP-Routen konfiguriert sein. Manche Applikationen erlauben es, andere nicht.
Damit die unterschiedlichen Systeme im Subnetz des VPNs erreicht werden können, muss sichergestellt werden, dass der Router nicht diesen Verkehr, wie bei AVM Routern blockiert. Dafür sind zusätzliche Routen zu setzen. Bei Router manchen anderen Herstellern sind spezielle Vorkehrungen nicht notwendig, leider gilt auch, dass einige Hersteller alles verbaut haben.
Für der Zugriff auf einzelnen Systemen des Heim LAN dürfte IPv6 unnötig sein, die Geräte sollten über einer IPv4 Adresse verfügen.
Das VPN sollte allerdings sowohl über IPv4 wie IPv6 erreichbar sein. Wenn öffentlich passende Adressen nicht vorhanden sind, kann eine Verbindung nicht erfolgen. Eine Konstellation die eine Verbindung verbittet wäre ein Heim Anschluss mit CGN bzw. Dual-Stack-Lite (nur IPv6 erreichbar) und ein Mobile Gerät, der nur über IPv4 erreichbar ist.
Ein Ausweg besteht darin, ein VPS (Virtuelle Privat Server) zu mieten und ihn als VPN Server einzurichten. Ein zusätzliche Vorteil ist, dass eventuelle Adressenänderungen des Heimanschluss die Erreichbarkeit nicht beeinflussen und ein DynDNS Dienst unnötig wird.
Sollte der Bedarf bestehen der VPN im Full-VPN Modus (alle Internetzugriffe erfolgen durch den eigenen Anschluss), soll IPv6 Zugriffe möglich sein. Hier ist möglicherweise NAT IPv6 nötig und Pflicht für IPv4.
Für den Hauptzweck, dass erreichen der verschiedene Geräte im Heimnetz, ist es zweckmäßig die Geräte im Netz per Name erreichen zu können, damit sollten Vorkehrungen beim Einrichten des VPN getätigt werden.
Für Mobile Geräte können die Geräte so eingestellt werden, dass die DNS Abfragen über eine verschlüsselte und gesicherte Verbindung erfolgen (DNS über TLS (doT) oder DNS über HTTPS (DoH)). Damit dürfte der Bedarf ein Full-VPN zu nutzen wesentlich geringer sein.
Die Autorisierung, eine VPN Verbindung zu nutzen kann mit ein Login verbunden sein, eventuell zusätzliche Zertifikate oder Client gebunden sein. Im letzten Fall hat jeden, der ein entsprechenden Gerät verfügt, Zugriff auf der Dienste des Heim LAN, sofern sie nicht über Authentifizierung bedürfen, dies stellt kein Nachteil dar.
Dienste die angeboten werden (Web, SSH, …) werden gerne attackiert und stellen ein Risiko dar. Solche Dienste können leicht entdeckt und Sicherheitslücken können zur super GAU führen.
Über ein VPN kann der Zugriffen auf den interne Ressourcen gefahrlos erfolgen.
Ein Notebook, den man auf Reise mit nimmt, kann abhanden kommen oder irgend jemanden kann ein physikalische Zugriff auf das Gerät haben. Ein sogenannten Bios-Password, das Login im System bieten keinerlei Schutz. Ein Zugriff auf der Daten ist leicht möglich. Wenn eine Linux Live-Distribution gebootet werden kann, ist ein voller Zugriff auf der Datenträger vorhanden. Sollte das Gerät nicht bootbar sein, kann der Datenträger entfernt werden und an ein passenden Rechner angeschlossen werden.
Das einzige Verfahren der eine ausreichenden Sicherheit gewährt, ist es die Daten verschlüsselt zu speichern (BitLocker für Windows, LUKS unter Linux, FileVault für Mac OSX).
Firewall sind auf jeden Systeme empfehlenswert, auch wenn doppelt genäht nicht wirklich immer besser ist. Wurde ein System im LAN kompromittiert, sind anderen System, im Netz, sehr stark gefährdet. Bei tragbare Geräte, wie ein Notebook, der nicht ausreichend geschützt ist, kann, wenn er in fremdem Händen kommt relativ leicht im fremden Netz eingedrungen werden.
Dementsprechend sollten auch ein Firewall auf das VPN Gateway betrieben werden.
Damit man auf das Heimnetz zurückgegriffen werden kann, müssen die Geräte wissen wie die IPv4 Bzw. IPv6 Adresse lautet. Befindet sich der VPN Gateway oder Server hinter ein CGN Anschluss muss die Verbindung über IPv6 erfolgen. Dies kann nur funktionieren wenn das mobile System auch eine globale IPv6 Adresse erhalten hat.
Ein Ausweg ist es ein Server bei ein Dienstleister zu mieten. Am günstigsten sind Virtuelle Private Server (VPS), die Kosten, je Monat, betragen nur wenige € (ca. 1 bis 5 €). Damit kann das VPN sowohl über eine feste öffentliche IPv4 wie auch über eine statische IPv6 Adresse. Damit entfällt auch die Pflicht zu eine DynDNS Dienst.
In Deutschland dürfte kaum ein Anbieter Anschlüsse mit ausschließlich IPv4 zur Verfügung stellen. Selbst Telefonica (O2) der lange kein IPv6 für mobile Telefone vorsah hat es geändert. Damit könnte auf eine öffentliche IPv4 Adresse verzichtet werden. Da die IPv6 Adressen, die zur Verfügung gestellt werden meistens dynamisch sind (sie können sich ändern, natürlich wenn man es nicht gebrauchen kann), muss ein DynDNS Dienst (meistens kostenpflichtig) genutzt werden. Manche Anbieter, wie AVM, bieten solch ein Dienst kostenlos an.
Bei eine direkte Verbindung zum VPN-Server im Heimnetz, sollte die Übertragungsrate höher sein als über der Umweg mittels einen VPS. Sollte man dennoch ein VPS betreiben und Optimierungen anstreben, könnte ein dedizierte DynDNS Dienst installiert werden, dies bedeutet aber ein höheren Aufwand.
In viele Fälle reichen die Möglichkeiten von wg-quick. Manches lässt sich allerdings nicht so leicht realisieren.
Bei der Verwendung von wg-quick dürfen die Konfigurationsvariablen Address, DNS, PostUp und PreDown.
Bei der DNS Anweisung kann zusätzlich eine “Suchdomäne” angegeben werden, beispielsweise “fritz.box” wenn das Heimnetz über der Fritz!Box betrieben wird. Mit der Zuweisungen bei PostUp bzw. PreDown können auch Scripts aufgerufen werden, damit kann ein wenig mehr erreicht werden.
Ich ziehe es vor jedoch die eigene Scripte zu verwenden, es erlaubt einiges mehr ohne wesentlich mehr Aufwand und das Testen vereinfacht sich. Zudem werden Dinge, die ich als unangebracht empfinde, nicht verwendet. Mit eigene Scripte können Fälle gelöst werden die sonst nicht ohne weiteres erreichen lassen.