Sieci wirtualne i podsieci

Azure Virtual Network (VNet) to logicznie odizolowana sieć w chmurze Azure, którą można definiować i kontrolować. Jest podstawowym elementem infrastruktury sieciowej Azure, umożliwiającym zasobom Azure, takim jak maszyny wirtualne, bazy danych i usługi aplikacji, bezpieczną komunikację między sobą, z internetem oraz z sieciami lokalnymi. Sieć VNet obejmuje jeden region Azure oraz określoną przestrzeń adresową IPv4 (i opcjonalnie IPv6) w notacji CIDR, definiowaną podczas jej tworzenia.

Podczas tworzenia sieci VNet przypisuje się jej przestrzeń adresową z użyciem notacji CIDR. Notacja CIDR (Classless Inter-Domain Routing) określa zarówno adres sieci, jak i liczbę bitów używanych jako prefiks sieci. Na przykład 10.0.0.0/16 zapewnia 65 536 adresów IP (od 10.0.0.0 do 10.0.255.255). Przestrzeń adresowa musi należeć do prywatnego zakresu adresów IP (10.0.0.0/8, 172.16.0.0/12 lub 192.168.0.0/16 zgodnie z RFC 1918). Należy wybrać przestrzeń adresową wystarczająco dużą, aby pomieścić wszystkie planowane podsieci i pozostawić miejsce na rozwój, ale jeśli planują Państwo połączenie hybrydowe, trzeba unikać nakładania się jej z sieciami lokalnymi.

Podsieć dzieli przestrzeń adresową VNet na mniejsze segmenty sieci. Każda podsieć ma własny zakres adresów IP (będący podzbiorem przestrzeni adresowej VNet) i może zawierać zasoby różnego typu. Podsieci służą dwóm celom: organizacji (grupowaniu powiązanych zasobów) oraz izolacji (stosowaniu różnych reguł zabezpieczeń do różnych grup zasobów). Można na przykład utworzyć podsieć web-tier (10.0.1.0/24) dla serwerów internetowych, podsieć app-tier (10.0.2.0/24) dla serwerów aplikacji oraz podsieć data-tier (10.0.3.0/24) dla baz danych.

W każdej podsieci Azure rezerwuje pierwsze cztery adresy IP oraz ostatni adres IP na własne potrzeby. W przypadku podsieci 10.0.1.0/24 są to: 10.0.1.0 (adres sieci), 10.0.1.1 (brama domyślna), 10.0.1.2 i 10.0.1.3 (zarezerwowane dla DNS Azure) oraz 10.0.1.255 (adres rozgłoszeniowy). W podsieci /24 pozostaje 251 użytecznych adresów IP. Przy określaniu rozmiaru podsieci należy uwzględnić tę rezerwację — podsieć /28 ma tylko 11 użytecznych adresów (16 minus 5 zarezerwowanych).

Domyślnie zasoby w tej samej sieci VNet mogą komunikować się ze sobą za pomocą prywatnych adresów IP, nawet jeśli znajdują się w różnych podsieciach. Komunikacja wewnątrz VNet nie wymaga dodatkowej konfiguracji. Zasoby w różnych sieciach VNet nie mogą domyślnie komunikować się ze sobą — należy jawnie je połączyć za pomocą funkcji VNet Peering. Zasoby w tej samej podsieci współdzielą ten sam segment sieci, dzięki czemu komunikacja między nimi odbywa się najbardziej bezpośrednią możliwą ścieżką w ramach definiowanej programowo warstwy sieciowej Azure.

Maszyny wirtualne w sieci VNet mogą domyślnie inicjować połączenia wychodzące z internetem — Azure automatycznie zapewnia wychodzący dostęp do internetu za pośrednictwem zarządzanej usługi NAT. Aby zapewnić przychodzący dostęp z internetu, zasób musi mieć przypisany publiczny adres IP do interfejsu sieciowego lub modułu równoważenia obciążenia. Następnie można kontrolować dostęp przychodzący za pomocą reguł Network Security Group (NSG), określając dokładnie dozwolone porty i protokoły. Typowa architektura umieszcza serwery internetowe w publicznej podsieci z publicznymi adresami IP, a serwery aplikacji w prywatnej podsieci, dostępnej wyłącznie z warstwy internetowej.

