Networking, směrování a firewalling

V rámci našeho projektu potřebujeme vytvářet virtuální sítě a máme následující požadavky:

Nejsme nějak zásadně omezeni na počet sítí, které takto vytvoříme
Není potřeba žádná dohoda s vlastníky jiných projektů – můžeme mít jakékoli IP rozsahy, neřešíme čísla VLAN ani nic podobného
Není potřeba žádná interakce s fyzickou sítí, tedy všechny popsané kroky musí být možné realizovat zcela bez zásahu do nastavení fyzické sítě (tedy bez zavolání síťaře)
Chceme mít možnost směrovat mezi těmto sítěmi, tedy mít router
Chceme pro svůj projekt dostat seznam IP adres, které mají obecnou platnost ve firmě nebo na Internetu (tedy chceme spojení s reálným světem)
Můžeme chtít používat firewallová pravidla na úrovni jednotlivých VM, ale i subnetů a routerů
Můžeme potřebovat řešit VPN připojení poboček do aplikací běžících v OpenStack prostředí
Možná budeme potřebovat load balancer, který pod jednou virtuální IP bude rozhazovat zátěž na jednotlivé virtuální servery

To vše je součástí HPE Helion OpenStack. Vyzkoušejme si to.

Per-VM stavový firewall

Nejprve si připravme mikrosegmentační pravidla (Security Groups). Jde o stavový firewall, který je implementovaný přímo v compute node (tedy v serveru, který je hostitelem vaší VM) a aplikuje se hned, jak provoz z VM pokračuje dál. Jděte do Compute, Access & Security, kde uvidíte výchozí SG default..

Vytvořme si teď nové pravidlo. Klikněte na tlačítko CREATE SECURITY GROUP zadejte název a klikněte na tlačítko vytvořit.

Podívejme se teď na bezpečnostní pravidla v této skupině - klikněte na tři tečky a následně na Manage Rules.

Všimněte si, že výchozí sada pravidel (kterou ovšem můžeme odstranit, pokud chceme) dovoluje komunikaci směrem ven, ale nepovoluje nic směrem dovnitř. Vzhledem ke stavovosti to znamená například možnost stahovat věci z Internetu (pozor - síť zatím máme izolovanou, nenapojili jsme ji na router, takže zatím se na Internet nedostaneme, což ale brzy změníme).

Nechme to prozatím takhle, tedy nepovolíme žádnou komunikaci dovnitř. Pojďme tuto Security Group přiřadit místo té výchozí našim dvěma VM, které už máme spuštěné. Jděte do sekce Compute, Instances a u VM klikněte na Edit Security Groups.

Použijte tlačítko minus na odstranění výchozího pravidla a tlačítko + na přidání našeho nového. Nakonec klikněte na ADD.

Totéž zopakujte pro druhou VM.

Nasadili jsme teď velmi omezují pravidlo - ven povolujeme cokoli, ale dovnitř vůbec nic. Pojďme zkusit ping z jedné VM do druhé - neprojde (což očekáváme).

Nastartujte konzoli jedné z VM.

Ping, dle očekávání, neprochází (doporučuji si nechat konzoli zvětšenou do jiného okna, bude se nám ještě hodit).

Řekněme, že toto pravidlo máme pro aplikační vrstvu. K té nechceme přístup pro uživatele (ti přistupují k aplikaci přes web server, ne přímo do aplikační logiky), ale protože běží v clusteru, určitě chceme, aby mezi sebou aplikační nody mohly komunikovat. Zavedeme tedy pravidlo, že komunikace přicházející od dalších členů této bezpečnostní skupiny budiž povolena. Jděte znovu do nastavení bezpečnostních pravidel.

Modifikujte pravidla naší Security Group

Klikněte na tlačítko ADD RULE a vytvoříme nové pravidlo.

Vyplníme ho takto. Můžeme se omezit pouze na konkrétní TCP/UDP port, ale pro členy skupiny nechť mohou komunikovat jakkoli, takže využijeme Other protocol a nebudeme jej nijak omezovat. Odkud takovou komunikaci povolíme? Ne odkudkoli ani ne z nějakého subnetu, ale ze členů této skupiny. To znamená, že jakmile do této skupiny přidáme další VM, automaticky bude moci mluvit k ostatním.

