OpenWrt verwandelt einen funktionsreduzierten Heimrouter in eine vollwertige Linux-Distribution mit Fokus auf Routing, WiFi, Firewall und VPN. Die Bedienung läuft über eine Weboberfläche oder über die Kommandozeile. OpenWrt versteckt keine Features hinter kostenpflichtigen Lizenzen. Mit OpenWrt beherrscht der Router VPN, Firewall, Werbefilter, Gäste-WiFi, Quotas und Lastverteilung.
Dieses Buch ist kein Fachbuch über die Theorie von VPN, sondern ein Buch für Praktiker über die Fähigkeiten von OpenWrt, ein VPN aufzubauen und zu betreiben. Das Buch untersucht nur die Möglichkeiten von OpenWrt und nicht alle Optionen einer Software. Beispielsweise können die ipsec-tools aus Kapitel 7 deutlich mehr als das OpenWrt-Startskript implementiert. Der OpenWrt-Praktiker soll nicht das jeweilige Handbuch ersetzen, sondern die typischen Anwendungsfälle schildern und mit praktischen Übungen belegen.
Die Kapitel geben einen Einstieg ins Thema und enthalten ein oder zwei Fallbeispiele. Sobald die Grundlagen verstanden sind und das Szenario im eigenen Labor funktioniert, kann der Leser die Aufgabenstellung auf seinen eigenen Use-Case anwenden.
Der erste Band der Buchreihe Der OpenWrt-Praktiker vermittelt einen Einstieg in OpenWrt und deckt die Grundlagen ab. Die Kapitel sind eine Bedienungsanleitung, die OpenWrt installieren, Netzschnittstellen einrichten und IP-Adressen vergeben. Nach der initialen Einrichtung behandelt Band 1 auch die Kommandozeile UCI, die Paketverwaltung und die Systemadministration mit Überwachung eines OpenWrt-Geräts. Der erste Band richtet sich an Leser, die mit OpenWrt keine Erfahrung haben und ins Thema einsteigen wollen. Wer bereits einen OpenWrt-Router im Einsatz hat, kann mit dem zweiten oder dritten Band starten.
Der zweite Band zeigt, welche Möglichkeiten OpenWrt bietet, wie die Software intern arbeitet und welche Dienste aus der Cloud eine mögliche Ergänzung sind. Die Themen sind für Anwender mit Vorkenntnissen konzipiert. Sie vermitteln dem Leser fortgeschrittene Inhalte, Tipps für die Fehlersuche und ein großes Kapitel zur Firewall mit Adressumsetzung.
Der dritte Band behandelt Anwendungsfälle aus der Praxis und liefert die passende Lösung mit OpenWrt. Die Kapitel erklären Mesh-Netze, dynamisches Routing mit OSPF, Hochverfügbarkeit mit VRRP, zentrales Management mit OpenWISP, Werbefilter und WAN-Lastverteilung. Band 3 richtet sich an Anwender mit soliden Grundkenntnissen.
Band 4 beschäftigt sich mit Virtuellen Privaten Netzwerken. Kapitel 1 beginnt mit dem Klassiker IPsec und den beiden Implementierungen Strong-Swan und Libreswan. Anschließend kontert Kapitel 2 mit OpenVPN und deckt damit die beiden bekanntesten Vertreter ab. Der Newcomer Wire-Guard folgt in Kapitel 3 und macht das Trio komplett.
OpenConnect aus Kapitel 4 ist die Antwort der Community auf kommerzielle VPN-Implementierungen von Cisco, Juniper und Palo Alto. In Kapitel 5 zaubert Tinc ein VPN-Mesh über alle Router und findet die kürzesten Wege durch die VPN-Wolke. Ähnlich arbeitet Kapitel 9 mit einem Multipunkt-VPN und dem Ziel, kompatibel zur DMVPN-Lösung von Cisco zu sein. Dazu verwendet OpenWrt die GRE-Technik aus Kapitel 8. Erneut geht es in Kapitel 7 um VPN-Produkte von Cisco, und wie OpenWrt mit Racoon und den ipsec-tools Kompatibilität schafft.
Deutlich größere Ziele hat ZeroTier in Kapitel 6 mit der Ansage, ein weltweiter Ethernet-Switch auf VPN-Basis zu sein. In Kapitel 10 versucht iodine per DNS-Tunnel eine restriktive Firewall auszutricksen. Den Abschluss macht Kapitel 11 mit SoftEther VPN, welches als Allzweckwaffe alle großen VPN-Protokolle unterstützt und die VPN-Router zentral verwaltet.
Wenn zwei entfernte Netze miteinander kommunizieren wollen, dann läuft das klassischerweise über eine eigene Leitung bzw. über ein privates Netzwerk. Ob Standleitung oder Wählverbindung, diese Netzkopplung ist entweder teuer oder langsam.
Die Alternative ist die Verwendung des Internets als verbindendes Element zwischen den eigenen Netzen. Das Internet, als öffentliches Netzwerk, wird als quasi-privates Netz benutzt. Die eigene Verbindung ist nur virtuell als Virtuelles Privates Netzwerk (VPN) vorhanden.
OpenWrt bietet verschiedene Methoden, um ein VPN technisch aufzubauen. Die Software implementiert den Schutz der transportierten Daten, die Authentifizierung der VPN-Sitzung, den regelmäßigen Schlüsselaustausch und prüft, ob die Pakete unterwegs verändert wurden.
Alle Kapitel basieren auf einem beispielhaften Netzwerk mit vier OpenWrt-Routern. Abbildung 1 auf Seite 13 stellt das Labornetz als Netzdiagramm dar und ist identisch mit dem Diagramm in den anderen Bänden dieser Buchreihe. Es repräsentiert einen Netzaufbau mit mehreren Standorten. Die Kapitel benutzen meist nur Teile dieses Netzwerks zur Untersuchung. Tabelle 1 auf Seite 12 listet alle IP-Adressen der Router und über welche Netzsegmente sie verbunden sind.
OpenWrt entwickelt sich weiter, unterstützt neue Gerätetypen und erhält weitere Features. Leider kann die Dokumentation mit der Entwicklung nicht immer mithalten und daher verwenden die Bände der Buchreihe Der OpenWrt-Praktiker nicht dieselbe Version, sondern benutzen die aktuelle Version von OpenWrt. Folglich können die Abbildungen und Kommandoausgaben zwischen den Bänden und den eigenen Experimenten unterschiedlich ausfallen.
| Gerät | Interface | Funktion/Netz | IPv4 | IPv6 |
| RT-1 | eth0 eth1 eth2 eth3 |
Management Standort-1 WAN-1 WAN-2 |
10.5.1.1 10.1.1.1 198.51.100.1 192.0.2.1 |
fd00:5::1 fd00:1::1 2001:db8:1::1 2001:db8:2::1 |
| RT-2 | eth0 eth1 eth2 eth3 |
Management Standort-2 WAN-3 WAN-1 |
10.5.1.2 10.2.1.2 203.0.113.2 198.51.100.2 |
fd00:5::2 fd00:2::2 2001:db8:3::2 2001:db8:1::2 |
| RT-3 | eth0 eth1 eth2 |
Management Standort-3 WAN-3 |
10.5.1.3 10.3.1.3 203.0.113.3 |
fd00:5::3 fd00:3::3 2001:db8:3::3 |
| RT-4 | eth0 eth1 eth2 eth3 |
Management Standort-4 WAN-3 WAN-2 |
10.5.1.4 10.4.1.4 203.0.113.4 192.0.2.4 |
fd00:5::4 fd00:4::4 2001:db8:3::4 2001:db8:2::4 |
| labsrv | eth0 eth1 |
Management Standort-1 |
10.5.1.7 10.1.1.7 |
fd00:5::7 fd00:1::7 |
Tabelle 1: Alle Geräte mit Netzadaptern, Funktion und IP-Adressen
Abbildung 1: Das Labornetzwerk als Vorlage für die folgenden Kapitel
IPsec ist der Klassiker für die gesicherte Übertragung zwischen zwei Routern. Dabei ist IPsec keine fertige Software, sondern eine Sammlung von Protokollen, die sich um Vertraulichkeit, Integrität und Authentizität bemühen. Das Ergebnis ist eine abgesicherte Verbindung zwischen privaten Netzen durch das öffentliche Internet. Die damit aufgebaute Netzkopplung ist das Virtuelle Private Netzwerk (VPN).
Private Netze haben meist private Adressen, die im Internet nicht transportiert werden. Wer überzeugt die Internet-Router, dass sie Pakete von Standort-1 zu Standort-2 transportieren sollen? Das erledigt ein Tunnel, der die technische Grundlage für ein VPN ist. Der verantwortliche Tunnel-Router in Standort-1 verpackt die ausgehenden IP-Pakete in einen zusätzlichen IP-Header und sendet sie zum Router am anderen Ende des Tunnels in Standort-2. Der innere IP-Header hat die privaten Adressen der Standorte 1 und 2, und der äußere Header hat die öffentlichen Adressen der beiden Tunnel-Router. Der Tunnel-Router von Standort-2 entfernt den äußeren Header vom empfangenen Paket und leitet dessen Inhalt als vollwertiges Paket zum Zielrechner weiter. In Abbildung 1.1 sind zwei kleine Netze per VPN-Tunnel verbunden.
Die Internet-Router sehen nur den äußeren Header und bewegen die VPN-Pakete genau wie alle anderen Pakete. Für sie stellt ein VPN-Paket keine besondere Aufgabe dar, da sie die innere Struktur des Pakets nicht sehen. Die Teilnehmer der privaten Netze bekommen von der Tunnelei nichts mit. Für sie sind die Gegenstellen im anderen Netz direkt adressierbar.
Abbildung 1.1: Ein getunneltes IP-Paket mit seinen Kopfzeilen
Die übertragenen Pakete fließen durch das unsichere Internet. Dabei passieren sie mehrere Internet Service Provider. Ihr Pfad ist vom Betreiber des VPNs nicht beeinflussbar. Für die Sicherheit der VPN-Verbindung gibt es ein wirksames Rezept gegen neugierige Mitleser: Verschlüsselung.
Im Prinzip ganz einfach: Bevor ein Paket das Internet betritt, wird sein Inhalt verschlüsselt. Und nachdem es das Internet verlässt und das private Netz erreicht, wird der Inhalt wieder entschlüsselt. Abbildung 1.2 zeigt das IP-Paket mit und ohne Sicherung durch IPsec.
Abbildung 1.2: Ein IP-Paket mit und ohne IPsec-Kopfzeile
Die technische Umsetzung ist schon etwas komplizierter, denn Kryptografie wird nicht einfach nur eingeschaltet. In der Praxis gibt es Kryptoverfahren, Algorithmen, Einwegfunktionen, Schlüsselaustausch und die magische Frage der Authentifizierung. Alle diese Methoden sollen helfen, dass die verschlüsselten Pakete für einen Unbefugten unleserlich sind.
Die WAN-Netze stellen das Internet dar, welches keine privaten IP-Adressen transportiert. Die Standortnetze sollen mithilfe der OpenWrt-Router und VPN-Tunnel kommunizieren. Der erste VPN-Tunnel führt von RT-1 zu RT-3 und eine weitere VPN-Beziehung reicht von RT-1 zu RT-2. Der Aufbau ist in Abbildung 1.3 dargestellt.
Abbildung 1.3: VPN-Tunnel verbinden die Standortnetze über das Internet
In der Praxis könnte zwischen den Tunnelendpunkten ein Router mittels Adressumsetzung (vgl. Kap. 2 aus Band 2) die IP-Adressen verändern. Darauf reagiert IPsec sehr allergisch und verweigert der Gegenstelle die Authentifizierung. Für dieses Szenario wird RT-4 im Datenpfad zwischen RT-1 und RT-3 sitzen und später die Adressen der Pakete so manipulieren, wie es ein DSL-Router für seine angeschlossenen Clients erledigt. Ausgehende Pakete von RT-3 erhalten beim Passieren von RT-4 eine andere Absenderadresse und erreichen RT-1 mit falscher Identität.
Der Router RT-1 ist über mehrere Leitungen mit dem Internet verbunden. Grund genug zwei redundante VPN-Tunnel zu erstellen, die einen Ausfallschutz der Internetverbindung schaffen. Wie erkennt ein VPN-Tunnel, dass sein Partner nicht mehr erreichbar ist? Die Erkennung von toten Gegenstellen (Dead Peer Detection, DPD) ist Voraussetzung für ein Umschalten von der primären VPN-Verbindung auf den Backup-Tunnel.
OpenWrt hat mehrere Anbieter im Katalog, die eine IPsec-Implementierung liefern. Dieses Kapitel stützt sich auf StrongSwan, da es vielseitig ist und die meisten Use-Cases abdeckt. Am Ende folgt ein kurzer Abstecher zur Alternative Libreswan.
Das Software-Repository enthält über 80 Pakete mit strongswan im Namen. Die Paketbauer unterteilen das Gesamtpaket in einzelne Bausteine und Module, sodass nur exakt die Pakete installiert werden, die das zukünftige VPN-Gateway benötigt. Für das beispielhafte Szenario reicht eine minimale Auswahl, welches die wichtigsten Komponenten bereitstellt:
opkg update
opkg install strongswan-minimal
Der Aufbau eines VPN-Tunnels ist aufwendiger als der Dreiwegeaufbau im TCP-Protokoll, da sich die Parteien über Verschlüsselung, Authentifizierung, IP-Netze und Gültigkeit der Verbindung einigen müssen. Für die Aushandlung dieser Parameter hat sich das Protokoll Internet Key Exchange (IKE) durchgesetzt.
Die Konfiguration einer IPsec-Verbindung bei OpenWrt läuft in fünf Schritten ab:
Vorab erhält das UCI etwas Vorbereitung und die allgemeinen Einstellungen der IPsec-Umgebung:
touch /etc/config/ipsec
uci add ipsec ipsec
uci add_list ipsec.@ipsec[0].listen=‘‘
Ohne weitere Konfiguration verwendet OpenWrt die neuere IKE-Version 2. Wenn ein VPN-Tunnel zu einer älteren Gegenstelle führt, schaltet der folgende UCI-Befehl für den jeweiligen Partner auf Version 1 um:
uci set ipsec.rt3_lan.keyexchange=ikev1
Der weitere Ablauf ist beispielhaft für Router RT-1. Auf der Gegenseite benötigt RT-3 eine entsprechende Anpassung bei den Subnetzen und bei der Gegenstelle.
In diesem ersten Schritt der Verhandlung authentifizieren sich die beiden Router gegenseitig und bilden eine „Steuerungs”-Verbindung (Security Association, SA). Das gelingt nur, wenn die gewählten Einstellungen für Diffie-Hellman-Gruppe (DH), Schlüsselalgorithmus, Hashverfahren und Schlüssel harmonieren. Das Ziel der Phase 1 ist eine gesicherte und verschlüsselte Verbindung zwischen den VPN-Partnern, durch die die Werte für den eigentlichen VPN-Tunnel in Phase 2 sicher verhandelt werden können.
Hinweis
Für die Wahl der Kryptoalgorithmen gilt die Faustregel: Je höher die Zahl, desto stärker die Verschlüsselung und desto mehr Rechenleistung benötigt die Routerhardware.
Ein Vorschlag zur Phase 1 mit akzeptablem Sicherheitsniveau enthält die beliebte Kombination aus AES und SHA:
uci add ipsec crypto_proposal
uci rename ipsec.@crypto_proposal[-1]=p1_aes_sha
uci set ipsec.p1_aes_sha.encryption_algorithm=aes128
uci set ipsec.p1_aes_sha.hash_algorithm=sha256
uci set ipsec.p1_aes_sha.dh_group=modp2048
Hinweis
Ohne einen konfigurierten Vorschlag verwendet StrongSwan eine Kombination aus AES128, SHA256 und modp3072.
In der zweiten Phase verhandeln die Router eine „Daten”-Verbindung. Wenn die Angebote (Proposal) der VPN-Gateways übereinstimmen, werden über diese Datenverbindung die IP-Pakete der Anwender transportiert.
uci add ipsec crypto_proposal
uci rename ipsec.@crypto_proposal[-1]=p2_aes_sha
uci set ipsec.p2_aes_sha.hash_algorithm=sha256
uci set ipsec.p2_aes_sha.encryption_algorithm=aes256
uci set ipsec.p2_aes_sha.dh_group=modp4096
Hinweis
Wenn die Konfiguration keine Settings für die Phase 2 enthält, fällt StrongSwan auf AES128 mit SHA256 zurück.
uci add ipsec tunnel
uci rename ipsec.@tunnel[-1]=rt3_lan
uci set ipsec.rt3_lan.local_subnet=10.1.1.0/24
uci set ipsec.rt3_lan.remote_subnet=10.3.1.0/24
uci set ipsec.rt3_lan.crypto_proposal=p2_aes_sha
uci add ipsec remote
uci rename ipsec.@remote[-1]=rt3
uci set ipsec.rt3.enabled=1
uci set ipsec.rt3.gateway=203.0.113.3
uci set ipsec.rt3.authentication_method=psk
uci set ipsec.rt3.pre_shared_key=OpenWrtPraktiker
uci add_list ipsec.rt3.crypto_proposal=p1_aes_sha
uci add_list ipsec.rt3.tunnel=rt3_lan
Die Gegenstelle (remote) enthält einen Vorschlag für die Phase-1 (crypto_proposal) und einen Tunnel (tunnel), welcher wiederum einen Phase-2-Vorschlag beinhaltet.
uci commit folgt der Startschuss mit:service ipsec restart
Kurz darauf versucht der Router mit seiner Gegenstelle 203.0.113.3 in die Phase 1 einzusteigen und die Verhandlung über Verschlüsselungsalgorith-mus und Schlüssellänge zu führen.
Für die Einrichtung des VPNs auf Router RT-3 ändern sich lediglich die Objekte tunnel und remote. Falls die VPN-Beziehung mehrere IP-Netze transportieren soll, benötigen die OpenWrt-Router mehrere tunnel-Objekte, die bei remote aufgeführt werden.
Aggressive- oder Main-Mode?
Ältere IPsec-Implementierungen sprechen IKE in der Version 1 (vgl. Kap. 7). Diese unterscheidet in der Phase 1 zwischen Main-Modus und Aggressive-Modus, wobei jeder Modus seine Vorteile in verschiedenen Einsatzgebieten ausspielen kann.
OpenWrt benutzt StrongSwan, welcher IKEv2 mitbringt. Diese neue IKE-Version unterscheidet nicht mehr zwischen den beiden Modi. IKEv2 ersetzt IKEv1 und enthält viele Erweiterungen, die sich im Laufe der Jahre in das IKE-Protokoll hineingeschmuggelt haben: NAT- Traversal (siehe Seite 25), Dead Peer Detection (siehe Seite 27), Configuration-Payload (siehe Seite 132) und MOBIKE.
Damit sind die IPsec-Tunnel zwischen RT-1 und RT-3 eingerichtet, und die Gateways versuchen sich gegenseitig zu erreichen. Der Paketfilter (vgl. Kap. 1 aus Band 2) muss unbedingt in dieses Vorhaben eingeweiht werden, damit er die Pakete nicht sperrt.
OpenWrt hat zwar ein paar Einträge zu VPN im Regelwerk hinterlegt, aber diese beziehen sich auf Zugriffe von außen in die LAN-Zone. Im Zweifel sollten eigene Firewallregeln das Problem bewältigen und ankommende VPN-Pakete erlauben. IPsec-VPN-Tunnel benutzen das UDP-Protokoll mit Port 500 zum Aushandeln der Verbindung. Anschließend verwenden die Nutzdaten die Protokolle Encapsulated Security Payload (ESP), Authentica-tion Header (AH), oder einfach nur den UDP-Port 4500, wenn NAT- Traversal (siehe Abschnitt Address Translation auf Seite 25) ein NAT- Gateway entdeckt hat. Die Regeln zum Erlauben dieser Ports und Protokolle sind in Listing 1.1 dargestellt.
In der Voreinstellung erlaubt der Paketfilter von OpenWrt bereits ausgehende IP-Pakete von der LAN-Zone in die WAN-Zone. Weiterhin wird OpenWrt die Quelladresse von ausgehenden IP-Paketen so verändern, dass sie zum WAN-Netz passt. Unglücklicherweise verhindert dieses Verhalten den Datenverkehr durch den VPN-Tunnel.
Die Ursache liegt im Netfilter-Framework des Linux-Kernels. Dort ist festgelegt, dass die Adressumsetzung vor der Verschlüsselung erfolgt. Sobald
uci add firewall rule
uci set firewall.@rule[-1].target=ACCEPT
uci add_list firewall.@rule[-1].proto=esp
uci set firewall.@rule[-1].name=Allow-IPsec-ESP
uci set firewall.@rule[-1].src=wan
uci add firewall rule
uci set firewall.@rule[-1].dest_port=‘500 4500’
uci set firewall.@rule[-1].src=wan
uci set firewall.@rule[-1].name=Allow-IPsec-IKE
uci set firewall.@rule[-1].target=ACCEPT
uci add_list firewall.@rule[-1].proto=udp
uci commit firewall
service firewall restart
Listing 1.1: Die Firewall von OpenWrt erlaubt IPsec-VPN-Tunnel
Netfilter die Quell-IP-Adresse des Pakets von der LAN-IPv4 10.1.1.X in die WAN-IPv4 192.0.2.1 geändert hat, passt die neue Adresse nicht mehr zu den schützenswerten IP-Netzen, welche die Router in der Phase 2 auf Seite 21 ausgemacht haben. Als Folge wird Netfilter das Paket unverschlüsselt auf die Reise ins WAN-Netz schicken.
Abhilfe schafft ein Kommando für Netfilter, das die Adressumsetzung für jene IP-Pakete verhindert, die für einen VPN-Tunnel vorgesehen sind. Die Anweisung dazu findet sich weder in LuCI, noch im UCI, sondern kommt als iptables-Befehl daher:
iptables -t nat -I POSTROUTING -m policy --pol ipsec \
--dir out -j ACCEPT
Damit die Anweisung dauerhafter Bestandteil der OpenWrt-Firewall wird, sollte sie einen Ehrenplatz in der Datei /etc/firewall.user erhalten. Der Eintrag dazu ist über LuCI bei Netzwerk → Firewall → Benutzerdefinierte Regeln möglich.
Dieser kleine Exkurs in die Untiefen von Netfilter hat gezeigt, dass eine VPN-Verbindung datenlos bleibt, auch wenn die Konfiguration (scheinbar) korrekt ist.
OpenWrt lässt seine Filterfunktion auch innerhalb des VPN-Tunnels wirken. Die Firewallregeln beziehen sich dabei auf interne IP-Adressen und filtern Pakete, die durch den Tunnel fließen.
Als zonenbasierte Firewall kann OpenWrt dem VPN-Tunnel eine weitere Firewallzone spendieren und darüber den Datenverkehr kontrollieren. Im einfachsten Fall lässt das Regelwerk alle Pakete aus dem entfernten Netz durch die IPsec-Verbindung passieren, wie es in Listing 1.2 konfiguriert ist.
1 uci set ipsec.@ipsec[0].vpn=vpn
2 uci add firewall zone
3 uci add_list firewall.@zone[-1].subnet=‘10.0.0.0/8’
4 uci add_list firewall.@zone[-1].subnet=‘fd00::/16’
5 uci set firewall.@zone[-1].name=‘vpn’
6 uci set firewall.@zone[-1].input=‘ACCEPT’
7 uci set firewall.@zone[-1].forward=‘ACCEPT’
8 uci set firewall.@zone[-1].output=‘ACCEPT’
9 uci add firewall forwarding
10 uci set firewall.@forwarding[-1].dest=‘lan’
11 uci set firewall.@forwarding[-1].src=‘vpn’
12 uci add firewall forwarding
13 uci set firewall.@forwarding[-1].dest=‘vpn’
14 uci set firewall.@forwarding[-1].src=‘lan’
15 uci commit ; service firewall restart
Listing 1.2: Eine neue Firewallzone für VPN-Tunnel entsteht
Damit das funktioniert, muss sich der VPN-Tunnel in Zeile 1 in die neue Firewallzone vpn begeben. In diesem Beispiel klassifiziert der Paketfilter alle Pakete aus den IP-Netzen in den Zeilen 3 und 4 als VPN-Verkehr und behandelt sie anhand der Zonenrichtlinie.
Der Einsatz eines zusätzlichen Regelwerks ist üblich, wenn sich hinter dem gegnerischen VPN-Router ein unbekanntes Fremdnetz verbirgt, z. B. von einem Partnerunternehmen. Beispielsweise könnte Router RT-1 nur Zugriffe auf bestimmte IP-Adressen seines Standorts erlauben.
Andersherum könnte es, je nach Szenario, Sinn machen, den Netzverkehr durch den VPN-Tunnel in ausgehender Richtung zu filtern. Dann dürfen nur bestimmte Verbindungen den Tunnel betreten.
Wenn alle Teilbereiche der VPN-Verbindung korrekt eingerichtet sind, sollte das ipsec status-Kommando mit Verbindungsinformationen loben. Listing 1.3 zeigt die ausgehandelte VPN-Verbindung zwischen RT-1 und RT-3. Mit dem Zusatz statusall liefert die Konsole auch die übertragenen Pakete und Byte, sowie die verwendeten Algorithmen für Verschlüsselung und Hashing.
root@RT-1:~# ipsec status
Routed Connections:
rt3-rt3_lan{1}: ROUTED, TUNNEL, reqid 1
rt3-rt3_lan{1}: 10.1.1.0/24 === 10.3.1.0/24
Security Associations (1 up, 0 connecting):
rt3-rt3_lan[1]: ESTABLISHED 3 minutes ago, \
192.0.2.1[192.0.2.1]...203.0.113.3[203.0.113.3]
rt3-rt3_lan{3}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: [...]
rt3-rt3_lan{3}: 10.1.1.0/24 === 10.3.1.0/24
Listing 1.3: Der ipsec-Befehl bestätigt einen aufgebauten Tunnel
Ein erfolgreich aufgebauter VPN-Tunnel zeigt sich als Status ESTABLISHED und liefert bei statusall positive Werte für ein- und ausgehende Byte.
Wenn im Pfad zwischen den VPN-Partnern ein Router die IP-Adresse verändert (NAT, vgl. Kap. 2 aus Band 2), steht IPsec mit IKEv1 vor einem Problem, denn es kann nicht zwischen einer gewollten IP-Änderung und einer bösartigen Manipulation des Paketinhalts unterscheiden. Als Folge wird die VPN-Verbindung scheitern.
Da NAT in vielen Umgebungen eher die Regel als die Ausnahme ist, benutzen IPsec-Gateways dafür NAT- Traversal. Dabei verpackt das Gateway seine ausgehenden IPsec-Pakete in unscheinbaren UDP-Datagrammen, die adressverändernde Router und Firewalls passieren können. Das originale IPsec-Paket bleibt unverändert, sodass alle Prüfsummen und Signaturen stimmen.
Das Laborgerät RT-4 stellt das Hindernis der Adressumsetzung dar, indem es die Pakete von RT-3 mit seiner eigenen IP-Adresse vom Interface eth3 überschreibt. Die Konfiguration ist in Abbildung 1.4 dargestellt.
Abbildung 1.4: Adressumsetzungen sind Stolpersteine für IPsec
Der VPN-Tunnel zwischen RT-1 und RT-3 wird kurz nach dem Aufbau keine Daten mehr transportieren, da keine Pakete von der ausgehandelten IPv4-Adresse bei RT-1 ankommen.
Router RT-1 muss seinen Partner durch andere Kriterien erkennen, als anhand der Absenderadresse. Die elegante und geschützte Variante ist die Identifizierung des VPN-Partners mittels einer Kennung. Im einfachsten Fall ist diese Kennung die IP-Adresse der Gegenstelle. Erlaubt sind beliebige Buchstabenkombinationen. Hiermit entsteht ein Stück mehr Sicherheit, wenn es darum geht, die Anmeldeversuche von unbekannten VPN-Partnern zu verhindern, bevor sie den Pre-shared Key erraten dürfen.
Welche Änderungen an der VPN-Konfiguration sind notwendig, wenn die Adressen unterwegs manipuliert werden? Zuerst akzeptiert Router RT-1 sein Gegenüber anhand einer beliebigen IP-Adresse:
uci set ipsec.rt3.gateway=any
Mit den Einstellungen aus Listing 1.4 erwartet RT-1 von seiner Gegenstelle eine Kennung, um Anfragen adressneutral zu beantworten. Damit erkennt RT-1 den Autor der IKE-Pakete, auch wenn die IPv4-Adresse der ankommenden Pakete unterwegs durch NAT verändert wurde. RT-1 wird sich ebenfalls nicht mehr mit seiner IP-Adresse, sondern mit einer Kennung identifizieren. Router RT-3 benötigt eine entsprechende Konfiguration mit vertauschten Kennungen.
uci set ipsec.rt3.local_identifier=Kennung_von_RT1
uci set ipsec.rt3.remote_identifier=Kennung_von_RT3