Pseudowire aka L2TPv3 - with - OpenSource

Transkript

1 Pseudowire aka L2TPv3 - with - OpenSource OpenWrt - Terminal Consulting - Olanis Contact: Autor: Last Update: heil@terminal-consulting.de pseudowire.tex :47:40Z heil This document may not, in whole or in part, be reproduced or distributed by another company, body, or individual, other than OpenWrt - Terminal Consulting - Olanis. This restriction includes the reproduction or distribution in any form or by any electronic or mechanical means, including, but not exclusively applied to, photo copies or recordings or through the means of any kind of information storage or retrieval system - unless excplicitly authorised in written form by OpenWrt - Terminal Consulting - Olanis Errors and changes reserved. The OpenWrt - Terminal Consulting - Olanis can neither be held liable nor made responsible in any way and under no circumstances for any form of direct or indirect damages that may or may not result from the application of the information contained in the aforementioned document. This extends to the application of any software components or algorithms or procedures herein described. All trademarks and other forms of intellectual property used in this document are trademarks of their respective owners.

2 1 EINLEITUNG 1 Einleitung Beim Betrieb heutiger Rechenzentren wird oft die Frage aufgeworfen, wie bei Ausfällen von Servern reagiert werden sollte. Dazu kann ein entferntes Rechenzentrum bzw. Standort mit einer symmetrischen breitbandigen Anbindung helfen. In diesem zweiten RZ (Rechenzentrum) könnnen preiswerte Server Ihren Platz finden. Daten vom primären RZ können so fortlaufend in das sekundäre übertragen werden. Fallen ein oder mehrere Server im primärem RZ einem Hardware-Schaden zum Opfer kann nun der Betrieb im sekundären fortgesetzt werden. Es müsste nur einen Weg geben, die beiden Standorte auf Layer 2 so zu verbinden, dass der gleiche Adressbereich auf beiden Seiten simultan verwendet werden kann. Mit teurer, proprietärer Hardware wie Cisco ist dies nahezu problemlos möglich. Hier kann Pseudowire Switching eingesetzt werden. Die Abbildung 1 veranschaulicht dies. Abbildung 1: Quelle: Für Linux existieren ebenfalls Möglichkeiten eine Layer 2 Kopplung mittels VPN 1 oder unverschlüsselt über das Internet herzustellen. Darunter fallen beispielsweise: OpenVPN - im Bridged to Bridged Modus Dazu werden auf der Server-Seite die Optionen server-bridge... up "/etc/openvpn/bridge-start" dev tap0 verwendet. Im entfernten RZ wird ein Client mit zwei VLANs ausgestattet. Mit dem ersten kann dieser eine Verbindung zum VPN-Server herstellen. Das zweite ist ein unbenutzes, in welches der Layer 2 Verkehr des ersten transferiert werden soll. In unserem Beispiel ist dies VLAN 111, welches auf dem Client als Bridge verfügbar ist. up "/etc/openvpn/bridge-start" client # /etc/openvpn/bridge-start #!/bin/bash 1 VPN - Virtual Private Network 1

3 2 1 EINLEITUNG ################################# # Set up Ethernet bridge on Linux # Requires: bridge-utils ################################# # Define Bridge Interface br="vlan111" # Define list of TAP interfaces to be bridged, # for example tap="tap0 tap1 tap2". tap="$1" for t in $tap; do /usr/sbin/openvpn --mktun --dev $t done for t in $tap; do /usr/sbin/brctl addif $br $t done for t in $tap; do /sbin/ifconfig $t promisc up done Das Transferieren des Layer 2 Verkehrs in das nicht verwendete VLAN 111 hat den Vorteil dass sich lokaler Traffic nicht mit dem des entfernten RZ mischen kann. Ein Nachteil dieser Variante ist der geringere Datendurchsatz bedingt durch die Architektur von OpenVPN. Es sind einfach zu viele Interrupts für das ständige Kopieren vom Kernel in den Userspace und wieder zurück, notwendig. Das zeigt sich vor allem dann sehr deutlich, wenn Embedded Hardware zum Einsatz kommt. rbridge - Abbildung 2: Quelle: Hier wird ein beidseitiger UDP Tunnel aufgebaut, um zwei Ethernet-Segmente miteinander zu verbinden. Eine Verschlüsselung kann beispielsweise durch IPSEC 2 hinzugefügt werden. Leider ist das Programm nicht im Quellcode verfügbar und damit nur begrenzt einsatzfähig. 2 IPSEC -

