Zdalny dostęp do firmy przez chmurę AWS?

Potrzebny zdalny dostęp do zasobów firmy, na JUŻ, na TERAZ. Sytuacja jest jaka jest… Trzeba szybko coś zrobić! 

A co gdybym Ci powiedział, że się DA! Na JUŻ, na TERAZ, z wykorzystaniem chmury Amazon Web Services (AWS).

Pomysł, zrodził mi się z racji otaczającej nas sytuacji i tego całego zamieszania wokół pilnej potrzeby wysłania pracowników do pracy z domu. 

Jednym z wyzwań to oczywiście potrzebą kolaboracji, choć w Polsce to słowo kojarzy się niezbyt pozytywnie, więc może niech będzie sprawnej komunikacji.

Dostępnych jest sporo rozwiązań jak MS Teams, Slack, Zoom i inne. Jedne bardziej RODO friendly inne chętnie podbierające nasze dane i kolejne dające różne warianty zabezpieczeń.

Ale jeszcze jeden z tematów, to dostęp do wewnętrznych systemów firmy, tych, które nie są dostępne bezpośrednio z Internetu. W tym wypadku potrzeba zapewnić bezpieczne połącznie do przecież wciąż działającej infrastruktury DataCenter i aplikacji tam działających.

Ten przypadek właśnie postanowiłem wziąść na tapetę. Jest to o tyle istotne dla tych, którzy nie posiadają żadnego rozwiązania i pilnie potrzebują coś zrobić. 

Zdalny dostęp przez chmurę AWS

Przyszedł mi do głowy właśnie taki pomysł? Weźmy chmurę i spróbujmy zapewnić zdalny dostęp do zasobów w lokalnym Data Center.

Z racji, że ja nie posiadam własnego Data Center, zasymilowałem takie środowisko w chmurze AWS.

Mam swoje „chmurowe” udające zwykłe ON-PREMISES DC, w których uruchomiona jest jakaś aplikacja. 

Aplikacja oczywiście nie jest dostępna publicznie z Internetu, a jedynie z sieci prywatnej firmy. 

Zatem w dalszym roku przygotowałem sobie kawałek infrastruktury AWS, w której będę hostował rozwiązanie do zdalnego dostępu.

W tym celu stworzyłem kawałek przestrzeni w usłudze Virtual Private Cloud (VPC), która jest takim „wirtualnym” Data Center w chmurze.

O tej jak i innych usługach AWS dowiesz się z mojego ebook – 5 USŁUG AMAZON WEB SERVICES, które warto poznać. 

Adresacja IP w moim Data Center to 10.100.0.0/16, zatem aby nie mieć problemy z routingiem dla VPN przeznaczyłem blok sieciowy 10.150.0.0/16.

Skonfigurowałem bezpieczne szyfrowane połączenie VPN, które jest dostępne w ramach usługi VPC. Połączenie to jest pomiędzy routerem brzegowym w DATA CENTER, a moim środowiskiem w AWS.

Teraz pojawia się najważniejszy element układanki, czyli nasz pracownik, który pracuje w domu i chce się połączyć z serwerem APP, który znajduje się w DATA CENTER.

Potrzebne jest rozwiązanie, które pozwoli w sposób bezpieczny i kontrolowany połączyć się do infrastruktury VPN_INFRA, a następnie przez tunel VPN do aplikacji APP.

Zastanawiając się przez chwilę, można to wykonać na kilka sposobów.

1. Jednym z nich to zapewne postawienie wirtualnej maszyny, zainstalowanie OpenVPN. Oczywiście trzeba wszystko zainstlować i skonfigurować od zera. Plus dochodza kwestie utrzymania, wysokiej dostępności itp.
2. Drugim wariantem możę być instalacja gotowego rozwiązania, które są oferowane w ramach AWS Marketplace. Sa tu rozwiązani firm Baracuda, Cisco i innych (w tym nawet te oparte o OpenVPN).
3. Trzecia opcja to poszukianie jakiegoś rozwiązania opartego o usługi AWS.

AWS Client VPN

W ten oto sposób doszliśmy do kandydata na zdalny dostęp.