Domyślnie Azure automatycznie obsługuje routing — ruch między podsieciami pozostaje w obrębie VNet, wychodzący ruch internetowy jest obsługiwany przez NAT, a ruch do usług Azure korzysta z sieci szkieletowej Azure. Można to zmienić za pomocą tras definiowanych przez użytkownika (User-Defined Routes, UDR) w tabeli tras. Częstym zastosowaniem jest wymuszenie kierowania całego wychodzącego ruchu internetowego przez wirtualne urządzenie sieciowe (Network Virtual Appliance, NVA) lub Azure Firewall w sieci VNet typu hub, aby centralnie go kontrolować. Należy utworzyć tabelę tras, dodać wpisy tras i skojarzyć tabelę z co najmniej jedną podsiecią, aby zastosować te ustawienia.

Niektóre usługi Azure — takie jak Azure App Service (VNet Integration), Azure Kubernetes Service, Azure SQL Managed Instance i Azure Databricks — wymagają dedykowanej podsieci delegowanej na rzecz danej usługi. Delegowana podsieć oznacza, że Azure może w Państwa imieniu wstrzykiwać do niej zasoby specyficzne dla usługi (interfejsy sieciowe, wewnętrzne adresy IP). Do delegowanej podsieci nie można wdrażać innych typów zasobów — jest ona zarezerwowana wyłącznie dla tej usługi Azure. Planując korzystanie z usług wymagających delegowania, należy zawsze przydzielić dedykowaną podsieć z wystarczającą przestrzenią adresową.

Najważniejsze najlepsze praktyki dotyczące projektowania VNet: zaplanuj przestrzeń adresową przed utworzeniem VNet — nie można jej zmienić bez ponownego utworzenia zasobów. Używaj oddzielnych podsieci dla każdej warstwy aplikacji, aby stosować odrębne zasady zabezpieczeń. Unikaj nakładających się przestrzeni adresowych z sieciami lokalnymi, jeśli planujesz połączenie za pomocą VPN lub ExpressRoute. Rezerwuj większe podsieci dla usług wymagających skalowania (np. pul węzłów AKS). Nazywaj zasoby w jasny sposób (np. vnet-prod-eastus-001), aby ułatwić zarządzanie na dużą skalę. Dobrze zaprojektowany VNet znacznie łatwiej zabezpieczać i diagnozować niż sieć utworzona ad hoc.

Sieci Azure VNet można łączyć z sieciami lokalnymi za pomocą dwóch mechanizmów: VPN Gateway — szyfrowanego tunelu IPsec/IKE przez publiczny internet; rozwiązanie opłacalne przy umiarkowanym zapotrzebowaniu na przepustowość. Azure ExpressRoute — prywatnego, dedykowanego połączenia światłowodowego za pośrednictwem partnerskiego dostawcy sieci; zapewnia większą przepustowość, mniejsze opóźnienia i bardziej przewidywalną wydajność niż VPN. W przypadku wrażliwych obciążeń lub scenariuszy wymagających gwarantowanej przepustowości preferowaną opcją jest ExpressRoute, choć wiąże się on ze znacznie wyższym kosztem i dłuższym czasem aprowizacji.

Określenie rozmiaru przestrzeni adresowej VNet wymaga zaplanowania bieżących i przyszłych potrzeb. Często stosowany wzorzec korporacyjny to: przestrzeń adresowa VNet: /16 (65 536 adresów). Podsieci: /24 na każdą warstwę obciążenia (po 251 użytecznych adresów). VNet /16 może zawierać 256 podsieci /24 — to więcej niż potrzeba w większości środowisk. W bardzo dużych środowiskach należy użyć zakresu /8 lub poprosić o kilka niepokrywających się zakresów. Należy zawsze pozostawić miejsce na rozwój: przydzielenie dziś zakresu /24, gdy w przyszłym roku może być potrzebny /22, prowadzi później do uciążliwego ponownego adresowania.

Sprawdź swoją znajomość zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.

W tej lekcji poznali Państwo: Azure VNet to logicznie izolowana sieć ze zdefiniowaną przestrzenią adresową CIDR, ograniczona do jednego regionu, podsieci dzielą VNet na segmenty w celu uporządkowania zasobów i odizolowania zasad zabezpieczeń, a także Azure rezerwuje 5 adresów IP w każdej podsieci, a zasoby w tym samym VNet komunikują się domyślnie prywatnie, bez dodatkowej konfiguracji. Następnie omówimy Network Security Groups i Application Security Groups służące do filtrowania ruchu.