Hlavní navigace

Připojení k Azure přes OpenVPN

Dan Ohnesorg

Pokud spojujete svou síť s cloudem, zpravidla to děláte přes IPsec. To je sice roky ověřené řešení, ale přesto nastávají situace, kdy úplně nevyhovuje. My jsme úspěšně použili OpenVPN.

Řešili jsme problém zákazníka, který trpěl nekvalitou spojení do Microsoft Azure. Přece jen je to spojení přes půl Evropy a několik poskytovatelů, stačí malý problém u jednoho z nich, nastane packet loss a následně rozpad IPsec tunelu. To je poměrně nepříjemná situace, protože znovu navázání trvá relativně dlouho a nemáte ani moc možností ovlivnit konfiguraci, protože ta na straně Azure je jedna a je pevně daná.

Navíc uživatelé pracují přes vzdálenou plochu a vidí tedy okamžitě každou nestabilitu konektivity.

Proto jsme se rozhodli zkusit OpenVPN, která má dvě přednosti, lépe se vyrovná se ztrátami paketů a umí přenášená data komprimovat, takže šetří pásmo a peníze za datové přenosy z cloudu. Současně oddaluje okamžik, kdy se linka provozem „ucpe“.

Instalace Linuxu do Azure je snadná operace a již se o tom na Rootu psalo, takže to nebudu rozepisovat. Zajímavá je jiná část konfigurace. Ta IPsec gateway má totiž v rámci Azure specifické postavení, provoz je přes ní směrován automaticky, pokud v konfiguraci vyjmenujeme, jaké síťové rozsahy lokální síť používá.

Při použití jiné VPN brány si musíme nastavit routing sami. To se nedá udělat přes GUI, ale naštěstí existuje velmi pěkná řádková utilita jménem Azure CLI. Její instalace je opravdu jednoduchá, pokud máme instalovaný node package manager, stačí zadat

npm install azure-cli -g

to -g znamená, že balíček bude dostupný globálně, ne jen pro jeden projekt. Potom se musíme přihlásit do Azure, opět jednoduchá operace

dan@dan:~> azure login
info:    Executing command login
info:    To sign in, use a web browser to open the page https://aka.ms/devicelogin. Enter the code XXXXXXX to authenticate.
info:    Added subscription AdminIT Production
+
info:    login command OK

Utilita vypíše URL, které navštívíte v prohlížeči a zadáte kód a tím získáte možnost pracovat s Azure. Pokud pro správu nepoužíváte dvoufaktorovou autentizaci, tak je možné zadat jméno a heslo přímo, tento režim se použije, pokud je na příkazové řádce uveden parametr -u následovaný uživatelským jménem.

Od této chvíle můžete z příkazové řádky udělat cokoliv, co ostatní konfigurují přes web, a spoustu dalších věcí.

Další krok je výběr režimu utility a tím současně verze Azure, kterou budete používat. Můžete zadat buď

azure config mode asm

nebo

azure config mode arm

Rozdíly mezi verzemi přesahují tento článek, berte to tak, že ASM je první verze cloudu a ARM je druhá vylepšená verze. Nové projekty tedy určitě chtějí ARM.

Azure má jednu specifickou vlastnost, síť propojující jednotlivé virtuální servery není L2 a je potřeba na to nezapomínat, když něco nefunguje. Náš virtuální stroj s OpenVPN nedostane pakety, které nejsou určeny přímo pro něj, tedy nemůže vidět náš plánovaný routovaný provoz. To mu musíme nejdříve dovolit. A to je věc, kterou lze snadno nastavit jen v novém režimu, tedy v ARM.

azure network nic set -g linuxOpenVPN -n NIC1 -f true

V ASM není tato volba k dispozici a budete muset požádat windows-kolegu, aby v rámci PowerShellu spustil

Get-AzureVM -ServiceName YOUR_CLOUD_SERVICE -Name linuxOpenVPN | Set-AzureIPForwarding -NetworkInterfaceName NIC1 -Enable

Zbytek návodu už platí pro obě verze stejně.

Konečně se dostávám k routovacím tabulkám. Tedy v terminologii Azure User Defined Routing. Routovací tabulky si vypíšeme přes

azure network route-table list

ale ve výchozím stavu je tento seznam prázdný. Musíme si tedy routovací tabulku vytvořit

azure network route-table create -n 'openvpn' -l 'West Europe'

Co jsem udělal je asi jasné, vytvořil jsem routovací tabulku jménem openvpn v lokalitě West Europe, tedy v Holandsku.

A rovnou si do ní přidám routu do naší sítě:

azure network route-table route set -r 'openvpn' -n 'openvpn1' -a 10.10.10.0/24 -t VirtualAppliance -p 192.168.1.1

Tady jsem do routovací tabulky openvpn přidal routu jménem openvpn1 a říkám, že cesta do sítě 10.10.10.0/24 povede přes virtuální server s IP adresou 192.168.1.1. Síť 10.10.10.0/24 se nachází ve firmě, tedy tzv. OnPremise a adresa 192.168.1.1 je virtuální server s instalovanou OpenVPN uvnitř Azure.

Tato routovací tabulka se ale ještě nepoužívá, nejříve ji musím připojit k subnetu uvnitř Azure.

azure network vnet subnet route-table add -t 'AdminIT Azure' -n 'FrontEnd' -r 'openvpn'

Tady jsem v síti jménem AdminIT Azure, která je rozdělena na více subnetů, přidal do subnetu jménem FrontEnd nově vytvořenou routovací tabulku. Od této chvíle, resp. v průběhu hodiny, než se konfigurace zreplikuje napříč cloudem, budou všechny do něj připojené stroje posílat pakety do sítě 10.10.10.0/24 přes ten linuxový router.

Rout do routovací tabulky mohu přidat libovolné množství, každá musí mít unikátní jméno, přes které ji potom např. mohu smazat.

Samozřejmě tento postup lze použít i pro mnoho dalších aplikací, např. pro instalaci IDS, IPS, použití vlastních loadbalancerů a podobně.

Na závěr graf odezev linky:

Vidíte tam dva zlomové momenty, první je výměna poskytovatele za takového, který garantuje větší šířku pásma do zahraničí a potom na začátku února nahrazení IPsec tunelu za OpenVPN.

Našli jste v článku chybu?
9. 9. 2016 8:39

Minimalne se pri nastaveni persist-tun chova tak, ze podrzi pakety nez se rozpadle spojeni zase navaze. IPsec v tom pripade generoval icmp destination unreachable, coz vedlo k resetu navazanych TCP spojeni. A pouzivame UDP rezim. Chteli jsme i delat offloading sifrovani a kompese na procesor, ale ty virtualy na strane azure to bohuzel neumi.

31. 8. 2016 14:48

Nevim, ale nekdy to zkusim. On ten PowerShell nestaci, jeste je potreba mit funkcni tvz. cmdlety, ktere teprve neco realne delaji. Obecne me PowerShell nezaujal, ale kdyz ohlasili ten azure shell, tak jsem si ho oblibil hned a od te doby do nej porad pridavaji a pridavaji nove veci. Ale celkem logicky spise do ARM verze.