AWS Client VPN, to usługa zdalnego dostępu do zasobów uruchomionych w chmurze AWS, oraz tych ulokowanych w lokalnym Data Center. 

Podstawowe właściwości usług to:

• Wpełni zarządzana przez AWS, po stronie użytkownika pozostaje konfiguracja wg. potrzeb,
• Bezpieczne połączenie TLS z wykorzystaniem klient OpenVPN dostarczonego przez AWS,
• Autentykacja z wykorzystaniem Active Directory lub certyfikatów,
• Granularna kontrola zarówno na poziomie sieci i uprawnień,
• Integracja z innymi usługami jak AWS Active Directory lub VPC.

Wstępna konfiguracja dla AWS Client VPN

Przejdźmy zatem do konfiguracji. W tym celu w VPC, będę tworzył coś, co nazywa się Client VPN Endpoint.

Ja w swoim przykładzie, dla uproszczenia wykorzystam metodę autentykacji opartą o certyfikat.

Dlatego na wstępie potrzebuję wygenerować dwa certyfikaty – dla serwera i dla klienta.

W tym celu pobiorę sobie prosty tool OpenVPN’a easy-rsa.

git clone https://github.com/OpenVPN/easy-rsa.git

Następnie przechodzę do katalogu i po kolei, inicjalizuję środowisko PKI i tworzę CA – certificate authority.

cd easy-rsa/easyrsa3
./easyrsa init-pki
./easyrsa build-ca nopass

Nastepnie tworzę certyfikat serwera:

./easyrsa build-server-full server nopass

A także certyfikat dla klienta:

./easyrsa build-client-full client1.vpn.lukado.eu nopass

Następnie, dla ułatwienia, skopiuje sobie wszystkie pliki do jednego folderu, aby ułatwić dalszą konfigurację.

mkdir ~/Downloads/lukado_vpn/
cp pki/ca.crt ~/Downloads/lukado_vpn/
cp pki/issued/server.crt ~/Downloads/lukado_vpn/
cp pki/private/server.key ~/Downloads/lukado_vpn/
cp pki/issued/client1.vpn.lukado.eu.crt ~/Downloads/lukado_vpn/
cp pki/private/client1.vpn.lukado.eu.key ~/Downloads/lukado_vpn/

Teraz mam już wszystko gotowe do tego aby przejść do konfiguracji po stronie AWS.

Na początek trzeba zaimportować utworzone przed momentem certyfikaty. Na platformie AWS, jest dedykowana usługa do zarządzania i dystrybucji certyfikatów – AWS Certificate Manager(ACM).

AWS Client VPN jak i wiele innych usług integruje się certificate managerem i może korzystać z certyfikatów, które tam są.

Aby było szybciej wykorzystam aws cli do importu certyfikatów do ACM. 

cd ~/Downloads/lukado_vpn/

aws acm import-certificate --certificate file://server.crt --private-key file://server.key --certificate-chain file://ca.crt --region eu-central-1

aws acm import-certificate --certificate fileb://client1.vpn.lukado.eu.crt --private-key fileb://client1.vpn.lukado.eu.key --certificate-chain fileb://ca.crt --region eu-central-1

Plus jeszcze weryfikacja:
aws acm list-certificates --region eu-central-1

Cerfytikaty zostały zaimportowane, zatem mogę już przejść do zasadnijczej konfiguracji.

Konfiguracja AWS Client VPN

Konfigurację Client VPN wykonuje się w ramach usługi VPC (ja tym razem operuje w regionie Frankfurt). Po lewej stronie na dole znajduje się sekcja Client VPN Endpoints gdzie utworzę nowy endpoint.

Piersza cześć to jak zwykle nazwa plus opis, oraz zakreś adresacji IP, który będzie przydzielany klinetom VPN. Oczywiście zakres ten nie powinien pokrywać się (kwestie routingu) ani z VPC, do którego będziemy się przyłączać ani z adresacją IP w Data Center.

Ja wybrałem 10.200.0.0/16

Następnie w części Authentication Information wybieram opcję „Use mutual authentication” i wskazuje zaimportowane certyfikaty serwera i klienta.

Dodatkowo można jeszcze włączyć zbieranie logów do CloudWatch, oraz opcjonalnie określić jeszcze takie rzeczy jak:

