Tym razem w poniższym artykule pochylimy się nad konfiguracją sieciową naszej chmury. Zaprezentujemy sobie jak utworzyć prywatną sieciową przestrzeń, w której będziemy mieć możliwość uruchamiania naszych wielowarstwowych aplikacji i systemów. Wydzielimy w naszym data center przestrzeń publiczną (dostępna z internetu) oraz prywatną (odizolowaną od ruchu spoza sieci), zdefiniujemy reguły routingu oraz przedstawimy sobie w jaki sposób możemy zapewnić bezpieczeństwo naszym usługą uruchamianym wewnątrz sieci. Wszystkie komponenty infrastruktury, które utworzymy w ramach tego artykułu są darmowe, więc możemy być spokojni o nasz rachunek 🙂
Czym jest VPC ?
Virtual Private Cloud – jest to logiczna i odizolowana przestrzeń sieciowa, w której mamy możliwość uruchomienia zasobów AWS, m. in. wirtualnych serwerów EC2 czy też relacyjnych baz danych RDS. Każda przestrzeń jest niezależnym bytem, posiada swoją własną adresację (IPv4 bądź IPv6), którą mamy możliwość zdefiniować oraz jest domyślnie niedostępna z żadnej innej sieci oraz z internetu. W VPC mamy pełną kontrolę nad konfiguracją sieciową, możemy dzielić naszą przestrzeń na podsieci, wydzielać części publiczne, w których będziemy uruchamiać serwery webowe oraz części prywatne, w których będziemy chcieli uruchamiać usługi objęte większą ochroną, do których nie będziemy dopuszczać ruchu spoza naszej sieci. Mogą to być właśnie serwery aplikacyjne czy też bazy danych.
W każdym data center budowanym on premises również realizowana jest konfiguracja sieciowa. Realizowana jest on za pomocą urządzeń takich jak routery, switche czy firewalle. AWS dostarcza nam możliwość skonfigurowanie analogicznych ustawień sieci związanych z routingiem i bezpieczeństwem za pomocą funkcjonalności dostępnych w VPC. W dalszej części artykułu przybliżymy sobie wszystkie najważniejsze aspekty związane z budowaniem data center w publicznej chmurze AWS.
Tworzenie nowego VPC
Nie przedłużając przechodzimy do działania logując się do naszego konta w AWS. Wyszukujemy w wybieraczce usługę VPC i przechodzimy do następnego dashboardu.
Na głównym ekranie ujrzymy informację o tym jakie funkcjonalności i jakie komponenty VPC zostały uruchomione w wybranym regionie. Z bocznego panelu wybieramy opcję Your VPCs, aby przejść do listy VPC
Tutaj ważna informacja. Całe VPC jak i wszystkie usługi w nim uruchomione (np. serwery EC2) są region-specific co oznacza, że nasze zasoby będą trwale związane z geograficzną lokalizacją data center AWS. Jeśli budujemy data center, które będzie obsługiwało ruch z polski polecam wybrać między regionem Ireland bądź Frankfurt, ze względu na to, iż zlokalizowane sa one najbliżej naszego kraju, co będzie miało przełożenie na mniejsze opóźnienia przy transmisji danych. Ja dla swojego VPC wybrałem region Frankfurt (eu-central-1).
Na powyższym ekranie przedstawiona jest lista wszystkich VPC jakie są utworzone w wybranym regionie. Na liście prezentuje się jedna pozycja, nawet jeśli wcześniej nie tworzyłeś żadnych sieci, jest tak dlatego, że AWS w każdym z regionów tworzy domyślne VPC wraz subnetami (podsieciami). Nie musimy się tym przejmować, gdyż są to komponenty, za które nie jesteśmy w żaden sposób chargowani. Polecam usunąć to domyślne VPC, aby nie myliło nam się to w późniejszej konfiguracji (zaznaczamy domyślne VPC -> klikamy Actions -> Delete VPC -> potwierdzamy). Chcąc stworzyć nasze nowe VPC klikamy Create VPC
Czas na pierwszą konfigurację. Musimy podać nazwę naszego VPC, najlepiej taką, która jednoznacznie będzie identyfikować i opisywać cel utworzenia. Kolejnym parametrem jest CIDR block, dla osób, które z sieciami mają na co dzień do czynienia ten parametr powinien być jasny. Ja pozwolę sobie krótko wyjaśnić i pokazać jak prawidłowo ustawić jego wartość. W przyszłości planuję popełnić krótki wpis na temat wyliczania CIDR bloków w kontekście VPC, gdyż temat ten jest istotny, a pytania dotyczące jego zrozumienia często pojawiają się na egzaminach certyfikacyjnych AWSa.
Notacja CIDR definiuję adresację naszej sieci. Składa się ona z adresu IPv4 oraz maski
199.199.199.0 <- IPv4
/24 <- maska
Maska określa nam jak duża hostów (serwerów) będziemy mogli zaadresować w naszej sieci. Adres IPv4 jak wiemy jest adresem 32 bitowym. Definiując maskę 24 bitową określamy, że pierwsze 24 bity będą statyczną częścią adresu (wszystkie IP hostów będą zaczynać się od adresu 199.199.199 ) natomiast pozostałem 8 bitów, czyli ostatni oktet będzie dynamicznie przydzielany serwerą wewnątrz VPC. Oznacza to, że maska 24 bitowo pozwoli nam zaadresować 256 serwerów w naszej sieci, a tak naprawdę 251 gdyż 4 pierwsze oraz ostatni adres są zarezerwowane przez AWS (x.x.x.0, x.x.x.1, x.x.x.2, x.x.x.3, x.x.x.255.) Przykładowo maska 16 bitowa pozwoliła zaadresować 65534 hostów. Teraz powinieneś rozumieć dlaczego ten parametr jest tak bardzo istotny, gdyż już podczas tworzenia VPC musisz przewidzieć i zdefiniować jak dużej sieci potrzebujesz. Moja sieć będzie niewielka, dlatego zdecydowałem, że masak 24 bitowa w zupełności mi wystarczy.
Wracając do konfiguracji, pozostały do zaznaczenia, że nie potrzebujemy dodatkowej adresacji dla IPv6 oraz wybrania Tenancy = Defalut. Konfigurując Tenancy = Dedicated AWS stworzyłby naszą sieć na fizycznie dedykowanej infrastrukturze. Takie ustawienie zapewnia lepszy performance, ale nalicza również dodatkowe opłaty. Zwykle stosuje się to ustawienie w rozwiązaniach Enterprise i performance-critical.
Gdy wszystko mamy już ustawione klikamy Create i voila mamy utworzone VPC.
Ostatnią rzeczą jaką dobrze jest zrobić w utworzonym VPC to włączenie opcji DNS hostnames. Dzięki tej opcji serwerą uruchomionym wewnątrz sieci oprócz adresów IP będą również przypisywane adresy DNS.
Podział VPC na publiczne i prywatne subnety
Gdy VPC mamy już gotowe czas na wydzielenie części prywatnej oraz publicznej w naszej sieci. Scharakteryzowaliśmy już sobie w przydługim wstępie do czego może służyć każda z podsieci. Z punktu widzenia konfiguracji część publiczną od części prywatnej odróżnia tylko fakt, że do publicznej podsieci zostanie skonfigurowane połączenie z Internet Gatewayem. IGW, bo takim skrótem najczęściej określa się ten komponent, służy do tego, aby zapewnić instancją uruchomionym w publicznym subnecie dostęp na świat, czyli inaczej mówiąc umożliwia komunikację z internetem w obie strony, zarówno z serwera jak i do serwera. W pierwszej kolejności musimy utworzyć nasz IGW i połączyć z naszym VPC (jeszcze nie z publicznym subnetem)
Powyższe 4 obrazki ilustrują w krokach jak należy prawidłowo utworzyć i podłączyć IGW z naszym VPC. Mała uwaga, jeśli nie usunęliście domyślnego VPC utworzonego przez AWSa, domyśle IGW również będzie u Was widoczne na liście.
Możemy teraz przejści do tworzenia subnetów. Zostaną utworzone 4 subnety z poniższa konfiguracją:
- cloud-box-public1 – publiczny, AZ eu-central-1a, CIDR 199.199.199.0/26
- cloud-box-public2 – publiczny AZ eu-central-1b, CIDR 199.199.199.64/26
- cloud-box-private1 – prywatny, AZ eu-central-1a, CIDR 199.199.199.128/26
- cloud-box-private2 – prywatny, AZ eu-central-1b, CIDR 199.199.199.192/26
Skąd taka a nie inna konfiguracja CIDR bloków, powinieneś już się domyślać. Całe VPC posiada maskę 24 bitową więc ma możliwość zaadresowania 256 adresów, dzieląc to na 4 uzyskujemy 64 adresy IP per każdy subnet, a to odpowiada masce 26 bitowej. (32 – 26 = 6 skolei 2^6 daje nam 64). W konfiguracji pojawia się nam również pojęcia Availability Zone. Każdy region składa się z kilku AZ-ów czyli swego rodzaju strefę, w której zlokalizowane jest data center AWS. Są one w pełni odizolowane co oznacza, że awaria jednego z AZ nie ma wpływu na inne. To właśnie ten czynnik dyktuje to, że nasze systemy staramy się rozmieszczać i backupować po różnych AZ-tach w danym regionie, po to aby zapewnić wysoką dostępność i odporność na awarię zony. Dlatego właśnie nasze VPC podzieliliśmy na 4 subnety, które rozmieszczone zostały w 2 AZ-tach eu-central-1a oraz eu-central-1b.
Konfiguracja subnetów
Gdy subnety zostały już utworzone przyszedł czas na ich konfigurację. W tej części omówimy sobie podstawowe elementy konfiguracji, na początek kilka pojęć, związanych z konfiguracją ruchu sieciowego w obrębie VPC i subnetów:
Route table – z każdym VPC skojarzony jest niejawny router, który używa tablic routingu do tego, aby zarządzać i prawidłowo kierować ruchem sieciowym wewnątrz VPC. Każdy subnet musi być powiązany dokładnie z jedna tablica routingu (przy tworzeniu przypisywane jest do domyślnej tablicy)
Network ACL – rodzaj firewall na poziomie subnetu. Jest to lista reguł określająca jaki ruch wchodzący jak i wychodzący ma zostać dopuszczony a jak nie (DENY/ALLOW). Domyślnie cały ruch jest otwarty, aby go ograniczyć musimy sami dodać reguły zabraniające w liście ACL.
Security group – rodzaj firewall na poziomie instancji (np. serwerów, load-balancerów). Tak jak w przypadku ACL mamy możliwość zdefiniowania ruchu wchodzącego jak i wychodzącego, z tą różnicą, że SG definiują jedynie reguły zezwalające na ruch, a domyślnie cały ruch jest zablokowany. W tym artykule nie będziemy konfigurować SG, gdyż jest to firewall na poziomie instancji, a nie subnetu. Bliżej przyjrzymy się security group gdy będziemy uruchamiać nasz serwer EC2 w jednym z kolejnych artykułów.
Na pierwszy ogień bierzemy konfigurację RT. Z bocznego panelu wybieramy zakładkę Route Table i klikamy Create route table
Utworzyliśmy dwie tablice routingu, jedną prywatną a drugą publiczną. Aby nasz publiczna tablica routingu faktycznie była publiczna, czyli miała skonfigurowany route do internetu musimy do niej przypisać wcześniej utworzony Internet Gateway
Wybieramy z list naszą publiczną tablicę routingu, przechodzimy do podzakładki Routes i klikamy Edit routes. W każdej tablicy występuje domyślnie jedna reguła z adresem subdomeny oraz targetem local, oznacza ona, że możliwa jest komunikacja wewnątrz podsieci. My chcemy przyłączyć do tej podsieci ruch z bramy internetowej, więc klikamy Add route, jak Destination wpisuje adres 0.0.0.0/0 – co oznacza że dotyczy to wszystkich adresów IPv4 a jako Target wskazujemy nasz utworzony IGW. Zapisujemy. Prywatną tablicę routingu zostawiamy bez zmian.
Ostatni krok to przypisanie skonfigurowanych tablic routingu do wcześniej utworzonych subnetów. Do publicznej tablicy routingu przypisujemy tylko publiczne subnety, a do prywatnej tablicy subnety prywatne, logiczne :).
Nasza sieć jest już praktycznie gotowa. Pozostaje wyjaśnić czym są jeszcze ACL i Security Group, w kontekście VPC.
Network ACL jak już wcześniej sobie powiedzieliśmy jest swego rodzaju firewallem. Za pomocą owej listy dostępów mamy możliwość zdefiniowania reguł, które będą otwierać bądź blokować ruch dla poszczególnych subnetów. Przechodząc do zakładki Network ACLs możemy zauważyć, że podobnie jak w przypadku IGW czy VPC, AWS sam utworzył dla nas domyślną listę ACL. Wszystkie utworzone przez nas subnety są do tej listy przypisane, gdyż nie ma możliwości utworzenia subnetu bez przypisania listy ACL (domyślnie przypisywana jest właśnie ta predefiniowana przez AWSa). Owa lista posiada jedną regułę, która określa, że ruch z całego internetu i dla wszystkich protokołów jest otwarty. Za pomocą listy ACL moglibyśmy np. utworzyć regułę, które umożliwi dostęp do sieci tylko z naszego IP, albo regułę, która zablokuje naszą sieć przed jakimś podejrzanym adresem IP, bądź zakresem adresów. W naszym przypadku nie będziemy tutaj zmieniać tych reguł.
Na początku tego akapitu wspomniałem jeszcze chwilę o Security Groupach. Są one ściśle związane z VPC, jednak ich tematem oraz ich konfiguracją poświęcimy sobie więcej czasu w artykule, opisującym uruchamianie serwerów EC2.
Podsumowanie
Powyższy obrazek ilustruje konfigurację sieciową, która utworzyliśmy. Tak skonfigurowana sieć pozwoli nam w późniejszym czasie na eksperymentowanie z innymi komponentami i funkcjonalnościami. A już w kolejnym artykule pokażemy sobie jak w stworzonym przez nas VPC uruchomić serwer EC2: https://cloud-box.pl/aws-ec2-wirtualny-serwer/