Otevřete konzoli (pokud jste si ji už dříve nechali v jiném okně, překlikněte tam) a zkuste ping znovu. Tentokrát prošel, obě VM totiž máme ve stejné Security Group.

V tom je to kouzlo - když přidáte další VM tuto Security Group, aplikují se na ni tato pravidla - nemusíte nikde řešit jakou dostala IP adresu.

K VM můžete přiřazovat větší množství Security Group a ty se vám „sečtou“ (chovají se tedy jinak, než například ACL v prvcích). Ještě se k nim vrátíme a ukážeme si její další možnosti, předtím ale potřebujeme vytvořit ještě další síť a směrování mezi nimi.

Sítě a směrování

Na chviličku teď opustíme Security Group a vrhneme se do směrování sítí. Máme aplikační servery, ale nemáme je připojeny nikam dál. Chybí nám síť pro web servery odkud bychom mohli sahat do aplikačních serverů a současně odtud poskytovat službu uživatelům. Pojďme to napravit. Následující operace můžete provádět buď v záložkách Networks a Routers nebo přímo z grafické reprezentace topologie. Pro začítek zvolíme to druhé.

Jděte do záložky Network, Network Topology.

Najdeme tam síť, kterou jsme společně vytvořili na začátku labu.

Přidáme si teď novou síť pro náš webový frontend. Klikněte nad obrázkem na tlačítko CREATE NETWORK.

Zadejte název a pokračujte dál.

Přidejte subnet

Přidejte DNS server a dokončete založení sítě

Sítě tam máme, ale nejsou nijak propojené.

Je čas přidat router, takže klikněte na tlačítko CREATE ROUTER

Dejte mu nějaké jméno a co určitě uděláme je, že ho připojíme do nějaké externí sítě (v našem labu je jen jedna, ale v principu jich administrátor může připravit víc). Jde o reálné sítě ve vašem datovém centru - sítě s přístupem k uživatelům, k Internetu, s veřejnými i privátními adresami apod. Pokud je například v externí sítí dostupný Internet, námi vytvořená Security Group (jak si jistě vzpomínáte) neomezuje komunikaci směrem ven. Router tak bude provádět Source NAT a můžete tak z VM přistupovat do Internetu a stahovat si třeba balíčky.

Router máme, dokonce je připojený do externí sítě, ale naše sítě do něj nevedou. To změníme. Klikněte na jeho ikonu a dejte ADD INTERFACE.

Přidejte „port“ vedoucí do jedné z našich sítí.

Zopakujte to ještě jednou a přidejte do routeru i naši druhou síť. Výsledný stav bude vypadat nějak takhle:

Vyzkoušejme, že se teď z našich VM dostaneme do externího světa. V našem tato externí síť nemá neomezený internet, takže použijte ping na adresu 16.21.188.1:

Přidejme VM do sítě a použijme mikrosegmentaci

V předchozích částech jsme si vytvořili Security Group pro dvě naše aplikační VM, které tak mohou mluvit mezi sebou. Také jsme založili novou síť pro naší webovou farmu a tuto se sítí pro aplikace připojili na router. Pojďme tento scénář dokončit a začneme Security Group.

Jděte do menu do části bezpečnosti.

Přidejme novou bezpečnostní skupinu.

První, kterou uděláme pojmenujme jak WebServery.

U této Security Group nebudeme přidávat nic dalšího - výchozí nastavení, které dovnitř nepovoluje nic, nám teď stačí (budeme si totiž chtít vyzkoušit přiřazování vícero skupin). Proč jsme to tedy udělali? Tyto web servery potřebují přistupovat k aplikačním serverům. Ve skupině MojeAplikace tedy povolme přístup skupině WebServery. Klikněte na tři tečky u MojeAplikace a dejte Manage Rules.

Povolme přístup na aplikační servery naší nové skupině WebServery. Klikněte na přidat pravidlo.

a vyplňte ho takhle:

Výsledek bude vypadat nějak takto:

