In der Open Telekom Cloud können Kunden den vNICs (Ports) ihrer virtuellen Maschinen (VMs) elastische bzw. sogenannte Floating IPs zuordnen, um ein- und ausgehende Internetverbindungen aufzubauen.

Viele VMs werden nur zu internen Zwecken verwendet und müssen daher nicht notwendigerweise über das Internet erreichbar sein. In manchen Fällen kann es jedoch sein, dass die von der Open Telekom Cloud bereitgestellten Public Services (wie DNS, NTP oder Update Repository Mirrors) nicht ausreichend sind und Informationen bzw. Software aus dem Internet abgerufen werden müssen.

Wenn jeder dieser VMs eine öffentliche IP-Adresse zugeordnet werden muss, werden dabei unter Umständen viele IPv4-Adressen verschwendet, die allerdings nur in begrenzter Anzahl zur Verfügung stehen. Darüber hinaus entstehen hierbei zusätzliche Kosten und die Angriffsfläche des Netzwerks wird möglicherweise vergrößert. Stattdessen ist die Verwendung einer einzigen öffentlichen IP-Adresse vorzuziehen, die von vielen VMs gemeinsam genutzt wird. Dies kann mithilfe von Source-NAT (SNAT) eingerichtet werden.

Die Open Telekom Cloud unterstützt seit Anfang Juni 2017 einen SNAT-Plattformservice. Hierbei handelt es sich um die empfohlene und zudem einfachste Variante für alle Fälle, in denen nur ausgehender Internetverkehr erforderlich ist. Im ersten Teil dieses Dokuments finden Sie hierzu genauere Informationen.

Seit Februar 2017 unterstützt die Open Telekom Cloud auch das Modell einer Routing-/SNAT-Instanz. Dabei wird eine VM mit einer öffentlichen IP-Adresse konfiguriert, die dann für eine Reihe von VMs im selben Subnetz bzw. derselben VPC als SNAT-Router/Gateway fungiert. Die Einrichtung ist zum einen mit viel Aufwand verbunden und es sind zudem spezielle Fachkenntnisse erforderlich. Darüber hinaus spielen Sicherheitsaspekte hierbei ebenfalls eine wichtige Rolle. Eine detaillierte Beschreibung sowie umfangreiche Informationen zu Sicherheitsfragen finden Sie im zweiten Teil dieses Artikels. Dort erfahren Sie außerdem, wie eine solche SNAT-Instanz eingerichtet und abgesichert wird und welche Einstellungen vorgenommen werden müssen, um den ausgehenden Internetverkehr von anderen VMs aus zu ermöglichen.

Seit Anfang Juni 2017 bietet die Open Telekom Cloud eine optional buchbare Plattformfunktion zur SNAT-Unterstützung.

Auch wenn die Einrichtung von SNAT-Instanzen (siehe zweiter Teil weiter unten) weitaus mehr Flexibilität bietet (z. B. durch Konfiguration von Port-Weiterleitung, Reverse Proxys, WAFs, Load Balancers, JumpHosts etc.), wird es mit der SNAT-Plattformfunktion nun sehr viel einfacher, VMs ohne EIP für ausgehenden Internetverkehr zu konfigurieren.

Zur Verwendung der SNAT-Plattformfunktion muss der Eintrag „--enable_snat“ in der „external_gateway_info“ Ihres VPC-Routers lediglich auf „true“ gesetzt werden.

Dies kann mit dem folgenden Befehl konfiguriert werden:

neutron router-gateway-set --enable-snat VPC-ROUTER-ID admin_external_net 

Die Deaktivierung erfolgt analog mit „--disable-snat“.

Dabei ist zu beachten, dass in der empfohlenen Version des Tools „neutron“ (OpenStack-Release Newton 6.0.0) ein Backport für die SNAT-Aktivierung erforderlich ist (die Deaktivierung funktioniert allerdings auch ohne Backport). Mit diesem Patch ist das Tool „neutronclient“ in den öffentlichen Images für openSuSE42 und SLES12 bereits enthalten. Falls dies bei Ihnen nicht der Fall ist, können Sie entweder eine neuere Version der Tools „python-neutronclient“ verwenden oder auf otc-tools zurückgreifen, die die Aktivierung bzw. Deaktivierung von SNAT ebenfalls unterstützen.