• Serwery DNS,
• Protokół transportowy – tutaj nic nie zmieniam UDP w tym wypadku sprawdza się lepiej,
• Enable split-tunnel – kiedy jest potrzeba aby podzielić, który ruch idzie przez tunel VPN, a który niezależnie.
• VPC ID – dodatkowo można powiązać od razu z VPC, ja to zrobię później.
• VPN Port- ja zostawiam domyślnie 443.

Finalnie moja konfiguracja wygląda jak poniżej (min. potrzebne do działania): 

Kiedy Endpoint zostanie utworzony, czas na powiązanie Endpointa z VPC i podsiecią. W zakładce Association dodajemy VPC i Subnet. Po kliknięciu Associate, trzeba czasem trochę poczekać.

Dalej jeszcze aby klienci mogli korzystać z zasobów trzeba ich do tego autoryzować. W tym celu w zakładce Authorization stworzę dwie konfiguracje. 

Pierwszy to dostęp do przestrzeni VPC VPN_INFRA czyli do sieci 10.150.0.0/16.

Gdybym korzystał z metody autentykacji „Use user-based authentication” wtedy mógłbym określić grupę użytkowników, którzy mogą z tej reguły korzystać.

Drugi to dostęp do zasobów Data Center – czyli do sieci 10.100.0.0/16

Aby dostać się do zasobów Data Center trzeba jeszcze przejść do zakładki Route Table i dodać wpis, że do sieci 10.100.0.0/16 ruch ma iść przejść podsieć z VPC z którym Endpoint jest powiązany.

Należy też pamiętać o dytrybucji czy też odpowiednich wpisach w tablicy routingu po stronie DATA CENTER, aby skierować ruch do sieci klientów VPN (w tym wypadku 10.200.0.0/16) przez tunel VPN do AWS.

To już wszystko jeśli chodzi o konfigurację po stronie AWS. Pozostaje jeszcze pobrać konfigurację do klienta i oczywiście pobranie i instalacja samej aplikacji AWS Client VPN.

Zanim jeszcze uda mi się połączyć do wykonania są jeszcze dwa kroki:

Po pierwsze plik z konfiguracją VPN i certyfikat i klucz klienta muszą znajdować się w tym samym katalogu. Ja dla uproszczenia przeniosłem plik z konfiguracją do mojego katalogu z certyfikatami: ~/Downloads/lukado_vpn/

Po drugie trzeba wyedytować plik z konfiguracją i dopisać ściężkę do certyfikatu i klucza. U mnie to:

cert ~/Downloads/lukado_vpn/client1.vpn.lukado.eu.crt
key ~/Downloads/lukado_vpn/client1.vpn.lukado.eu.key

Zmodyfikować adres endpoint’a poprzez dopisanie czegoś na jego początku. W tym celu odszukujemy coś w tej postaci:

remote cvpn-endpoint-0d069d2a422b060c1.prod.clientvpn.eu-central-1.amazonaws.com 443

i zmieniam na coś w stylu:

remote lukado.cvpn-endpoint-0d069d2a422b060c1.prod.clientvpn.eu-central-1.amazonaws.com 443

Teraz już pozostaje zapisać plik, odpalić klienta, zaimportować konfigurację i wykonać połączenie.

Udało się połączyć, więc sprawdzam, czy mogę się dostać na serwer w Data Center….

Jak widać działa ?

Jak już wspominałem moje Data Center też jest w AWS ?

AWS Client VPN – szybkie i niezbyt skomplikowane rozwiązanie do zdalnego dostępu.

Jak widać dość łatwo i szybko można skonfigurować zdalne połączenie VPN z wykorzystaniem AWS Client VPN. 

Co z pewnością w dzisiejszej sytuacji może być dość ciekawe. Bez czekania, bez instalacji sprzętu i masowego zakupu licencji.

Z pewnością przy większej skali należałoby rozważyć integrację za Active Directory dla lepszego zarządzania dostępami i użytkownikami. 

Dodatkowo poza Authorization Rule’ami można jeszcze wykorzystać Security Group’y do kontroli i przepływu połączeń.

A póki co to tyle. Cheers ?

---

Zbuduje swoje bezpieczne środowisko AWS.