Možná vás napadá, že jsme sice povolili komunikace web serverů s aplikačními, ale uživatelé budou potřebovat přístup na web na portu 80 a 443. Máte pravdu. Proč jsme to nezapsali rovnou do Security Group WebServery? Rád bych na tohle vytvořil skupinu jinou. Jednak si vyzkoušení přiřazení vícero skupin k jedné VM, ale má to i praktické důvody. Například můžu aplikace dvě a k nim příslušné webové a aplikační servery. Web1 má vidět jen na App1, ale ne na App2. Toho dosáhneme čtveřicí Security Group. Nicméně v obou těch webových se bude opakovat povolený port 80 a 443. Možná bude z hlediska správy lepší takové pravidlo držet v jiné skupině, kterou web serverům přiřadíme služby/porty.

Založme si tedy Security Group WebFrontend, která povolí přístup na portech 80 a 443. To už zvládnete určitě bez problémů sami, takže si ukažme jen výsledek:

Vytvořme si teď dvě nové VM představující databázové servery. Jděte do Project, Compute, Instances.

Spustíme si nové instance

VM si pojmenujeme mujWEB a budeme chtít dvě.

Pozor, teď nepoužijeme Cirros, ale pro účely labu máme vytvořený hotový snapshot web server, který teď použijeme.

Jako flavor tentokrát použieme web.tiny

Přiřaďte naši novou síť, ale instance ještě nespouštějte.

Tentokrát už máme připravenou i Security Group, tak ji rovnou nastavíme.

Teď už můžeme VM spustit. V seznamu instancí pak klikněte na jednu z nich:

Dole v detailech si můžete prohlédnout mikrosegmentační pravidla:

Skočte do konzole našeho aplikačního serveru (to jsou ty původní VM) a zkuste pingnout ty nové. Neprojde - tak jsou totiž nastavena naše stavová pravidla - web server může začínat komunikaci k aplikaci (ptát se jí na věci), ale opačně ne.

Zkuste to obráceně - pingněte z webového server do aplikačního. Jako login do webserveru použijte web/web.

Tímto jsme si ověřili stavovost bezpečnostních skupin a take jsme routovali z jedné sítě do druhé. Když jsme v server můžeme si ověřit, že web běží. Použijeme “textový prohlížeč” curl a zamíříme ho na loopback adresu (tedy sám na sebe).

Už to vypadá docela kompletně, ale stale jsme ve virtuálních sítích uvnitř cloudu, které nejsou viditelné uživatelům. Potřebovali bychom web server zpřístupnit uživatelům mimo náš privátní cloud. A to uděláme hned v další části.

Přístup ke službám v cloudu z venku (Floating IP)

V předchozí části labu jsme našemu routeru přiřadili jednu z externích sítí, kterými jsou existující sítě v infrastruktuře, DMZ nebo Internet apod. Vyzkoušeli jsme si, že je možné se z našich VM dostat ven díky SNAT překladu adres na routeru). To nám může stačit pro stahování balíčků, ale pro frontend web servery to bude málo. Pokud je to možné, budeme chtít držet backend komunikaci uvnitř tenantu (databáze, aplikační server apod.), nicméně například k web serveru potřebujeme dát přímo přístup našim uživatelům (externím sítím).

Helion OpenStack toto řeší překladem 1:1, tedy Floating IP. V rámci tenantu/projektu si zažádáte o přidělení reálné IP adresy z vybrané externí sítě a tuto svážete s nějakou z vašich VM. Jinak řečeno vaše instance vnitřně nemá tuto IP adresu nastavenou na své síťové kartě. Tam zůstává interní adresa virtuální sítě, ale při komunikaci ven dojde k jejímu přeložení na externí (a při cestě od uživatelů naopak). Toto se odehrává distribuovaným způsobem (Distributed Virtual Router), takže přímo na compute node, kde je VM hostovaná (provoz nemusí jít do centrálního routeru, přímo z compute node je přeadresován a odchází do externí sítě – podle toho jak to administrátor cloudu udělal třeba nějakou specifickou VLAN nebo dedikovanou síťovou kartou). Protože adresa není nastavena přímo uvnitř VM je označována za plovoucí (Floating) – můžete ji přidělit jedné z VM, ale pak změnit názor a této ji odejmou a dát jiné (můžete tak například bokem instalovat novou verzi aplikace, zkoušet si ji a až budete spokojeni, rychle a snadno přehodit IP adresy).