Im Folgenden finden Sie den fünfzeiligen Backport für „neutron“, falls Sie den Patch von „neutronclient“ selbst durchführen möchten.

# python-neutronclient assumes that snat is enabled by default, so it
# only supports disabling, but not enabling it explicitly.
# This has been fixed in latest upstream versions.
# This is my minimal version of this feature. -KG
Index: neutronclient/neutron/v2_0/router.py
===================================================================
--- neutronclient/neutron/v2_0/router.py.orig
+++ neutronclient/neutron/v2_0/router.py
@@ -235,6 +235,9 @@ class SetGatewayRouter(neutronV20.Neutro
            'external_network', metavar='EXTERNAL-NETWORK',
            help=_('ID or name of the external network for the gateway.'))
        parser.add_argument(
+ '--enable-snat', action='store_true',
+ help=_('Enable source NAT on the router gateway.'))
+ parser.add_argument(
            '--disable-snat', action='store_true',
            help=_('Disable source NAT on the router gateway.'))
        parser.add_argument(
@@ -258,6 +261,8 @@ class SetGatewayRouter(neutronV20.Neutro
        router_dict = {'network_id': _ext_net_id}
        if parsed_args.disable_snat:
            router_dict['enable_snat'] = False
+ if parsed_args.enable_snat:
+ router_dict['enable_snat'] = True
        if parsed_args.fixed_ip:
            ips = []
            for ip_spec in parsed_args.fixed_ip:

Die SNAT-Plattformfunktion kann allerdings noch nicht über die Open Telekom Cloud Weboberfläche aktiviert werden. Dies muss über API erfolgen. Die API für diese Einstellung ist identisch zu der in anderen OpenStack-Clouds. In vielen Clouds ist SNAT allerdings standardmäßig aktiviert, sodass bei Konfiguration eines externen Gateway-Netzes im Router der Internetzugang sofort hergestellt wird. Bei der Open Telekom Cloud hingegen ist der externe Router zwar immer konfiguriert (damit Floating IPs ohne Weiteres funktionieren), allerdings ist die SNAT-Funktion standardmäßig deaktiviert.

Wenn Sie lediglich SNAT benötigen, wird die Nutzung der oben beschriebenen SNAT-Plattformfunktion empfohlen. Eine SNAT-Instanz hingegen bietet die Möglichkeit, erweiterte Routing-Funktionen und -Richtlinien zu implementieren, wie z. B. die Einrichtung von openVPN-Tunneln und das standardmäßige Routing von Paketen über openVPN. Im folgenden Abschnitt finden Sie Informationen zu den Grundfunktionen, die bei der Ersteinrichtung von SNAT erforderlich sind. Bitte beachten Sie, dass die SNAT-Plattformfunktion zum Zeitpunkt der Entstehung dieses Artikels noch nicht verfügbar war. Die hier enthaltenen Informationen stellen jedoch weiterhin eine nützliche Orientierungshilfe für die erweiterte Einrichtung dar. Hierbei sind auch die Sicherheitsaspekte zu berücksichtigen, die mit der Weiterleitung aller Adressen über bestimmte Ports (Einstellung „allowed-address-pairs“) einhergehen. In diesem Fall wird die Sicherheitsgruppe der betreffenden Ports den gesamten eingehenden Datenverkehr durchlassen.

Viele Betriebssysteme unterstützen Routing-Pakete. Vor der Weiterleitung überschreibt das Betriebssystem die Quelladressen der Pakete jedoch mit seiner eigenen Adresse, damit die Pakete mit einer öffentlichen Absenderadresse versendet und die Antwort-Datenpakete korrekt zugeordnet werden können. Diese Methode nennt sich Source Network Address Translation (kurz: SNAT; dt. Quellen-Netzwerkadressübersetzung). Das Betriebssystem muss den Überblick über die Pakete mit veränderten Adressen behalten, damit beim Eingang der Antwort-Pakete die Zieladresse wieder eingefügt (DNAT, Destination Network Address Translation, dt. Ziel-Netzwerkadressübersetzung) und das Paket an den ursprünglichen Absender gesendet werden kann. Im Folgenden werden wir kurz ansprechen, wie dies unter Linux erreicht werden kann.

Prinzipiell muss lediglich die IP-Weiterleitung per „sysctl -w net.ipv4.ip_forward=1“ aktiviert und die SNAT-Regel „iptables -t nat -A POSTROUTING -j SNAT -o eth0 -s NET/PREFLEN --to OWNIP“ eingerichtet werden. Die genaue Vorgehensweise wird ausführlich in Kapitel 3.10 des VPC-Benutzerhandbuchs der Open Telekom Cloud beschrieben.

Die OpenStack-Netzwerkkomponente „neutron“ lässt standardmäßig keine VM-Pakete durch, wenn die Senderadresse von der eigenen IP-Adresse abweicht. Diese Einstellung bietet Schutz vor gefälschten Paketen und trägt zu einer höheren Netzwerksicherheit bei. In unserem SNAT-Szenario würde „neutron“ jedoch alle Pakete ablehnen, die von der SNAT-Instanz zur ursprünglichen VM zurückgesendet werden, da die Absenderadresse in diesem Fall von der eigenen IP-Adresse abweicht.

Dieser Sicherheitsmechanismus in „neutron“ kann jedoch deaktiviert werden. In der Weboberfläche („Service Console“) ist dies im Tab „NIC“ über die Option „Unbind IP from MAC“ möglich.

In der Befehlszeile muss die Netzwerkschnittstelle (Port) der SNAT-Instanz und folgender Befehl angegeben werden:

neutron port-update PORTID --allowed-address-pairs type=dict list=true ip_address=0.0.0.0/1 ip_address=128.0.0.0/1

Mit dieser Einstellung lässt „neutron“ Pakete von beliebigen Absenderadressen über den angegebenen Port durch.1

Die SNAT-Instanz hat eine externe IP-Adresse und ist somit vom Internet aus zugänglich. Daher muss die Instanz ausreichend abgesichert werden, beispielsweise durch entsprechende Netzwerkmechanismen (Firewall-Regeln bzw. Schließung offener Ports), Deaktivierung der SSH-Authentifizierung (bei allen öffentlichen Images in der Open Telekom Cloud standardmäßig deaktiviert) und die zeitnahe Installation von verfügbaren Sicherheitsupdates.

Aus diesem Grund sollten Sie sicherstellen, dass die SNAT-Instanz ausreichend geschützt ist. Da für die interne Verbindung zum Subnetz und zum Internet dieselbe Schnittstelle verwendet wird, können die Filterregeln nicht auf Grundlage des Namens der Netzwerkschnittstelle definiert werden. Dadurch gestaltet sich der Netzwerkschutz etwas komplizierter.

Wenn die Verfügbarkeit Ihrer Anwendung von einem ausgehenden Internetzugriff abhängt, sollte sichergestellt sein, dass die Anwendung auch bei einem Ausfall der SNAT-Instanz weiterhin funktioniert. Wenn das System so konfiguriert ist, dass es auch bei einem Ausfall einer kompletten Availability Zone (AZ) weiterhin problemlos funktioniert, ist automatisch eine hohe Verfügbarkeit Ihrer Cloud-Umgebung sichergestellt.

In diesem Abschnitt wird beschrieben, wie sich mithilfe einer virtuellen IP-Adresse und zwei VMs ein hochverfügbares SNAT-Setup erreichen lässt.

Es wird ein Netzwerk und Subnetz für beide AZs erstellt und in jeder AZ jeweils eine SNAT-Instanz angelegt. In der Weboberfläche können Sie die virtuellen IP-Adressen im Menü VPC/Subnet über „Manage Private IP Address“ zuordnen.

Normalerweise müssten Sie diese Adresse an den Ports der SNAT-Instanz zulassen (BIND Private IP). Da wir jedoch schon vorher alle Adressen für die SNAT-Funktion zugelassen haben, ist hier nichts weiter zu tun.

Die SNAT-Instanzen müssen lediglich so konfiguriert werden, dass sie die virtuelle IP-Adresse verwenden. Hierzu müssen Sie sich in den VMs einloggen und den Befehl „ip addr add VIP/32 dev eth0“ eingeben.

Dieser Vorgang lässt sich auch vollständig automatisieren. Bei der benutzerdefinierten cloud-init-Funktion „user_data“ gibt es hierfür die Einstellung „otc.addip“.

# Assumptions: VPC-ROUTER exists, $SNATSG contains security-group ID
getid() { FIELD=${1:-id}; grep "^| $FIELD " | sed -e 's/^|[^|]*| \([^|]*\) |.*$/\1/' -e 's/ *$//'; }
listid() { grep $1 | tail -n1 | sed 's/^| \([0-9a-f-]*\) .*$/\1/'; }
SNATNET=$(neutron net-create SNAT-NET | getid)
SNATSUB=$(neutron subnet-create --dns-nameserver 100.125.4.25 --dns-nameserver 8.8.8.8 --name SNAT-SUBNET SNAT-NET 172.16.0.0/24 | getid)
neutron router-interface-add VPC-ROUTER $SNATSUB
neutron port-create --name SNAT-VIP --security-group SNAT-SG-DANGERZONE --fixed-ip subnet_id=$SNATSUB,ip_address=172.16.0.99
cat > user_data.yaml <<EOT
#cloud-config
otc:
   internalnet:
      - 172.16/12
   snat:
      masq:
         - INTERNALNET
   addip:
      eth0: 172.16.0.99
   autoupdate:
      frequency: daily
      categories: security recommended
EOT
IMGID=$(glance image-list | listid 'Standard_openSUSE_42_JeOS_latest')
nova boot --image $IMGID --flavor computev1-1 --key-name SSHkey-SNAT --user-data user_data.yaml --availability-zone eu-de-01 --security-groups $SNATSG --nic net-id=$SNATNET,v4-fixed-ip=172.16.0.4 SNAT-INST1
nova boot --image $IMGID --flavor computev1-1 --key-name SSHkey-SNAT --user-data user_data.yaml --availability-zone eu-de-02 --security-groups $SNATSG --nic net-id=$SNATNET,v4-fixed-ip=172.16.0.5 SNAT-INST2
SNAT_INST1_PORT=$(neutron port-list | grep 172.16.0.4 | listid $SNATSUB)
neutron port-update $SNAT_INST1_PORT --allowed-address-pairs type=dict list=true ip_address=0.0.0.0/1 ip_address=128.0.0.0/1
neutron floatingip-create --port-id $SNAT_INST1_PORT admin_external_net
SNAT_INST2_PORT=$(neutron port-list | grep 172.16.0.5 | listid $SNATSUB)
neutron port-update $SNAT_INST2_PORT --allowed-address-pairs type=dict list=true ip_address=0.0.0.0/1 ip_address=128.0.0.0/1
neutron floatingip-create --port-id $SNAT_INST2_PORT admin_external_net
neutron router-update VPC-ROUTER --routes type=dict list=true destination=0.0.0.0/0,nexthop=172.16.0.99

Im voranstehenden Code wird davon ausgegangen, dass Ihr VPC-Router den Namen VPC-ROUTER hat und eine Sicherheitsgruppe namens SNAT-SG-DANGERZONE mit entsprechenden Regeln für die SNAT-VMs sowie ein SSH-Schlüsselpaar namens SSHkey-SNAT konfiguriert sind. Der ausgehende Datenverkehr aus dem Bereich 172.16/12 wird hierbei maskiert. Dies setzt voraus, dass alle anderen Subnetze des VPC-Routers, in denen SNAT erforderlich ist, Adressen aus diesem Adressbereich nutzen. Der Einfachheit halber werden nur feste IP-Adressen verwendet. Die Netzwerkressourcen wurden nach Namen (anstelle der Quell-UUIDs) referenziert und es kommen zwei kleine Hilfsfunktionen zum Einsatz. Eine Fehlerbehandlung findet nicht statt. Mit Ausnahme dieser Details handelt es sich hierbei um die empfohlene Konfiguration.
 

Zu beachten ist auch die Benennung SNAT-SG-DANGERZONE. Diese Sicherheitsgruppe umfasst Ports mit der Einstellung „--allowed-address-pairs“. Pakete von dieser Sicherheitsgruppe sollten also an keiner Stelle zugelassen werden, wenn Sie nicht der ganzen Welt Tür und Tor öffnen möchten.

Einen vollständigen Beispielcode finden Sie in config_snat.sh.

Die Einstellung „otc.addip“ bewirkt nicht einfach ein „ip addr add $VIP/32 dev $DEV“ auf beiden Instanzen. Auch wenn dies zu funktionieren scheint, ist hierbei alles davon abhängig, dass der ARP-Cache des Routers für ein stabiles Routing sorgt und nicht unnötigerweise zwischen den beiden Instanzen hin- und herwechselt. Obwohl die Funktionsfähigkeit in unseren Tests zwar nachgewiesen werden konnte, heißt dies noch lange nicht, dass diese Einstellung auch in Zukunft für einen problemlosen Betrieb sorgt. Die Einstellung „otc.addip“ startet also einen Service (snat_addip.sh), der die Internetkonnektivität sowie die Verfügbarkeit der virtuellen IP-Adresse überwacht und sicherstellt, dass die virtuelle IP-Adresse nur von einer Instanz verwendet wird. Verliert eine Instanz die Konnektivität, kommt es zu einem Failover.

Routing über die SNAT-Instanz

Mit Open Telekom Cloud 2.0 wird eine VPC-Routingfunktion eingeführt, bei der ausgehender Datenverkehr über Ports ohne EIP über eine SNAT-Instanz geroutet werden können.

Die Einstellung erfolgt über die Weboberfläche, siehe Kapitel 3.9 des VPC-Benutzerhandbuchs der Open Telekom Cloud.

Der Befehl zur Implementierung via API ist im obenstehenden Beispielcode bereits enthalten:

neutron router-update VPC-ROUTER --routes type=dict list=true destination=0.0.0.0/0,nexthop=172.16.0.99 

Die Nutzung dieser VPC-Routingfunktion erfordert keinerlei Änderungen in der VM-Routingkonfiguration. VMs werden wie zuvor direkt mit Nachbarn (im selben Subnetz) kommunizieren und für alle weiteren Verbindungen den VPC-Router als Standard-Gateway nutzen. Der Router kennt weiterhin alle verbundenen Subnetze (über neutron „router-interface-add“ oder die Weboberfläche) sowie Peer-VPCs, VPN-Verbindungen und das Anbieternetzwerk (auf dem öffentliche Dienste wie DNS, NTP und Repository Mirrors gehostet werden). Die Pakete werden dementsprechend weitergeleitet. Außerdem wird der Router auch solche Pakete direkt an das Internet senden, die von Ports (vNICs) mit einer Floating IP (EIP) stammen. Das für 0.0.0.0/0 konfigurierte VPC-Routing hat die niedrigste Priorität und wird nur verwendet, wenn keine der obenstehenden Bedingungen erfüllt ist. Genau das ist das Ziel, das bei der Bereitstellung eines SNAT-Service verfolgt wird.

Aktuell ist es für Benutzer nicht möglich, die im VPC-Router verwendete Routing-Tabelle genauer anzupassen. Das Setup mit Standardrouting kommt jedoch in den meisten Anwendungsfällen zum Einsatz – ganz gleich, ob es sich um eine SNAT-Instanz zu Regelung des ausgehenden Datenverkehrs oder um einen openVPN-Endpunkt handelt, der Remote-Netzwerke miteinander verbindet.

Vor Einführung der Open Telekom Cloud 2.0 gab es keine Möglichkeit, um im VPC-Router das Routing über ein SNAT-Gateway zu konfigurieren. Um dennoch eine SNAT-Instanz zu verwenden, mussten daher die Routing-Tabellen von sämtlichen VMs angepasst werden, die keinen eigenen EIP haben und auf ausgehenden Datenverkehr angewiesen sind. Im folgenden Beispiel für eine Routing-Tabelle hat das SNAT-Gateway im /22-Netzwerk die IP-Adresse 192.168.16.4:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.16.4 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 192.168.16.1 255.0.0.0 UG 0 0 0 eth0
100.64.0.0 192.168.16.1 255.192.0.0 UG 0 0 0 eth0
172.16.0.0 192.168.16.1 255.240.0.0 UG 0 0 0 eth0
192.168.0.0 192.168.16.1 255.255.0.0 UG 0 0 0 eth0
169.254.169.254 192.168.16.1 255.255.255.255 UGH 0 0 0 eth0
192.168.16.0 * 255.255.252.0 U 0 0 0 eth0

Pakete an die lokalen Netzwerke werden alle an das Standard-Gateway gesendet, während die restlichen an das SNAT-Gateway gehen. Für Hosts in anderen Subnetzen müsste eine über den VPC-Router (.1) laufende Host-Route zum SNAT-Gateway konfiguriert werden, um die Standardrouten über die SNAT-Instanz hinzufügen zu können. Bei vielen Hosts gestaltet sich die Verwaltung solcher Routing-Tabellen relativ unpraktisch, sofern nicht ein paar DHCP-Tricks zum Einsatz kommen. In diesem Fall werden vor dem Start der VMs Ports (vNICs) erstellt und mithilfe von „extra_dhcp_options“ angepasst. Die Einrichtung eines eigenen DHCP-Servers ist zwar auch möglich, aber noch mühsamer, da Ihre IP-Adressen dann nicht mehr in OpenStack verwaltet werden. Dies ist insbesondere im Hinblick auf „allowed-address-pairs“ und Sicherheitsgruppen problematisch und auch die Ermittlung der IP-Adresse einer VM ist nicht mehr ganz so einfach.

Im vorkonfigurieren Setup haben wir für die SNAT-Instanz nur einen vNIC verwendet. In der Regel werden in Netzwerken allerdings zwei vNICs verwendet – eine für interne Verbindungen und eine mit EIP. Da die IP-Adressenbindung nur an der internen Netzwerkschnittstelle aufgehoben werden muss, bleibt die Sicherheitsgruppe auch weiterhin vor der Außenwelt geschützt. Darüber hinaus ist hierbei auch die Festlegung von richtigen Filterrichtlinien einfacher, da die meisten Firewall-Skripts für Linux-Distributionen von mehreren Schnittstellen für mehrere Zonen ausgehen. Andererseits müssten beide Subnetze der vNIC mit dem VPC-Router verbunden sein. Demnach ist keine vollständige Netzwerktrennung sichergestellt. Aus diesem Grund wurde das einfache Setup mit einem vNIC unter Verwendung der benutzerdefinierten Einstellungen „otc.snat user_data“ vorbereitet. Das Skript kann auch erweitert und getestet werden, um Setups mit mehreren vNICs zu unterstützen. Gegenwärtig ist dies allerdings nicht geplant. Falls Bedarf besteht, lassen Sie es uns wissen!

Da NTP, DNS und Package Mirrors über die Public Services der Open Telekom Cloud abgedeckt sind, ist der Bedarf für ausgehenden Internetzugang eventuell nicht allzu groß. Anstelle eines kompletten SNAT-Services bietet sich vielleicht auch die Einrichtung eines http-/https- bzw. Socks-Proxyservers an. Viele Anwendungen unterstützen die Variablen http_proxy und HTTPS_PROXY und funktionieren mit einem auf diese Weise konfigurierten Proxy. Bei ausreichendem Interesse können wie zur Bereitstellung eines solchen Services auch eine einfache Methode ausarbeiten, um Squid über ein paar Zeilen in user_data zu konfigurieren.

1 Die einfachere Einstellung „ip_address=0.0.0.0/0“ funktioniert in der Open Telekom Cloud nicht