Pokud potřebujete mít v Azure privátní prostředí bez veřejných IP adres, můžete se k němu připojit přes site-to-site VPN ve firmě, ExpressRoute ve spolupráci s operátorem a nebo vytočit VPN přímo ze svého počítače (point-to-site). Dnes se chci věnovat té poslední možnosti - jak si mohou například vývojáři vytočit VPNku do Azure. Podíváme se na dvě varianty. Tou první bude nativní Azure VPN, což má řadu výhod, zejména perfektní integraci do Windows, ale i své limity. Proto se podíváme také na možnost použít VPN třetí strany. Může to být Fortinet, Checkpoint, Cisco, Palo Alto a tak podobně, ale my si ukážeme open source variantu SoftEther.
Azure VPN vs. SoftEhter pro point-to-site připojení
Nejprve si připomeňme scénář. Privátní síť v Azure (VNET) můžete připojit do své sítě site-to-site VPN tunelem nebo přes ExpressRoute. Občas ale můžete potřebovat, aby přímo klientská stanice, například notebook vývojáře, byla schopna do Azure VNET přistupovat. To samozřejmě můžete udělat vytočením VPN do své sítě a odtamtud do Azure, ale co když se vám hodí spíš přímé připojení? To řeší point-to-site tunely. Ideální jsou takové, které běží na technologiích připomínajících přístupuna HTTPS stránku v Internetu. Tedy na portu 443 s využitím SSL/TLS - ty totiž bez problémů projdou různými domácími routery s NAT a filtrací portů s větší pravděpodobností, než klasický IPSec tunel.
Proč Azure VPN pro P2S tunely? Je to služba, která je přímo integrovaná v Azure a nemusíte se tedy starat o nějakou VM, řešit jestli má všechny patche a instalovat VPN software apod. Pro Windows stanice je velmi jednoduchá a používá SSL/TLS spojení s Microsoft SSTP protokolem. Další výhodou je, že pokud stejně potřebujete Azure VPN pro site-to-site tunel, stačí P2S pouze nakonfigurovat na této gateway - neplatíte nic dalšího navíc. Uživatele ověřujete klienstkým certifikátem a můžete přihlášení integrovat s AD domain services nebo RADIUS.
Jaké jsou limity Azure VPN? Nepodporuje Linux a kromě Windows umí už jen Mac, ale tam se musí využít IPSec protokolu (který špatně prochází některými firewally). Počet současně připojených uživatelů je omezen na maximálně 128.
Kdy použít SoftEther? Tato open source platforma nabízí (mimo jiné) otevřený OpenVPN protokol, který je postaven na SSL/TLS a je k dispozici pro Windows, Mac, Linux a dokonce existují i klienti pro mobilní operační systémy. Stejně jako Azure VPN můžete ověřovat klienty certifikátem, napojit se na AD či RADIUS. Limity na počet připojených uživatelů jsou podstatně vyšší. A nevýhody? Řešení si spravujete sami - poběží ve VM, o kterou se musíte starat a všechno je na vás.
Kdy použít komerční virtuální appliance? Pokud ve vašem prostředí máte strategii nasazovat konkrétního výrobce, například Fortinet, můžete v tom pokračovat i v cloudu. Appliance najdete hotové v portálu, v Azure zaplatíte za použité zdroje (VM) a výrobci appliance za licenci a podporu (ať už přímo metodou bring-your-own license neno u některých výrobců s využitím pay-as-you-go minutové sazby přes Azure).
Azure VPN
Pokud ještě nemáme, vytvoříme si pro svůj VNET Azure VPN. Ujistěme se, že VNET má dostatek adresního prostoru.
Vytvoříme VPN.
Zvolíme si svojí VNET, průvodce pro nás automaticky vytvoří "spojovačku" a přiřadíme/vytvoříme veřejnou IP, na které bude naše VPN poslouchat.
V mezičase si připravíme certifikáty. Funguje to tak, že musíme mít certifikační autoritu, jejíž public klíč naimportujeme do Azure VPN (serverové strany). Následně touto autoritou budeme generovat certifikáty pro klienty (uživatele), kterými se budou do VPN připojovat. Já použiji openssl, ale můžete to udělat i v PowerShell nebo přes utilitku makecrt.exe
Založíme si klíč pro certifikační autoritu.
openssl genrsa -out rootCA.key 2048
S tímto klíčem vytvoříme kořenový public certifikát. Současně ho rovnou ještě uložíme v DER souboru, který pak budeme importovat na klientech.
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem openssl x509 -outform der -in rootCA.pem -out rootCA.der
openssl genrsa -out tomaspc.key 2048 openssl req -new -key tomaspc.key -out tomaspc.csr openssl x509 -req -in tomaspc.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out tomaspc.crt -days 500 -sha256 openssl pkcs12 -export -inkey tomaspc.key -in tomaspc.crt -out tomaspc.pfx
Tím máme certifikáty připraveny.
Až bude VPN nahoře, pustíme se do konfigurace point-to-site funkce.
Pro připojené klienty potřebujeme přidělovat nějaké IP adresy - jiné, než ve VNETu. IPSec VPN používat nebudu, nechám zaškrtnutý jen SSTP.
Sjedeme níž a vložíme do konfigurace obsah souboru rootCA.pem mezi BEGIN a END certificate, tedy veřejný klíč naší certifikační autority.
Uložíme a můžeme stahovat VPN klienta.
Nejprve do klienta nakopírujeme PFX soubor s certifikátem a naimportujeme dvojím poklikem.
Totéž musíme provést pro kořenový certifikát naší autority, tedy nakopírovat a poklepat na rootCA.der.
Instalačku si nakopírujeme do klienta a nainstalujeme.
VPN je přímo integrovaná do Windows. Klikněte na ikonku sítě a najdeme ji tam.
To je všechno - teď už se stačí jen připojit!
Hotovo, jsme připojeni.
SoftEther a OpenVPN
Z pohledu protokolu se podíváme na OpenVPN. Na rozdíl od klasických IPSec tunelů, které mohou mít problémy dostat se přes různé NAT a potřebují specifické otevřené porty, funguje OpenVPN na TLS na běžném HTTPS portu 443. Ano - OpenVPN je z pohledu vašeho domácí firewallu stejná, jako přistupovat na HTTPS stránky. Čili něco, co je bezproblémově povoleno prakticky všude včetně kavárny či nákupního centra.
Jako server a klienta můžeme použít přímo software projektu OpenVPN, ale ten není (alespoň ve své open source formě) jednoduchý na nastavení. Existuje ale krásný open source projekt, který je klikací, a který nejen podporuje OpenVPN, ale i přináší velmi pokročilé možnosti autentizace, integrace apod. jde o https://www.softether.org
Instalace a nastavení VPN serveru
V Azure jsem si vytvořil VNET (privátní síť), v ní jednu testovací VM bez public IP adresy (do té se budu chtít dostat) a jednu Windows VM s public adresou - ta bude dělat VPN server. Stáhnu si instalačku z webu a nainstaluji SoftEther.
Po instalaci otevřeme konfigurační nástroj a připojíme se do lokální instance serveru (poprvé vás poprosí a založení hesla).
Vytvoříme se virtuální hub.
Výborně - pojďme si ho nastavit.
Přidáme si uživatele (jméno toho nebo těch, co se budou přihlašovat).
Pro začátek můžeme (nedoporučuji pro praxi) použít jen jméno a heslo. Další možnost je klienstký certifikát, který můžeme přímo v software vygenerovat a uživatel se jím bude prokazovat. Můžete se ale dokonce napojit i na centrální identity řízení - buď RADIUS protoklem (například proti Microsoft NPS serveru) nebo NT login (pak ale musí být VPN server v doméně). Bohužel modernější metody jako je Open Connect ID, které by se napojilo přímo na Azure Active Directory podporované není, ale to je u VPN koncentrátorů zatím běžné.
Dále musíme zapnout virtuální překlad adres a DHCP server pro připojené klienty. Tím zajistíme, že připojení klienti budou ve VNETu vystupovat pod IP adresou VPN serveru. To je samozřejmě krajně jednoduché řešení, ale v tomto příkladu mi jde právě o něco jednoduchého.
SoftEther pro vás vytvořil DDNS, tedy dynamické DNS jméno. To ale Azure umí také - na public IP si můžete nastavit záznam na něco.westeurope.cloudapp.azure.com. Co použijete je na vás, asi bych použil Azure a DDNS vypnul, ale je to celkem jedno.
Svoje DDNS jméno najdete zde:
A DNS v Azure si můžete nastavit na public IP adrese.
Připojíme klienta
Stáhneme si a nainstalujeme klienta - je k dispozici pro Windows, Linux a Mac. Pokud potřebujete ještě třeba Android, SoftEther server je kompatibilní s OpenVPN klienty, takže můžete použít na mobilech ty.
Přidáme si nové spojení.
Protože nemáme zatím žádný virtuální adaptér, bude pro nás vytvořen.
Nastavme si jednoduché připojení - nebudeme ověřovat certifikát (jen na chvilku, v praxi takhle nedělat!).
Připojte se.
Jsme tam! Klidně teď vyzkoušejte vzdálenou plochu na server ve VNETu, který nemá veřejnou IP.
Zabezpečíme si lépe
Ověřování serverového certifikátu
V první řadě serverový certifikát chceme rozhodně ověřovat. Buď mu dejte platný certifikát třeba z vaší CA, nebo alespoň udělejme self-signed, který ale naimportujeme klientům.
Na klientovi zapnu nutnost ověřování serverového certifikátu.
Když se teď pokusím spojit, neprojde to.
Na serveru se podíváme na certifikát.
Vytvoříme si nový self-signed certifikát na mojí Azure doménu.
Uložte a vyexportujte certifikát do souboru.
Provedeme export do CER souboru bez klíče (k tomu se nám udělá i soubor s klíčem, ten hned smažte, klient ho nepotřebuje).
Nakopírujte si do klienta a importujte.
Připojte se - bude fungovat.
Díky tomuto opatření máme jistotu, že klient mluví opravdu pouze s naším serverem a ne útočníkem.
Ověřování klienstkým certifikátem
Co kdybychom místo hesla uživatele použili bezpečnější certifikát? Vyzkoušejme si jednoduchou variantu - certifikát bez ověření důvěryhodnou autoritou.
Pojďme do nastavení serveru a budeme modifikovat můj účet tomas. Použijeme teď certifikátové ověření (bez podepsání autoritou) a vygenerujeme certifikát.
Hotovo. Certifikát si musíme vyexportovat a doručit na klienta. Tentokrát do souboru ale samozřejmě musí dostat i privátní klíč - provedem export jako PKCS (PFX soubor) a uzamkneme soubor heslem (bez jeho znalosti nelze klíče naimportovat).
Soubor nakopírujeme na klienta, změníme způsob přihlášení na klientský certifikát a naimportujeme ho.
Přihlašte se. Funguje! Teď už máme řešení velmi dobře zabezpečené a přitom je to stále dost jednoduché. Samozřejmě mohli bychom jít i dál a používat firemní certifikační autoritu, napojit se na RADIUS a tak podobně, ale pro náš příklad už tak daleko nepůjdu.
Potřebujete připojení z notebooku rovnou do VNET v Azure? Používáte primárně Windows na klientech a nepotřebujete víc jak 128 současně připojených uživatelů? Rozhodně použijte Azure VPN. Pokud potřebujete mix Windows, Linux a Mac klientů či máte větší nároky na počet uživatelů, zkuste třeba SoftEther.