4 3 1 EINLEITUNG und weitere Es kann auch L2TP über IPSEC zur Anwendung kommen. Allerdings kann dies nicht transparent in ein VLAN gebridged und nur vom Client benutzt werden. Genau das ist der Grund warum L2TPv3 bzw. Pseudowire als Standard definiert wurde. 1.1 L2TPv3 mit OpenWrt Es wurde die Frage aufgeworfen, warum es gerade für Linux keine L2TPv3 Implementation gibt. Das hat sich mit dem Release von Kernel grundlegen geändert, da L2TPv3 rudimentär verfügbar ist. Siehe dazu Mittlerweile ist auch Kernel stabil und damit L2TPv3 für Linuxer(innen) verfügbar. Allein ist das noch kein Grund es einzusetzen, da es vorher noch einige Hürden zu bewältigen gilt: Linux installieren Firewall konfigurieren IPSEC Tunnel einrichten IPSEC Tunnel überwachen L2TPv3 Tunnel starten und auf beiden Seiten bridgen Bisher hat immer noch keine Distribution L2TPv3 in ein Netzwerk-Setup anständig verpackt. Das heisst bis auf OpenWrt. Dort kann es einfach in der Netzwerk-Konfiguration /etc/config/network eingetragen werden. tunnel Wer glaubt, OpenWrt könne nur auf Linksys Routern betrieben werden, der irrt. So stehen viele Virtualisierungen zur Auswahl, die es erlauben, auch sehr performante Netzwerkoperationen durchzuführen: KVM - Kernel Based Virtual Machine XEN - ESX/ESXI - VMware Virtual Box - Oracle OpenWrt ist äußert klein, anpassungsfähig und hat eine sehr gute Buildchain, die es erlaubt, jederzeit eigene Anpassungen einfließen zu lassen.

5 4 2 PRAKTISCHE REALISIERUNG 2 Praktische Realisierung Nach der trockenen Theorie soll nun eine praktische Realisierung folgen. Diese geht von folgenden willkürlich gewählten Annahmen aus: externe IP-Adresse im primären RZ ( ), Gateway ( ), Netzmaske (Class C) internes Netz /24 externe IP-Adresse im sekundären RZ ( ), Gateway ( ), Netzmaske (Class C) unbenutztes VLAN 111 im sekundären RZ L2TPv3 over IPSEC IPSEC / /32 primäres RZ Disaster RZ / /24 Webserver Backup Webserver Abbildung 3: Überblick Desaster RZ Annahmen Die Abbildung 3 zeigt, wie die Layer-2-Kopplung etabliert wird. Zunächst wird ein IPSEC Tunnel von der zur aufgebaut. War dies erfolgreich, bekommen die Tunnel-Endpunkte die /32 und /32 zugewiesen. Über diese kann nun der L2TPv3 Tunnel initialisiert werden. Der Schritt über IPSEC ist notwendig, da die Verbindung in jedem Fall kryptografisch geschützt werden sollte. Da diese im Kernel abläuft und von Crypto-Hardware profitieren kann, sind kleine Latenzen und großer Datendurchsatz zu erwarten. Auch L2TPv3 ist Kernel-basierend. Und das macht es auch so attraktiv im Hinblick auf die angestrebten Eigenschaften.

6 5 2 PRAKTISCHE REALISIERUNG 2.1 Realisierung mit OpenWrt Um das Setup mit OpenWrt abbilden zu können, müssen im primären RZ eine Instanz l-01 und auf der anderen Seite eine Instanz l-02 mit folgenden Konfigurationen etabliert werden. l-01 /etc/config/network config interface wan option ifname eth0 option type bridge option proto static option ipaddr option netmask option gateway config interface lan option ifname eth1 option type bridge option proto l2tp option ipaddr option netmask option encap udp option sport 1701 option dport 1702 option localaddr option peeraddr /etc/config/firewall config rule option src wan option proto gre option target ACCEPT config rule option src wan option proto esp option target ACCEPT config rule option src wan option proto ah option target ACCEPT config rule option src wan

7 6 2 PRAKTISCHE REALISIERUNG option dest_port 500 option proto udp option target ACCEPT config rule option src wan option dest_port 4500 option proto udp option target ACCEPT /etc/ipsec.conf #Es wird OpenSwan verwendet conn to-secondary type=tunnel left= leftnexthop= leftsourceip= leftsubnet= /32 leftid="primary@rz" right= rightnexthop= rightsourceip= rightsubnet= /32 authby=secret auto=start ike=aes128-sha-modp1024 esp=aes128-sha1 /etc/monitrc check process pluto with pidfile /var/run/pluto/pluto.pid start program = "/etc/init.d/ipsec restart" stop program = "/etc/init.d/ipsec restart" # check host secondary with address if failed icmp type echo count 5 with timeout 30 seconds then exec "/sbin/ifup lan" l-02 /etc/config/network config interface wan option ifname eth0 option type bridge option proto static option ipaddr option netmask