Jděte do seznamu instancí, vezměte si mujWEB-2 (záměrně nejdřív dvojku) a v menu najděte Associate Floating IP.

Teď si vybereme skutečnou externí IP adresu. V našem projektu v tuto chvíli žádnou vyžádanou nemáme, takže klikněte na tlačítko +

Tady si žádáme o přiřazení IP adresy z externího rozsahu (tedy reálné IP, kterou uvidí uživatelé), v našem případě ze sítě ext-net.

Dokončete asociaci této adresy.

Vyzkoušejme si to. Protože tato venkovní síť je zamčená uvnitř našeho lab prostředí, nejprve se připojte na labServer. Jeho IP adresu a port najdete na zde: http://cloudsvet.cz/helion/015/. Použijte Putty nebo jiného svého oblíbeného SSH klienta.

Přihlašovací jméno a heslo je stejné jako do konzole Helion OpenStack.

Jakmile budete uvnitř, zkouste pingnout vaší plovoucí IP. Nemělo by se to pořadit, protože ICMP (ping) jsme v naší Security Group nepovolili.

    tomas@labserver:~$ ping 10.201.0.12

    PING 10.201.0.12 (10.201.0.12) 56(84) bytes of data.

    ^C

    --- 10.201.0.12 ping statistics ---

    7 packets transmitted, 0 received, 100% packet loss, time 5999ms

Použijte curl (textový prohlížeč) a uvidíte, že web server nám něco vrací.

    tomas@labserver:~$ curl 10.201.0.12

    Odpoved ze serveru: 192.168.2.7/24

Představme si teď, že na druhém web serveru jsme třeba nainstalovali novější verze webového GUI a chtěli bychom tuto uživatelskou IP přesunout. Jděte do Compute, Instances a klikněte na Disassociate IP.

Uvolněnou IP přiřaďte mujWEB-1

Vyzkoušjte teď z labServer znovu curl prohlížeč. Na stejné IP adrese teď dostanete odpověď z našeho druhého serveru.

    tomas@labserver:~$ curl 10.201.0.12

    Odpoved ze serveru: 192.168.2.6/24

Tím jsme si vyzkoušeli sílu plovoucích externích adres.

Provider sítě

Pro naprostou většinu situací doporučuji používat virtuální networking tak, jak jsme to dělali v tomto labu. Tedy vytvořit virtuální sítě, virtuální routery a ven se dostávat přes SNAT pro back-end a Floating IP pro servery, ke kterým mají přistupovat uživatelé. Směrování ven (včetně překladu na Floating IP) provádíte na externí sítě, kterých můžete míc víc (například jedna externí síť může být Intranet, druhá DMZ). Tímto způsobem získáte maximální flexibilitu a výhody IaaS.

Mohou ale být situace, zejména při pozvolné migraci z pouhé virtualizace k IaaS, kdy chcete VM rovnou přímo napojit do externí sítě, tedy do nějaké reálné VLAN ve vašem datovém centru. Podobně jako u běžné virtualizace tedy řeknete – provoz této VM v okamžiku, kdy opouští compute node, má mít VLAN tag 1001 (a předpokládáte, že váš síťař takovou VLAN skutečně má). Bez multitenance, bez virtualizace, bez flexibility volby IP rozsahů apod.

Tato možnost není přístupná přímo z GUI, resp. nejprve administrátor musí provést deployment této VLAN na compute nody (na to má Helion Lifecycle Manager) a zavést tuto Provider VLAN v administrátorské části OpenStack. Pak mohou uživatelé (nebo konkrétní projekt) tuto přímou VLAN využívat.

V našem labu to zkoušet nebudeme a v praxi doporučuji používat spíše vyjímečně. Nicméně je to relevantní možnost a z pohledu uživatele jednoduchá a snadno pochopitelná.

Tím jsme si prošli ovládání sítí a v další části se zaměříme na vyšší síťové služby. Konkrétně load-balancing pro rozdělování provozu na vaše VM (LBaaS), automatizaci firewallu perimetru vašeho cloudu (FWaaS), IPSec VPN spojení (VPNaaS) a samoobslužné nastavování DNS záznamů (DNSaaS)