8 7 2 PRAKTISCHE REALISIERUNG option gateway config interface lan option ifname eth1 option type bridge option proto l2tp option ipaddr option netmask option encap udp option sport 1702 option dport 1701 option localaddr option peeraddr /etc/config/firewall wie bei l-01 /etc/ipsec.conf #Es wird OpenSwan verwendet conn to-primary type=tunnel left= leftnexthop= leftsourceip= leftsubnet= /32 rightid="secondary@rz" right= rightnexthop= rightsourceip= rightsubnet= /32 authby=secret auto=start ike=aes128-sha-modp1024 esp=aes128-sha1 /etc/monitrc check process pluto with pidfile /var/run/pluto/pluto.pid start program = "/etc/init.d/ipsec restart" stop program = "/etc/init.d/ipsec restart" # check host secondary with address if failed icmp type echo count 5 with timeout 30 seconds then exec "/sbin/ifup lan"

9 8 2 PRAKTISCHE REALISIERUNG 2.2 Erläuterungen Der kleine Daemon monit stellt auf beiden Seiten sicher, dass sowohl der IPSEC- als auch der L2TPv3-Tunnel steht. Andernfalls wird durch ein ifup lan die L2TP Verbindung neu initialisiert. Im Desaster RZ wurde davon ausgegangen das sich eth1 innerhalb des VLAN 111 befindet. Nun kann in diesem VLAN das interne Netz des primären RZ verwendet werden, ohne das lokale Layer 2 Geräusche stören. Wir haben also das interne Netz vom primären RZ in das VLAN 111 auf der Gegenseite gebridged. 2.3 Bridgen von Geräten mit unterschiedlicher MTU Bis hierher wird das Setup soweit funktionieren, dass sich beide Seiten anpingen können. Versucht man allerdings, eine ssh-verbindung aufzubauen, friert diese nach wenigen Sekunden ein oder kommt gar nicht erst zustande. Der Grund dafür ist, dass sich innerhalb der Bridge für das L2TPv3 Geräte mit unterschiedlicher MTU 3 befinden. Und da hier gebridged wird, findet auch kein Routing statt und die MTU kann nicht automatisch durch einen Router angepasst werden. Alle Geräte im lokalen Netzwerk verwenden in der Regel eine MTU von Die MTU des L2TPv3 Gerätes liegt bei etwa Da der Tunnel selbst nicht fragmentieren kann, gehen so alle Pakete verloren, die größer sind. Das passiert schon bei einem längern HTTP-Request. Bei der Lösung dieses Problemes kommt uns Bridge-Firewalling und TCP MSS Clamping zur Hilfe. Bridge Firewalling bedeutet, dass die iptables Regeln auch dann gerufen werden, wenn ein Paket eine Bridge passiert. Eigentlich dürfte das gar funktionieren, da eine Bridge genau genommen nur auf Layer 2 arbeitet. Jedoch macht es Linux möglich, denn hier kann eine Bridge, sofern Bridge Firwalling im Kernel verfügbar ist, sowohl auf Layer 2 als auch auf Layer 3 arbeiten. Dafür sind folgende sysctl Schlüssel zuständig: net.bridge.bridge-nf-call-iptables 0 - schicke keinen Ipv4-Verkehr durch iptables 1 - schicke Ipv4-Verkehr durch iptables net.bridge.bridge-nf-filter-vlan-tagged 0 - schicke vlan getaggten Ipv4-Verkehr durch iptables 1 - schicke vlan getaggten Ipv4-Verkehr durch iptables Für Ipv6 existiert ein eigener Schlüssel, der hier nicht aufgeführt wurde. Für unser Setup sollten diesen Regel wenigstens so aussehen: iptables -I FORWARD -s /24 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400 iptables -I FORWARD -d /24 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400 iptables -I FORWARD -s /24 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 3 MTU - Maximum Transfer Unit

10 9 4 GRIECHISCH iptables -I FORWARD -d /24 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu Diese Regeln sollten, soweit es möglich ist, eingeschränkt werden, um unangenehme Seiteneffekte zu vermeiden. 3 Ergo OpenSource ist kostenlos, aber nicht umsonst. Bezahlt wird nach Meinung des Autors mit viel Zeit und Nerven. Dieses sollte dann in der Regel durch einen Kunden entlohnt werden, der auf ein weitreichendes Know-How in diesem Bereich zurückgreifen kann und sich nicht mit Netzwerkern und oder Administratoren herumschlagen muss, die nur ein kommerzielles Produkt mit Lizenzen verkaufen wollen. Was er kauft, ist Wissen und Zeit. Vielen Dank an die großartigen Entwickler aus dem OpenWrt-Team. Besonders erwähnen möchte ich an dieser Stelle Jo-Philipp Wich, der trotz meiner ständigen Penetranz immer mit neuen Ideen und jeder Menge Programmierunterstützung zur Stelle war und ist. 4 griechisch Das ist Teκαιναν Das ist Te